As part of the "all software should be liable brigade", it is a matter of misplaced goals after the cybersecurity agencies started looking into the matter.
I has been served for several decades, however since the late-90's many decided reducing to only C and C++ was the way going forward, now the world is rediscovering it doesn't have to be like that.
Thing is, those safety checks are also available in C and C++, provided that one uses the right tools like PVS and PurifyPlus (just to quote two examples), and now ongoing AI based tooling efforts for verification, thus the question is why a language like Zig in the 21st century, other than "I don't like either C++ or Rust".
> It has for Amazon, Adobe, Microsoft, Google and the Linux kernel.
I don't think so. I don't know about Adobe, but it's not a meaningful statement for the rest. Those companies default to writing safe code in languages other than Rust, and the Linux kernel defaults to unsafe code in C. BTW, languages favoured by those projects/companies do not reliably represent industry-wide preferences, let alone defaults. You could certainly say that of the two languages accepted so far in the Linux kernel, the only safe one is Rust, but there's hardly any "default" there.
> It remains to be seen which big name will make Zig unavoidable.
I have no idea whether or not Zig will ever be successful, but at this point it's pretty clear that Rust's success has been less than modest at best.
It is a clear mandate on those companies that whatever used to be C or C++, should be written in Rust for green field development.
Whatever could be done in programming languages with automatic memory management was already being done.
Anyone deploying serverless code into Amazon instances is running of top of Firecracker, my phone has Rust code running on it, and whatever Windows 11 draws something into the screen, it goes through Rust rewrite of the GDI regions logic, all the Azure networking traffic going through Azure Boost cards does so via Rust firmware.
Adobe is the sponsor for the Hylo programming language, and key figures in the C++ community, are doing Rust talks nowadays.
"Adobe’s memory safety roadmap: Securing creativity by design"
> It is a clear mandate on those companies that whatever used to be C or C++, should be written in Rust for green field development. Whatever could be done in programming languages with automatic memory management was already being done.
I don't know how true either of these statements is or to what extent the mandate is enforced (at my company we also have language mandates, but what they mean is that to use a different language all you need is an explanation and a manager to sign off), but I'll ask acquaintances in those companies (Except Adobe; don't know anyone there. Although the link you provided doesn't say Rust; it says "Rust or Swift". It also commits only to "exploring ways to reduce the use of new C and C++ code in safety critical parts of our products to a fraction of current levels").
What I do know is that the rate at which Rust is adopted, is significantly lower than the rate at which C++, Java, C#, Python, TS, and even Go were adopted, even in those companies.
Now, there's no doubt that Rust has some real adoption, and much more than just hobby languages. Its rate of adoption is significantly higher than that of Haskell, or Clojure, or Elixir were (but lower than that of Ruby or PHP). That is without a doubt a great accomplishment, but not what you'd expect from a language that wishes to become the successor to C++ (and doesn't suffer from lack of hype despite its advanced age). Languages that offer a significant competitive advantage, or even the perception of one, spread at a faster pace, certainly those that eventually end up in the top 5.
I also think there's little doubt that the Rust "base" is more enthusiastic than that of any language I remember except maybe that of Haskell's resurgence some years back (and maybe Ruby), and that enthusiasm may make up for what they lack in numbers, but at some point you need the numbers. A middle-aged language can only claim to be the insurgent for so long.
>>It is a clear mandate on those companies that whatever used to be C or C++, should be written in Rust for green field development.
>>Any hobby language author would like to have 1% of the said modest Rust's success, I really don't get the continuous downplay of such achievement.
This is a political achievement, not technical one. People are bitter about it as it doesn't feel organic and feel pushed onto them.
> Anyone deploying serverless code into Amazon instances is running of top of Firecracker, my phone has Rust code running on it, and whatever Windows 11 draws something into the screen, it goes through Rust rewrite of the GDI regions logic, all the Azure networking traffic going through Azure Boost cards does so via Rust firmware.
Ignoring it doesn't make those achievements political rather than technical.
While certain teams within Google are using rust by default, I'm not sure rust is anywhere close in scale for new lines of code committed per week to c++.
It's still 100% pure Gentoo (and actually these days even vanilla Gentoo itself offers precompiled binaries) so you still can compile things in rare cases that binary isn't already compiled with use/config that you want.
That’s mostly why I build system images in CI; my slowest builds (qemu user mode emulation of aarch64 for e.g. raspberry pi boards) can take multiple days so I just declared myself a 1 week window between updates and then just pull in the changes via rsync. I even boot the images with qemu as part of the testing cycle. At some point I might try building and hosting prebuilt bins like gentoo does now, I don’t use those though because I explicitly want to build everything from source.
Absolutely! In a way it's really cool you can go to ACM archives and start reading from something like
https://dl.acm.org/doi/10.1145/563858.563893
(Blinn, Models of light reflection for computer synthesized pictures)
and then track forward from there.
But the developments in the field have mostly been motivated by "I think this looks better than that" followed by a formal mathematical model. The aesthetic aspect has been far more impactful in driving development than drive for technical precision as such.
"Does it look good" is far more important metric than displaying graphs with error bars.
This is not to say the field _isn't_ extremely technical. It is! But the main motivation for all developments has been aesthetic - hence it's IMHO almost as hard to learn computer graphics by just reading about it as it would be to learn something like academic oil painting just reading about it.
"In the center of the display, images reconstructed from filters with random values of (B, C) were displayed ... Nine expert observers took
part and over 500 samples were taken...It would not be credible to suggest that a single ideal parameter pair can be deduced from subjective testing"
So they basically did kernel fitting based on what looks good - while the theory of the kernel function itself was more technically motivated.
But arenas have substantial benefits. They may be one of the few remaining reasons to use a low-level (or "systems programming") language in the first place. Most things are tradeoffs, and the question isn't what you're giving up, but whether you're getting the most for what you're paying.
First, Zig is more modern than any of the languages you mention. Second, I'm not aware that any of those languages offer arenas similar in their power and utility to Zig's while offering UAF-freedom at the same time. Note that "type-safe" arenas are neither as powerful as general purpose arenas nor fully offer UAF-freedom. I could be wrong (and if I am, I'd really love to see an arena that's both general and safe), but I believe that in all these languages you must compromise on either safety or the power of the arena (or both).
"modern: relating to the present or recent times as opposed to the remote past". I agree it's not a useful concept here but I didn't bring it up. Specifically, I don't think there's any consideration that had gone into the design of D, C#, or Rust that escaped Zig's designer. He just consciously made different choices based on the data available and his own judgment.
Not really modern, it is Object Pascal/Modula-2 repackaged in C like syntax.
The only thing relatively modern would be compile time execution, if we forget about how long some languages have had reader macros, or similar capabilities like D's compile time metaprogramming.
Also it is the wrong direction when the whole industry is moving into integrity by default on cyber security legislation.
There are several examples around of doing arenas in said languages.
> Not really modern, it is Object Pascal/Modula-2 repackaged in C like syntax.
That's your opinion, but I couldn't disagree more. It places partial evaluation as its biggest focus more so than any other language in history, and is also extraordinarily focused on tooling. There isn't any piece of information nor any technique that was known to the designers of those older languages and wasn't known to Zig's designer. In some situations, he intentionally chose different tradeoffs on which there is no consensus. It's strange to insist that there is some consensus when many disagree.
I have been doing low-level programming (in C, C++, and Ada in the 90s) for almost 30 years, and over that time I have not seen a low-level language that's as revolutionary in its approach to low-level programming as Zig. I don't know if it's good, but I find its design revolutionary. You certainly don't have to agree with my assessment, but you do need to acknowledge that some people very much see it that way, and don't think it's merely a "repackaged" Pascal-family language in any way.
I guess you could say that you personally don't care about Zig's primary design points and when you ignore them you're left with something that you find similar to other languages, but that's like saying that if you don't care about Rust's borrow- and lifetime checking, it's basically just a mix of C++ and ML. It's perfectly valid to not care about what matters most to some language's designer, and it's perfectly valid to claim that what matters to them most is misguided, but it is not valid to ignore a language's design core when describing it just because you don't care about it.
> Also it is the wrong direction when the whole industry is moving into integrity by default on cyber security legislation.
Again, that is an opinion, but not one I agree with. For one, Rust isn't as safe as other safe languages given its relatively common reliance on unsafe. If spatial and temporal memory safety were the dominating concerns, there wouldn't be a need for Rust, either (and it wouldn't have exposed unsafe). Clearly, everyone recognises that there are other concerns that sometimes dominate, and it's pretty clear that some people, who are no less knowledgeable about the software industry and its direction, prefer Zig. There is no consensus here either way, and I'm not sure there can be one. They are different languages that suit different people/projects' preferences.
Now, I agree that there's definitely more motion toward more correctness - which is great! - and I probably wouldn't write a banking or healthcare system in Zig, but I wouldn't write it in Rust, either. People reach for low level languages precisely when there may be a need to compromise on safety in some way, and Rust and Zig make different compromises, both of which - as far as I can tell - can be reasonable.
> There are several examples around of doing arenas in said languages.
From what I can tell, all of them either don't provide freedom from UAF, or they're not nearly as general as a proper arena.
I know of one safe and general arena design in RTSJ, which immidiately prevents a reference to a non-enclosing arena from being written into an object, but it comes with a runtime cost (which makes sense for hard realtime, where you want to sacrifice performance for worst-case predictability).
Wouldn't C# and Swift make it tough to integrate with other languages? Whereas something written in Zig (or Rust) can integrate with anything that can use the C ABI?
It's harder than you'd expect. Depending on what kind of bucketing an arena does (by size or by type), a stale reference may end up pointing to another piece of memory of the correct type, which is still wrong, but more subtly than a crash.
Xfce is what I settled on, when still using GNU/Linux desktops.
I used a multitude of UNIX environments since 1994, starting with IBM X Windows terminals connected to DG/UX, and thanks to the way Unity got dropped, the way GNOME 3.0 went down, windowmaker no longer being actively developed, Xfce it was.
From where I am standing it feels more like bug fixing than anything else, like it was back in the 2000's, when I used to see what were the new WINGs coming out, and play around with GNUStep integration.
reply