Yeah, no. That is not a fair description of Rust. It's got far fewer mistakes than C++ and, get this, it has a mechanism for tentative features that can get revised and fixed based on usage experience. It doesn't always work especially for far-reaching decisions (I hear that async is considered problematic), but it prevents a lot of stupid mistakes that C++ is carrying along forever - with a few exceptions (e.g. garbage collection support, extern templates) and some very notable inclusions (the kind of botched module system, suboptimal unordered_map, std::string which is more of a byte/word array).
I like C++ because I like the fairly unique high performance low level feature set, not because I particularly like most of the detailed design decisions that went into it. Rust has the same goals, but is better thought out IMO. I'm sure that I will find some more trouble in Rust as I use it more, but so far the impression is quite good. I have become pretty good at writing C++ code that works after fixing one or two stupid bugs, and that works even better in Rust, mostly without the stupid bugs because you can't forget to null-check a pointer to another subsystem while starting up etc.
My description of the red herring that is Rust stands as written.
I also wasn't a fan of Python or Javascript back in the day, for very sound reasons that your type will always just brush away as meaningless, yet in time these languages have proven to be just as flawed as I always knew they were. And yes, C++ is garbage too, as I've also understood, but you don't want to hear me when I tell you Rust is NOT any kind of solution.
In fact it's a great big joke that is obvious with the least bit of actual analysis. Question: Rust is built on top of LLVM, which is written in which language? ___. Fill in the blank. Hint: it's the language that is supposedly going to be replaced by Rust. lol.
Rust, the language that is so obviously great the only way to put it everywhere is to force it on people; force it into the kernel against big objections from smart engineers, force it into the browser with the power of Google, force it into the heart of Mesa through writing a critical component in it, etc.
Sort of like systemd, right? So obviously great that people have to be forced to use it, until the old guard has died off or been silenced and all that's left is the brainwashed youth who never knew anything different. Same old tactics the liars and crooks always used to force their garbage down on people and make them think it was their own idea.
Always the herd marches in the direction its owners desire, while each individual creature thinks "his" ideas are truly his own and he himself decided which direction he is to travel in.
I've long had the experience of people "suddenly beginning to discover" things I clearly understood on day one, decades ago. I've also long had the experience of never being given any credit for my actual understanding, instead constantly being told I'm wrong, stupid, have no idea what I'm talking about, blah blah. This is exactly why I don't spend much time hanging out with the hoi polloi anymore. (You Are Here.)
You're naming and lambasting multiple different technologies and their communities without justifying why they are so bad. Few people use C without knowing about the threat of buffer overflows or invalid pointer dereferences, and C can be used productively in spite of these obvious flaws. Instead of trying to drive people away from what they do, if you seek understanding then you should allow others to justify their reasons. If you only test your understanding against your understanding, you're not making an assessment at all. You can find and talk to many smart people here and elsewhere, if you so desire.
You're saying "force into this and that" like there's some evil omnipotent entity compelling people to write Rust against their own free will lol. What do you mean by forced? People enjoy writing Rust, so hence it's being written in other projects.
Saying LLVM is written in C++ doesn't really bring much to the discussion. It was released 25 years ago, and C++ was released 40 years ago (hey, it's older than me lol). Rust was released like 10 years ago. So, yeah... I guess it makes sense that they used C++ back then? I'd have picked C++ back then too.
I've written C++ for about 15 years, and I don't have a blind hatred for the languge, but going back to it doesn't fill me with joy either, especially after having written Rust for the past few years.
The module system is more intuitive to use than the preprocessing file concatenation. There's also a nice package manager. I know some people find this a downside though, but I prefer it to fighting autoconf or CMake.
Syntax highlighting for Rust code doesn't lag 10+ seconds.
Symbol search doesn't require three different third-party tools to work.
Documentation is built in AND nice (no doxy doesn't count as nice, not in any universe).
Testing is built in. There's a (mostly) homogeneous build system
The borrowing rules are things you think about in C++ anyway, but Rust just makes it so you don't forget them; there's some clang lints that help with this in C++ anyway.
The syntax, while sometimes a bit noisy, is nicer in the average case, but C++ has been getting better in that regard.
There's much fewer API gotchas with Rust than with C++ (from the top of my head: closures, std::optional, std::variant, iterators, {a..z}values, a managerie of constructors, SFINAE, all these things have pain in the ass built in as a core principle). I also despise function overloading.
The macro system, while I don't like it too much in Rust, makes things
The type system in Rust is so much better it's not even comparable.
But anyway, Rust has some downsides. It requires you to change how you design solution sometimes. The compilation times are crap (but the compilers also does so much).
> You're saying "force into this and that" like there's some evil omnipotent entity compelling people to write Rust against their own free will lol.
No, I'm saying that you never had free will to begin with. It was always an illusion. Read Brave New World. You have never been in control of anything. You do the things you do, support the things you support, and buy the things you buy because you were told to do so. Very little to nothing of what you do was your own actual original idea. I don't care what kind of creative genius you imagine yourself to be; I know how you've been controlled your entire life by your media owners.
Rust "has some downsides"? In point of fact it is complete garbage. A joke of a language, that is in no way a suitable replacement for C or C++. This is what I'm trying to point out to you.
It's a joke in exactly the same way Tesla's Cybertruck is a joke. You think that is a real product, that is really meant to be successful? You call me a troll? The Cybertruck was and is a giant troll. I'm just telling you the unvarnished truth.
Can you really think of NO way in which every single programming language in existence today, including Rust, Zig, and everything else, can be described as total garbage? No? Well then maybe you need to step into the nearest cryo pod.
After you wake up in 100 years, look around and see if anything has improved. Yes? You see some kind of improvement in the status quo? Nobody's using Rust anymore, and in fact have long forgotten about it? Well then. I guess that means some other people must have had greater vision than you of what the future will hold, yes?
The military isn't going to allow C++ anymore due to it being a massive security hazard. You can't get away with buffer overflows, use after frees, data races, etc. forever.
Due to an evil entity called the military industrial complex, you are going to be using Rust in the future.
No, I just forked the last sane Linux kernel, because I was tired of the bugs and instability in 5.x and beyond. See, I like stable systems, not giant piles of increasingly complex garbage "maintained" by maniacs.
If you ever run into trouble with execution of JS slowing down your Qt/QML application, you are using way too much JS. The most common performance issues in decently written applications are rendering of invisible items aka overdraw (especially on very weak embedded SoC GPUs) and slow startup time. There is tooling to find these and ways to fix or improve them.
> The most common performance issues in decently written applications are rendering of invisible items aka overdraw
That's indeed what I found as well! Especially, these hidden items consume a lot of unnecessary RAM. What tools do you know for Qt/QML that can help with this issue?
For another perspective and more details, RenderDoc (or another frame debugger if you have one) is a nice tool as well.
Also don't use Rectangle { color: "transparent" }, use Item {}. An Item has geometry, but doesn't render anything. A transparent Rectangle probably also doesn't render, but it's still (at least slightly) more resource-intensive and makes you look like you don't know what you're doing.
Use Loader, StackView and visible liberally to disable stuff that isn't currently relevant. If unloading causes trouble with lost state, you may be carrying too much state on the QML side.
I make computers do things, but I never act like my stuff is the only stuff that makes things happen. There is a huge software stack of which my work is just the final pieces.
The problem with calling it “full stack” (even if it has a widely understood meaning) is that it implicitly puts the people doing the actual lower-level work on a pedestal. It creates the impression that if this is already “full stack,” then things like device drivers, operating systems, or foundational libraries must be some kind of arcane magic reserved only for experts, which they aren’t.
The term “full stack” works fine within its usual context, but when viewed more broadly, it becomes misleading and, in my opinion, problematic.
Or, alternatively, it ignores and devalues the existence of these parts. In both cases, it's a weird "othering" of software below a certain line in the, ahem, full stack.
And it's okay. It doesn't mean it should be this way for everyone else.
It is pretty common (and been so for at least two decades) for web devs to differentiate like so: backend, frontend or both. This "both" part almost always is replaced by "full stack".
When people say this they just mean they do both parts of a web app and have no ill will or neglect towards systems programmers or engineers working on a power plant.
In my German-speaking opinion, Zersiedlung is more about destruction of landscape than about fraying of settlements. You don't say that a village is zersiedelt, you do say that a landscape is zersiedelt.
You are right. "Zersiedlung" is a term of art in land-use and development planning to describe the undirected expansion of settlements into rural areas. I happen to work in the periphery of planning and approval and the term comes up quite often. The English equivalent would be the mentioned "suburban sprawl".
This "create a default-constructed value just so you can return a reference" logic is pretty terrible tbh. For insert: first create a default-constructed value, then assign to it. For retrieval: in the not found case, (permanently) insert a default-constructed value into the map. Need to return a valid reference!
Qt containers do it better: upsert with insert() and retrieve with value(), which, in the not found case, will return a default-constructed value (or a caller-supplied value) but without inserting it into the map.
I keep being puzzled by the unwillingness of developers to deal with scheduling issues. Many developers avoid optimization, almost all avoid scheduling. There are some pretty interesting algorithms and data structures in that space, and doing it well almost always improves user experience. Often it even decreases total wall-clock time for a given set of tasks.
reply