Hacker News new | ask | show | jobs
by hsn915 1772 days ago
People focus too much on the SoA thing as if it was the whole point of the language, but it's really really not.

Jon does a lot of programming streams, and I think anyone who watches his programming streams will recognize that "structure of arrays" is not the default mode that he usually programs in.

That's not even the point of the language.

Yes the language does a lot of what you expect from a modern systems language: structs, explicit memory allocation and management, no header files, etc.

But as far as I can tell, this is just the bare minimum that you should expect from a modern systems language, and the ultimate goal of this language is not to just be that.

The best way I can think of to describe it is collapsing layers into just one: the language and its compiler.

This is why the language has meta programming and code generation built in.

I've seen talks where people boast about how they use a python script to generate a whole lot of C++ code!

I've seen projects written ostensibly in C++ but to build them you need download 10 different tools (including compilers or interpreters for other languages).

Big C++ projects are notorious for being a nightmare to build.

The point of this language is to make it so that you only need one thing: the compiler of this language.

You can write a large system program that builds very quickly and does not need any extra tools to build.

Ultimately even the linker would be deprecated: the compiler would output the executable file directly. But for practical reasons the language has to support linking in order to interop with C libraries.

2 comments

Oh for sure, build is the main point and SoA isn't. The SoA feature discussions probably came from its deprecated interesting approach.

Collapsing into a single layer is great. As an aside, another language notorious for doing so would be Smalltalk, which is on the complete opposite end of the spectrum in terms of paradigm. It's kinda interesting to see the horseshoe theory in action in software philosophy.

Thanks for the great explanation. Do you know how it plans to handle dependencies? Is it expected to work on embedded platforms like Cortex-M?

It's nice seeing a mix of modern systems languages: Zig, Rust, Jai. All seem very well designed and promising.

I don't really know .. these are just guesses:

- I think it will not support any platform that is less than 64 bits.

- I think the preferred way will be to explicitly host the dependency in your repository. What ever the language does to help with dependency management will probably be geared towards that direction. Code bases are expected to be self contained. Once you checkout the code from your version control system, you should not need to download an additional thing from the internet to build.

That said, there is a video where Jon talked at length about his plans for dependency management, but it was more of an information discussion than a concrete plan. It is from 3 years ago (2018.01)

https://www.youtube.com/watch?v=3TwEaRZ4H3w