This is a bit like saying everyone would be a bit less jaded if the plane staying in the air wasn't hung over the Boeing 737 MAX 8 designer's heads by certain communities and used as an existential threat to the company.
Doesn't modern C++ offer the ability to write memory safe code? The primary distinguishing difference from Rust, on this front, is that Rust is memory safe by default (and allows them to override memory safety with code that is explicitly declared as unsafe) while C++ requires the developer to make a conscious effort to avoid unsafe code (without providing facilities to declare code as safe or unsafe). While this means that C++ is problematic, it does not make Rust automagically safer - particularly when interfacing with C/C++ code (as would be the case when interfacing with Linux syscalls or most C or C++ based libraries).
I guess what I'm saying is that Rust is great when dealing exclusively with Rust libraries since it is either memory safe by default or because it is easier to audit (since it is either declared explicitly or implicitly as unsafe). On the other hand, it is not guaranteed to be memory safe. While this may sound like nitpicking, the distinction is important from the perspective of the end user who is unlikely to ever audit the code yet may be swayed by being told that it is written in a memory safe language.
> C++ requires the developer to make a conscious effort to avoid unsafe code
The problem is much worse than how you put it. I've written C++ for more than a decade and it's painful to constantly having to worry about memory safety due to enormous complexity of the language. Even if you are super diligent, you will make a mistake and it will bite you when you expect it the least.
Relying on clang-tidy, non-default compiler flags, sanitizers and other tools is not only not enough, but a constant source of headache on how to integrate them with your build systems and project requirements.
Admittedly, I am more of a hobbiest when it comes to C++ development. I try to keep track of things, but I started learning the language before it was standardized and I switched to other languages shortly after it was standardized (never mind the introduction of memory safe option in the standard libraries, which occurred in the 2000's). That said, memory safety has been a consideration, and a feature, for nearly 20 years now. It seems to me that people should have been taught how to approach it for nearly 20 years now. Sure, you can break the rules. Sure, anyone working with older code would have been exposed to bad code. Yet it shouldn't be a universal problem unless people are deliberately seeking out shortcuts (since writing memory safe code in C++ is messier than writing unsafe code).
All languages offer the ability to write memory-safe code. It's just that doing so is very difficult in C and C++. The benefit of Rust isn't really the assurance of safety that's provided by not using the `unsafe` keyword. After all, pretty much all Rust programs do use the `unsafe` keyword. The benefit of Rust is a combination of many design decisions that make it easy to write safe code.
For example, everyday operations in Rust are almost all defined. But in C++, it is extremely easy to run into undefined behavior by accident and make your code do something bizarre. On the practical side, I have never ever gotten a segfault when writing rust, but have many times in C++.
I think one of the fundamental differences in the SOTA C++ approach to memory safety (eg. extending unique/shared_ptr) and Rust is that C++ doesn't try to enforce having a single mutable reference to a variable and it still relies on strict aliasing heuristics, and so cannot claim to be fully deterministic.
Still, use after free, and memory leaks should be impossible.
It'll still let you do a bunch of stuff Rust doesn't, which is up to the programmer to decide whether this is good or not.
Doesn't modern C++ offer the ability to write memory safe code?
Can you name an example of a non-trivial C++ program that's memory safe? The only examples I can think of went to extraordinary lengths with formal methods and none of them are widely used.
> to the point of Ada being mandated by law in certain niches.
> And then Ada software caused the loss of US$370 million with Ariane 5.
This seems like a bit of a non-sequitur? Ariane is an EU rocket and the flight you're referring to was carrying an EU payload, and I don't think it was ever subject to the US DoD Ada mandate or an EU equivalent (which I'm not sure ever existed?).
(Also a bit of a nitpick, but I don't think the US DoD Ada Mandate was a law per se; it was a DoD policy and not something the US Congress passed).
It's probably somewhat disputable as to whether the Ariane failure was "due to Ada" or whether other higher-level concerns were responsible (e.g., reusing the Ariane 4 software without revalidation)
If you're writing C/C++ and you don't care about memory safety, you're taking one of a few possible positions:
1. "I don't care what my program does."
Why write it though?
2. "I don't care what the standard says, I've put text into a compiler and it gave me a binary that does the thing."
What if you want to put the same text into a different compiler in the future, or the same compiler again? Are you certain the binary is going to continue doing the thing? Have you even fully tested the binary?
3. "I use a special runtime that makes memory unsafety defined again."
One, I don't believe you unless you're part of a very small group of people and two, why are you accepting the serious drawbacks (performance, process death, all the broader issues of UB) that come with this?
It's genuinely hard for me to understand why you wouldn't think memory safety is important Don't you want to write code that's portable and correct? Don't you want to execute other people's programs and trust they won't segfault? Doesn't it frustrate you that the language committees have spent years refusing to address even the lowest-hanging fruit?
Google is a somewhat widely known place where promo is a huge problem, but the problem isn’t particular to Google. Generally companies will require you to repeatedly “prove” you are worth the additional compensation before agreeing to it. The friction varies, but the structural incentives are always there. Therefore if the goal is to maximize earnings, and assuming you are a high performer, it’s in your best interest to job hop once in a while.
To not play this made-up game, you either decide to stop caring about compensation, or be your own boss. Of course these are not always realistic depending on one’s life situation.
There's a third way. Think about maximizing salary to effort ratio instead of total salary. It might be the case that lower position has better ratio. Quiet quitting where people do bare minimum not to get fired is essentially this theory put into practice. You want to avoid a situation where you're rich but too stressed out to do anything with that money.
This is me, within limits of course. I work on 90% contract, having 10 weeks of paid vacation and sure as hell try to use that to the fullest.
Life is too short to focus on stuff that would lead to deep regrets later. I dont know about you guys but focusing all the time on money and career certainly feels like one, IT engineering is too successful to really have the need to behave so, so it becomes a choice.
I do focus on those but in short bursts and them coast the results for long time. Ie push through some boundary (lengthy acquiring of property, planning and realizing big reconstruction, naturalization process for me and family etc). I never grokked the 'completionist' mindset as a default one, its endless toil and unhappiness in big corporations.
I feel this is easier if you treat day jobs almost as a side hustle and have significant hobbies and life elsewhere. It’s more difficult if your career heavily overlaps with what you love doing (e.g. software), except the career comes with unwanted things like politics, promos, managing others, etc.
I think this pattern of "under promotion" is probably common is all highly competitive industries with large wealth corps. Think: Investment banking ("high finance"), oil & gas, big tech, law firms, consulting, etc. When I think about the sheer number of insanely talented people trying to get in, it conjures the World War Z image of zombies trying to get over the walls. With some perspective in my industry, I constantly remind myself: There are many, many more people outside my office that can do my job -- probably better than me. I need to constantly remind my employer why I am good. (Yes, it is exhausting.)
My new job title says "senior". It means nothing within the company except a 5% pay bracket or something, but I don't have to tell the next company that. I understand this is the mechanism by which titles result in money.
I wish Google would open source their gtl library. Similar utilities exist elsewhere but not in the same consistent quality and well-integrated package.
I particularly like the “what to do for flat profiles” ad “protobuf tips” sections. Similar advice distilled to this level is difficult to find elsewhere.
Honest question. Why is a Rust rewrite of coreutils getting traction? Nobody thought it’s a good idea to rewrite coreutils with Go, Java, Python, C++, etc etc. It can’t just be memory safety.
> uutils coreutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.
> Our key objectives include:
> Matching GNU's output (stdout and error code) exactly
> Better error messages
> Providing comprehensive internationalization support (UTF-8)
> Improved performances
> Extensions when relevant (example: --progress)
> uutils aims to work on as many platforms as possible, to be able to use the same utils on Linux, macOS, Windows and other platforms. This ensures, for example, that scripts can be easily transferred between platforms.
Experimenting with better error messages, as test-bed for extensions that might not be able to be tried or accepted in GNU coreutils (for technical, social or other reasons), and being able to use the same tools in all major OS are very reasonable divergences from GNU's project to "justify" its existence.
The project was originally just a learning project for someone who wanted to learn Rust by reimplementing tools that were small, not a moving target and useful. From there, it grew as it found an audience of developers interested in productionalizing it. There have been coreutils ports for the languages you mention (go-coreutils, pycoreutils, coreutils-cpp, etc.), they just didn't (yet?) hit critical mass. It is a harder sell for GC-based projects in this case because they are unlikely to ever be included as part of a dirtribution's base. Lets not forget that coreutils themselves are a rewrite of previously existing tools to begin with.
Given the site where this is posted and the screenshot, is the author an engineer turned fiction writer? Kudos if true. Posting these must take a lot of courage.
As a former employee, the engineering culture at Google gives me old-school hacker vibes, so users are very much expected to “figure it out” and that’s somewhat accepted (and I say this with fond memories). It’s no surprise the company struggles with good UX.
LLMs are good at in-distribution programming, so inventing a new language just for them probably won’t work much better than languages they were already trained on.
If you could invent a language that is somehow tailored for vibe coding _and then_ produce a sufficient high quality corpus of it to train the AI on them, that would be something.
Interestingly it became most painfully clear to me once I started working in an office in a developed country. Something about seeing the scale of it all. But I take your point.
reply