Ron Minsky started a thread asking about Zig, relating it to OxCaml. I thought the community might be interested.
do you mind posting the text, or screenshots, for those of us that dont want to touch x…
6 Likes
He used to repost on Bluesky, unfortunately could not find the same thread there. Here’re the screenshots:
1 Like
I replace “x.com” with “xcancel.com” (and “youtube.com” with one of the Invidious instances
4 Likes
80+ million lines of code and 1,500 developers.
Nothing good can come from that.
5 Likes
The focus on memory safety makes sense for so much code with so many developers.
But to discourage non memory safe languages for anything where security matters is very lacking in nuance. When you have other strong requirements such as performance/memory footprint/binary size/etc, memory safe languages often struggle with that. Mostly due to how restrictive they are with what they let you do safely.
And while zig lets you write memory unsafe code, it is able to catch some things at compile time, some things at runtime, and provides either its own tools, or integration with existing tools to catch the rest.
Thats pretty much the next best thing for safety, while still giving you the flexibility to meet other strong requirements.
It is also worth mentioning, the zig team want to make zig as safe as possible and practical. There are a number of safety features being worked on atm.
2 Likes
I’d argue that’s because “automatically managed memory” languages are ceding too much ground to “manual memory managed” languages.
If I have to haul out C/Zig/Rust/C++ it’s because every other programming language has failed and has some giant glaring fault for my problem.
For me, Zig wins the moment “C interop” matters. And “C interop” matters WAY more often than everybody else who writes programming languages thinks. If I can’t do the moral equivalent of @CImport and have it grab, wrap and compile my C code, we’re done. If I can’t just “git clone” and compile on Windows or Linux, we’re done. etc.
This is a nice example of the issues that managed memory systems like OCaml have when confronted with interoperating with a C library like Vulkan:
There is no inherent reason why these problems exist for OCaml other than nobody has sat down to work out what the solutions should be and then implement them. By the same token, since nobody feels the need to solve them, they then do become a problem with the language.
4 Likes
In their domain you need to let developers iterate broadly and swiftly to maintain an edge in the market. At the same time, performance is critical. Most of their competitors are C++ shops.
My impression is their goal for a language is one which is expressive and safe by default, such that 1400 out of 1500 can chuck away at it and then, instead of having to refactor the output later on to C++ „to get to production“, they can „opt-in“ to less safe but more performant aspects of a language - ideally explicitly such that the maintainers know where to tread more carefully (similar to Lattners „progressive disclosure of complexity“). Then the question is: which features facilitate such a language, and how can these features be designed to be ergonomic?
My impression from previous posts is that they explored Rust, admitting that most of their desired features are available, that the design is ultimately not ergonomic enough for them to warrant adoption, and rather push for OxCaml. I think a lot of Zig devs seem to sympathize with this.
Now the Zig question seems to come from the opposite side, seeing the elegance in the design but, not having it fully explored yet in terms of features or how type safety issues are addressed (where the most likely answer is, they are not).
Naturally all of these statements are reductive and I have no idea what’s really driving those questions but that’s how it appears to me from an outside perspective.
2 Likes
JaneStreet chose OCaml in 2002. D pops out in 2001. Scala pops out in 2003. F# is 2005. Rust doesn’t appear until 2010. By that time JaneStreet had been using OCaml for almost a decade.
Rust would have to offer some very compelling reasons to throw out the codebase and expertise they had by that time.
That’s why I think WUFFS is a quite interesting project.