When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant.
And to be fair, YAML is somewhat clean for what it is. I shouldn't have included that in my rant either. My main gripe is with the "JSON Everywhere" approach. :)
There's no one-size-fits-all solution to anything. If one is using JavaScript—great, use JSON as a way to transmit objects over the wire or unpack an object into a template. Just PLEASE do not use it for a configuration format. Visual Studio Code configuration is a nightmare of ugliness.
Generally there is misunderstanding of these markups. JSON came along because the JavaScript people found it convenient and more network-efficient (the irony being it's not really). But a million years later followed the schema-validation logic to back-fill deficiencies.
In my opinion, one should go for XML when writing a portable document format of any variety to allow a vast array of schema validators, linters, and so-forth. This makes writing plugins which target a given schema much more portable and easier to write.
It's kind of ridiculous how many times web folks reinvent the wheel. Seriously, get rid of YAML, TOML, JSON. We already had INI, XML/XPATH/XSD.
There's nothing wrong with XML, people are just lazy and so is JSON. It's the lazy, sloppy cousin of XML which was a well-thought-out standard to fill a deficiency in HTML for data.
Honestly though, we should be using something like this:
http://openddl.org/
As other folks have commented, CUDA not being an open standard is a large part of the problem. That and the developers who target CUDA directly when writing Stable Diffusion algorithms—they are forcing the monopoly. Even at the cost of not being able to squeeze every ounce out of the GPU, portability greatly improves software access when people target Vulkan et al.
Remember we are talking about putting it into the core OS and overall what will the impact be on the stability of said OS. What folks here tend to describe is userspace applications which languages like Go/Java/C#/Erlang/Etc... already solve. In fact, most banks probably already use safer languages for the bulk of the workloads and it works just fine.
I want to point out one more thing: Rust is not a simple language by any stretch. It's equal to in complexity to C++ (yet without decades of established "good practices"). It is much preferable to have an easier to understand core and move the complexity outward—for improved stability and robustness. The core OS by nature of what it does needs to access raw resources in an "unsafe" manner. Rust kernel code will be littered with unsafe blocks and unnecessary complexity.
Rust is not immune to security vulnerabilities. And at the end of the day, social engineering will steal more data than "hacking the mainframe". Why break in when you can just ask to be let in?
OpenBSD has a great security track record because they resist excessive change and prefer simplicity. For those who want to add Rust to the core of FreeBSD my primary question: is it really necessary? Or is it just because a bunch of Rustaceans want to?
Honestly, after being in the software industry for a couple of decades and seeing how many times folks attempt to reinvent the wheel (for commercial or other reasons), I am beginning to sigh when I see how many language zealots there are (not you, just in general). The reality is, Rust does not need to replace everything. Nor should it be held on some kind of pedestal.
E.G. Curiosity rover is doing just fine running on millions of lines of C.
If it's going to impact OS stability and decrease performance and portability of the humble, dependable, simple C, it doesn't belong in the core. C is better than Rust for OS development.
I recommend taking a look at Autotools—if anything for historical context. It quickly becomes apparent that many features in CMake (and likely meson—no experience there myself)—are derived from some functionality in Autotools. It also helps one appreciate the package maintainers role in the software development lifecycle, as many of the GNU coding standards have influenced software packaging/distribution—be it RPM, Deb, Pacman, etc.
While there is certainly value in using CMake (as so many projects have chosen it as their build system)—it also becomes a sort of cautionary tale whence projects try to reinvent the wheel to fix some deficiency, only to build a complex system with it's own set of deficiencies. Obviously, part of this is due to the fact that commercial entities (cough Microsoft) deviated from any sort of standards-based approach to building software.
But for every build-configuration system, Autotools seems to be the only one which dictates that a developer machine merely have POSIX tools installed. Nowadays, that's all the big players, considering that MSYS2 on Windows is better than ever. And it supports many languages to boot: C/C++, Objective C/C++, Go, Fortran, Erlang.
Funny to mention cmake when GNU Autotools handles all of these dependency resolution with grace using only a few lines of autoconf.
CMake script syntax is not very great, and debugging is no better than sprinkling printf's throughout... So, why not use Autotools? /bin/sh has been the norm for most build processes, to the point where the later-designed YaML syntax is _effectively_ the SAME as a Makefile with /bin/sh statements running the pipeline procedures.
CMake came along and tried to fix complexity in Autotools while adding kitchen-sink baggage along the way.
> My recommendation is this - decide if you want to make a company, or if you want to make Open Source. The number if places that have succeeded in both is vanishingly small.
The issue at hand is more about deciding how OTHER people/companies may or may not use your source-code to suit their own needs. If you decide Open Source, someone else can easily decide: actually, Company (and free labor to boot).
But to your point, in the long term, Open Source is a better prospect (for the people not the companies). Think of all the problems with crappy IoT devices and bad security practices. Many devices _could_ have decades of life left in them, only to be bricked because the companies want to sell newer crap instead (for the companies not the people). And on-and-on.
I think the whole idea of a new licensing model is a good starting point—like a forced NDA to keep a head-start. However, the same problem holds: nothing will prevent someone from stealing the source code either way—one license or otherwise—if it is freely available. But if there is a large community of contributors, the value prospect for everyone is huge.
And, to top it off: now with AI—how can we prevent an AI from rewriting the sources in a way that appears "nothing like the original"?
Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh