I agree with this point and cross-platform development is painful in C and C++. However, one of the reasons people use C and C++ is because of platform specific development. It turns out the platforms themselves are written in C.
For example, the "very deep standard library" for Rust can't do DNS TXT queries. On Linux, I run 'man res_query' [1] and get the documentation. Notice the Synopsis, that's C/C++ and the Linux specific code I write can use that.
Rust can also call these functions but there is an impedance mismatch between the safe world of standard rust and the unsafe calls to the system -- I imagine that a crate is a available to ease the pain of the 'unsigned char *answer'.
I am not making this comment to belittle Rust, I actually think it is a good and safe alternative to C++. However, there is decades of system development behind the C/C++ ecosystem and coming onto a C/C++ thread (about a package manager) and calling things a "shitshow" is not going to win people over.
Though I haven't used it personally, it seems like the trust-dns project is one such example:
I was mostly replying to this:
> However, one of the reasons people use C and C++ is because of platform specific development. It turns out the platforms themselves are written in C.
It's a higher bar than "just about any language supports abstraction". It fits more into a Pythonic world-view where there's a one-size-fits-all standard library mentality.
But it is as shitshow. Pretty much everything in system programming is a shitshow. From the moment you boot up a computer, it's just continous stream of bad ideas, lack of foresight, incidental architectures, hacks, bugs and workarounds all glued together with a duct-tape. That's what system development really is.
Everything we do in mainstream system computing is a shitshow. The fact that people are afraid to put any computer to handle public Internet traffic is a shitshow. It's a shitshow, everybody knows it's a shitshow and we even have whole mature industries sucking out a lot of money out of economy to deal with that shitshow.
Anyone that can't see it's a shitshow can't really be "won over". They will happily live their lives being quite skilled at navigating this shitshow, and repeating stuff like "UB is not a problem", "security bugs are only problem of bad developers", "modern C++ is mostly-safe", and so on.
The biggest shitshow... the meta-shitshow here, is how many people in systems development can't see it's a shitshow. They never ventured to investigate ideas from outside of the Unix/C/C++ bubble and tried to incorporate it into systems programming.
And just to be clear... Rust is not completely shitshow-free, and is just a small pocket of almost-shitshow-free environment in a vast shitshow ocean.
It's also quite problematic, in that this tends to create a lot of reliance on non-standardized compiler behavior and quirks.
> C++ might get there eventually with clang
I sure hope not! (and I appreciate clang). It's important and useful for there to be several compilers. Plus, if any compiler becomes the single standard one, then it definitely needs to be strongly "copyleft"ed, e.g. with a GNU GPL license.
Otherwise agree with the problems you identified.
While that may be a problem in other communities, with Rust there is a general aversion to undefined behavior. It is my belief that there will be more community pressure to fix quirks and such, and not depend upon them in general.
Ah, but it will be defined behavior - just implicitly defined.
But wait, are you saying that Go and Python are not serious languages?
I would call C a serious language. Its running your laptop, your phone, your car, the airplane you took on holiday, the fighter planes that protect your airspace, your washing machine, and if you are unfortunate enough to get seriously ill it will probably be running on the medical equipment that keeps you alive.
One of the reasons it is serious is because it is standardized and multiple implementations exist.
So if that's the criteria, then brainfuck is a serious language.
If one wants to use a tool in a life-critical system, a system that might be in use for decades they're going to reach for one of the said "serious languages": C, C++, Ada, etc. That list's very short and it includes neither Brainfuck nor Rust for that matter.
The point is: neither of those two datapoints is a particularly useful metric on how "serious" a programming language is and much less even a useful metric on how well it is suited to any given task. Even how mainstream programming languages are is not a useful signal for that. Javascript is very much mainstream, but I hope no one ever will want to program a cars ECU in a JS dialect. Specialized applications are almost by definition the realm of specialized languages.
Of course most rational engineering organizations wouldn't choose Brainfuck because it's harder to write code that other people can evaluate. But it's not automatically out of the question if you have a good reason for its use.
I did a fair bit of development in C, and developed hard real time systems in VHDL that did involve life & death, but, wouldn't call any language used in the industry generating value as a non serious language...
Off the top of my head I thought C++ and Ada. However, you mention VHDL which I agree with and somebody else pointed out Javascript which is also a good point. The Javascript example (along with C++) make the point that serious computer languages are not necessarily great languages.
I would argue that Rust is not a serious language (at the moment [1]) because its still young, there is no specification and if anything happens to the one implementation it would be a disaster.
Despite C being a null pointer minefield, if someone was to sue a developer the argument could be made that it is an industry standard. In the less likely event that a Rust program hurt somebody what are you going to say?
[1] https://users.rust-lang.org/t/is-there-a-plan-to-get-a-forma...
In practice, though, V8 is the serious impementation. The interesting thing about C and C++ is that I don't know if any given dev is using Clang, GCC, or MSVC until I ask him. I know a JS dev is using V8.
"The Rust development team isn't interested in supporting your obscure embedded architecture" or "sorry, this platform was phased out due to technical debt" is what I mean by not serious.
Look at Python and how any attempts to make alternative interpreter implementations ultimately failed. (And they at least have PEPs.)
> And they at least have PEPs.
Rusts language development has been guided by RFCs since like the beginning. There's no comprehensive standard as in "somebody went and wrote down the current state", but it's also not the case that there's no written spec of how things should behave. You could base a new compiler on that and there's actually developments to have different backends to rustc. Cranelift for example https://github.com/bytecodealliance/wasmtime/blob/main/crane...
> "The Rust development team isn't interested in supporting your obscure embedded architecture" or "sorry, this platform was phased out due to technical debt" is what I mean by not serious.
So any compiler team that stops supporting some sort of architecture because it's either rare or no longer worth the effort is not serious in your opinion? Like GCC, that has a decision making matrix for that? https://gcc.gnu.org/backends.html And dropped various architectures along the way?
The fact that a specific corporation has implemented a specific project by using a specific tool is completely meaningless as to the appropriateness of using that tool in another context.
> The fact that a specific corporation has implemented a specific project by using a specific tool is completely meaningless as to the appropriateness of using that tool in another context.
You're entirely correct. That's another goalpost move - nobody proclaimed that being used for business critical projects makes rust in any way magically fit for any and all other conceivable projects.
a) the fact that a corporation uses a language is meaningless and can't be used as an argument for anything - except maybe what to learn if you want to get a job there.
b) that all arguments based on Rust's novelty, call it "serious language" "mainstream language" or whatever - have merit. Rust is obviously not mature enough for many potential users and you can't convince them by talking about RFCs.
I disagree with you here. This is a low level production grade application in a domain that requires secure and stable operation. The fact that a team picked a specific language for this application demonstrates a certain level of stability and suitability for various problem domains. There are more examples of large scale rust codebases. That does not imply that rust is magically suited to all problems or that you should pick rust for your project at all cost and without further consideration, but it does mean that rust is used in “serious” projects that have significant monetary value attached to it.
> b) that all arguments based on Rust's novelty, call it "serious language" "mainstream language" or whatever - have merit. Rust is obviously not mature enough for many potential users and you can't convince them by talking about RFCs.
You’re again arguing against points I never made. Rust has no ISO standard - true. But the point I was responding to was “the implementation is the spec” and that’s plain false. The RFC is written first and the implementation is tested against the RFC. There is a written document that specified expected behavior. Sometimes you need to follow the chain if RFCs modify existing behavior and there’s certainly cases where the implementation doesn’t follow the RFCs, but it not like all c compilers are 100% spec compliant all of the time.
My understanding is that mostly CPython does whatever it wants and the other follows, but it is still better than a single implementation where the boundary between bug and spec would be nebulous.
The problem, rather, is that coders tend to ignore this, and write code that only works on CPython.
Except for C, for all intents and purposes every other major language basically has one authoritative compiler implementation.
C and C++ don't have bespoke build and module systems because it wasn't really a thing back when they were conceived, that's it. And bolting that stuff as an afterthought on top of existing, widely popular languages is extremely difficult.
Then you want to add a library that compiles fine on Fedora, but fails on ArchLinux, because they've moved some header file from `/usr/include` to `/usr/include/subdir`.
Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world.
Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
By the way, the fact that C doesn't use rich signatures is a problem, not a feature. C ABI can also be changed by using different compilation options, but the user won't even know it until the app explodes (crashes). At least C++ will emit a linker error in such case (sometimes, other times it will explode as well).
This is why pkg-config exists.
>Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
This sounds like a problem in such "package manager" or problem in the upstream build system.
>Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world
This is a valid point. Visual studio already has its own solution however. I personally avoid visual studio anyways, because it sucks for C.
>Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
These aren't really problems unless you rely only on the upstream build system. PKGBUILDs, nix recipes they can do their own thing.
One could, but no one has. That's the whole discussion, there are multiple partial implementations with limited adoption.
It's a nice thought but you have to be confident every 3rd party project you use is one whose parallel build you'll maintain as it updates. That's the strength of Cargo - it's the way to write Rust code & the maintenance is done by upstream for everyone.
Additionally Cargo's strength isn't just it's packaging & publishing system. Having a single Rust compiler that everyone uses on all platforms is powerful. C++ might get there eventually with clang but the ecosystem of libraries will need to support that as a baseline. Currently there's too many compiler or platform-specific hacks that are done to regularize the environment a bit whereas Rust generally does all of that under the hood for you (i.e. try writing any cross-platform BSD socket code - it's a total shitshow that basically results in Winsock & all other POSIX OSes basically different net stacks). Rust also comes with a very deep standard library for I/O, path manipulation etc whereas the C++ equivalents for all of this are still surprisingly lacking even in C++20 (especially on the network side).
[1] Based on manually counting the packages listed here https://wrapdb.mesonbuild.com/