Rendered at 19:55:19 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Cyan488 25 minutes ago [-]
> Heterogeneity belongs in the type system, not in the runtime.
Is the intent that applications developed with this are compiled for target hardware on a machine-specific basis?
e.g. I define a machine file for my i5 and GTX3080, and another machine file for my gnarly datacenter rack, and the compiler compiles specifically for each?
That way the same source file is "provable" for different hardware configurations without relying on a runtime to be identicallu implemented?
png732 30 minutes ago [-]
Is there a backstory for this being named Vx? Seems a bit too close for comfort to the VxWorks OS, though there seems to be no connection.
> Vx is the right language for the thing that must be correct and fast across ten kinds of silicon. It is not the right language for the thing you are still figuring out.
Sounds like a great language for an AI to use then :)
yewenjie 10 minutes ago [-]
Why is it giving me Vlang vibe
api 41 minutes ago [-]
Why does this need a new language? Aren't there existing languages where these concepts can be expressed?
classified 21 minutes ago [-]
[dead]
AnimalMuppet 2 hours ago [-]
I haven't played with it at all, but the writeup looks promising. Moving a bunch of things into the type system and out of runtime crashes is one of the ways we make progress.
dnautics 27 minutes ago [-]
I think this is wrong. Type systems should be simpler, and you should design it so that your language is easily and correctly statically checked. Not all invariants necessarily have to be verified at the same cadence (compile time)
treyd 19 minutes ago [-]
> you should design it so that your language is easily and correctly statically checked.
You do that by making the type system more sophisticated.
If you have a really important invariant that you really don't want to be violated due to run-time behavior/input, it's a huge benefit to have a compiler that can statically check that it actually can't be. That's one of the main benefits of having type systems, not just describing the shape of data structures in memory.
dnautics 10 minutes ago [-]
You can perform static analysis outside of the compiler without putting things in the type system?
C is a bad language to do this with for various reasons, but as a simple example:
char* buf = malloc(SIZE);
free(buf);
free(buf);
There is absolutely no reason why static analysis should not be able to see what the problem is here.
classified 18 minutes ago [-]
So you prefer runtime crashes to compiler diagnostics, just so the type system can be "simpler"? I find these priorities backwards.
Is the intent that applications developed with this are compiled for target hardware on a machine-specific basis?
e.g. I define a machine file for my i5 and GTX3080, and another machine file for my gnarly datacenter rack, and the compiler compiles specifically for each?
That way the same source file is "provable" for different hardware configurations without relying on a runtime to be identicallu implemented?
Sounds like a great language for an AI to use then :)
You do that by making the type system more sophisticated.
If you have a really important invariant that you really don't want to be violated due to run-time behavior/input, it's a huge benefit to have a compiler that can statically check that it actually can't be. That's one of the main benefits of having type systems, not just describing the shape of data structures in memory.
C is a bad language to do this with for various reasons, but as a simple example:
There is absolutely no reason why static analysis should not be able to see what the problem is here.Do you not understand what static analysis is?