> 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 49 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 28 minutes ago [-]
Why is it giving me Vlang vibe
api 59 minutes ago [-]
Why does this need a new language? Aren't there existing languages where these concepts can be expressed?
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 46 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 37 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 29 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.
binary132 49 seconds ago [-]
typesystems can be considered a kind of static analysis
classified 36 minutes ago [-]
So you prefer runtime crashes to compiler diagnostics, just so the type system can be "simpler"? I find these priorities backwards.
dnautics 32 minutes ago [-]
> So you prefer runtime crashes
Do you not understand what static analysis is?
Rendered at 20:13:38 GMT+0000 (Coordinated Universal Time) with Vercel.
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 :)
https://en.wikipedia.org/wiki/Transmeta
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?