How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
> 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.
A bit tangential, but I really *really* appreciate them making this distinction, and wish more people did this. Way too many tools try to advertise themselves as all things for all people, catering to all use cases, and that helps nobody.
Ugh guys... The front page of your project is the most important thing there is. If you can't even be bothered to write it yourself then I don't have much hope for the rest of your project.
And it doesn't seem to render correctly on mobile. I hit this myself trying to vibe up a side project; it looked slick, but it took multiple prompts (and at least an uploaded screenshot or two) just to make it mobile friendly.
Title's a tell, sure. But "every chip" is the bigger red flag for me. Somebody's gonna hit a silicon errata at 3am and find out the abstraction doesn't cover it. Good luck with that in prod.
I'm reminded of a number of critiques that have popped up over the years such as "C Is Not a Low-level Language: Your computer is not a fast PDP-11" and others I can't remember at the moment. In essence our "low level" languages are designed to run on an abstract machine that hasn't changed much since the 70s while the actual hardware it's meant to abstract over has become incredibly sophisticated. As a simple example consider how many programming languages have something simple like SIMD support without dropping into compiler intrinsics or relying on the optimizer.
I've actually created some experimental DSL embeddings around this idea before as I find it a fascinating area. Skimming through the Vx docs it seems like it is moving some of the abstract machine into the type system for greater flexibility.
Many CPUs, and most since the PDP-11 were designed were designed around the languages (often C/C++) that they support (eg later x86). For example the introduction of AVX for SIMD with un-aligned memory and load-store cues for unrolling loops with pointers across memory boundaries without penalty. C++ of course also evolved.
It's important to note that there was a huge shift from RISC to CISC to speed decode and then to vectorization and virtualization. The former was driven at first to allow higher single threaded clock speeds, and then when that hit a power wall ~2004 to raise data throughput and allow multi-threading (which required code changes), and then multiple virtual machines.
The unaligned load thing is a good example. On recent x86 I've profiled, misaligned AVX loads that stay inside a cache line cost basically nothing, so the old alignment tricks are mostly noise now. Crossing a 64-byte line is still where you get bitten, though, and compilers rarely warn you.
We tried something like this for a small DSL, and the prompt wasn't the problem, the missing tests were. Once we wrote a few dozen failing examples first and had the model grind against them, it got useful fast. Without that you just get a nice README claiming GPU support that nobody ever ran.
I have come slowly to the view that LLMs are very good at this kind of thing and we can use them very productively. I’m tempted to say that this is optimal human+LLM collaboration.
even when the underlying language is widely used (in this case, Rust) I think there is a case to coin a new language when (i) there is a bunch of new stuff, (ii) it ain’t gonna be adopted wholesale by the core team and (iii) it has a coherent toolchain and (iv) it makes promises to coders that are stable over time. Disclosure, I am the author of https://bil-lang.org that pulls the same trick as an extension / transpiler targeting golang
> 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 :)
> 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?
> Is the intent that applications developed with this are compiled for target hardware on a machine-specific basis?
Vx gives you the power to do so, but one can be conservative by putting all the values in the fleet/*.vx files to extreme values. An analogy to that would be when we compile for X86-64, we can specify `-mcpu` otherwise by default the compiler picks a conservative backend.
Vx allows one to define compute elements(number of cores, etc), memory elements (number of distinct memory elements, hierarchy if any) and their relationship (placement, ownership etc). Together they define the toplogoy of a machine. Toplogy goes into machine description files (see https://github.com/vx-lang/Vx/tree/main/fleet) and the compiler uses them to 'monomorphize' the program based on that topology.
> One Language, Every Chip [...] CPU, GPU, NPU [...]
Every chip? For example if I target an Intel Meteor Lake (I'm not picking a niche one), does it compile for this CPU, its integrated NPU and its Arc GPU?
Always nice seeing others arriving at similar conclusions! Those two jump out to me:
- "Most compilers hard-code a cost model. Vx reads one. A machine file describes the memory hierarchy and interconnect of a real part, and the compiler admits or rejects placements against it." I also designed it so that the target system is described by a single file that is picked up by the static analysis - cool!
- "Where data lives is part of its type" also doing that - when I got my project to an mvp state; I need to check out how vxlang does what it does: do they use a literal typesystem, or also compile checks outside of that? If its a type system, is it a dependent type system, or another flavor?
Yet another motivation to finally get my side project starting (forth-adjacent, many similar claims with regards to compile-time checks as vxlang; however, I still have to achieve that, while they already seem to have at least those and more in place; kudos to the vxlang team!)
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.
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)
Small nit: the PDP-11 critique is about C's abstract machine, not the hardware. IIRC the argument was that modern CPUs do tons of speculation and cache tricks that C hides from you. A new language "for every chip" doesn't obviously fix that either, but I could be wrong.
A bit tangential, but I really *really* appreciate them making this distinction, and wish more people did this. Way too many tools try to advertise themselves as all things for all people, catering to all use cases, and that helps nobody.