Already at this point I'm hoping that I never need to write C++ again, as the complexity of the language is maddening and only increasing.
(I've only spent a few days on Zig and it was also a very fresh breeze).
If the curve is small moving from A to B can make a lot of sense. Rust is an obvious possible successor.
But as the curve gets bigger maybe looking at less obvious choices makes more sense. Maybe even a language with a runtime or VM like Java if you’re not doing low level programming like Google is in this post.
Swift is a strawman here. I know it’s probably not there for large non-Apple adoption today, but pretend it was
If you want to develop a library, you might have to dig into more complicated features in order to provide a convenient interface for users.
If you want to build an API, using a web framework is simple and doesn’t require understanding the more complicated parts of the language.
Can you point me to where I said or suggested any of that?
Rust generally has a lot of what C has, you just might need unsafe to get it.
One notable omission is `volatile` but that sorta beside the point.
If the concern is just relearning a new STD lib and getting used to error handling with an enum instead of ints, then I suspect you could get up to speed pretty quickly.
Past that, sure the rust crate ecosystem might make use of a lot more complex bits of rust, just like C++ libraries can do wild things with templating.
If you are just comparing C, just avoid the complex stuff and write your Rust function like you write your C functions. It’ll work.
What do you mean here?
Rust hasn't replaced all the C I write, why should it? It's replaced lots of C I wrote around the periphery of the hairiest stuff, and frankly done it better than the C I might otherwise have written there.
I’m genuinely glad that was your experience!
I actually would love for more C programmers to have that same experience (or better), but my own experience with Rust and the experiences of many of my colleagues is that going from C as someone who’s productive with it to Rust entails at least a couple months just to get comfortable with the language and its semantics.
One could argue that spending that time is worth it for the memory safety benefits and I’d probably agree, but I’m just pointing out that it’s a pretty hard sell for many C programmers.
What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating?
Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues?
I think the bigger issue is convincing people it’s worth the energy and risk to port existing, working, and tested C code.
People who still use C rather than C++, which has this exact feature?
https://open.substack.com/pub/ryanfleury/p/untangling-lifeti...
"This, of course, does not eliminate all possible bugs (misuse is still possible, and often not checkable in a language like C++)—so, this idea is often paired in newer languages with heavier (and more complex) compile-time checking features, which attempt to both automate this code generation, and prohibit misuse."
I’ve been through my Rust hype phase, and I’ve been through thoughtfully applying it for web services and a greenfield messaging broker, albeit nothing systems level. With a decade or so C++ behind the belt, I don’t feel an app team is necessarily more productive over the lifecycle of the project if they pick Rust over C++, much less so if they pick it over Java.
I’ve been doing mostly low-latency JVM projects. I can extract better performance from a JVM and a given infrastructure than from Rust. Ease of development and the option to delegate the lifetimes to the GC, or just get a huge heap, is often the escape hatch you need to make through the tight deadline.
In Rust, you need just one “smart” colleague to make the project unmaintainable - wasting everyone’s time on optimizing the type signatures making it thereby impenetrable to anyone outside the team, or easy to forget the derivation a few months later on.
There was a nice suggestion on HN somewhere to distinguish between an area beneficial particularly to Rust (slow pace, settled architecture, more low-level) as opposed to the area with fewer fruits to reap for Rust where other semantics prevails.
I think it's great that you can build solid projects efficiently in C++ or Java! People should be free to choose whatever works best for them; as someone who does love Rust I'm of course happy to see it gaining traction, but if the flavor of the month were to suddenly change I don't think I'd feel the need to go out of my way trying to tear the new thing down.
In fact, there are lots of arena/bump allocator crates! It's not a negative point for Rust, but it solves a problem this author doesn't have.
>
> Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues?
Those are some nice strawmans, but ignoring the fact that this type of response very clearly goes against HN’s guidelines, I think it’d be great if you addressed the point I actually made instead of your own.
Also, I’d like to make it clear that you’re perfectly entitled to believe this problem I highlighted doesn’t exist and is somehow a figment of my imagination. I’m just sharing my perspective and experience. You’re free to take it or leave it.
My point is, most of them already know a lot of the semantics. It’s the semantics they keep in their head while trying to be safe in C!
As for the HN guidelines. Sorry if you felt like I crossed a line. Never my intention.
I didn’t feel like you crossed a line—according to the HN guidelines [0], you very clearly crossed a line.
You responded with snarky strawmans instead of responding, in good faith, to the actual point I made.
To quote the guidelines:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
>
> My point is, most of them already know a lot of the semantics. It’s the semantics they keep in their head while trying to be safe in C!
The most fascinating aspect of interactions like these is that I’m literally sharing the real life experience shared by myself and my colleagues, and you’re just like, “Nope, that’s not the case!”
Well, thanks…I guess I have nothing else to add to this discussion then.
The problem isn't just personal preference or inertia. It's that all mainstream OSes, libraries, and system software are written in C/C++. You can't exactly ignore this and not learn the language if you want to work in this space.
Of course, there are many developers who don't work with system-level stuff, and they may be perfectly fine just knowing Java or JavaScript, but Rust is not positioning itself as a direct competitor to that.
There’s just too much pre-existing code.
Respectfully, this is wishful thinking.
C programmers aren’t going anywhere any time soon. There are millions upon millions upon millions lines of C code everywhere running critical software, firmware, infrastructure, etc. that won’t be rewritten in Rust any time soon.
However a lot of new infrastructure is being developed in rust. Infact it can be argued that the very reason it should be in rust is because it is critical. I think there would be great value if a person can efficiently thread between both rust and c rather than competing.
But you’re dead right. At this point Android apps may be the bigger set of code. Or at least put up a good fight.
I fully agree with that.
The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.
To quote the HN guidelines [0]:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
I think if you’re a good C programmer you’ll naturally be a good Rust programmer, and come up to speed faster than you expect.
There’s nothing forcing you to write everything with traits, generics, etc. You can write simple, fast, safe Rust without them.
Edit: read some of your other comments and realize this doesn’t quite address your point, but I do still think that writing small sections of logic in simple, straightforward Rust and then calling that from C is a nice way to get started. Doing so for places where ownership is complicated and the compiler can help enforce invariants can provide I think a meaningful ergonomic gain in a C codebase.
I know that writing your first 10 lines of Rust code will give you 15 novel compile errors, and that feels like it's impossible to get anything done in Rust, but once you get over the hump, you get to use a very productive modern language that can be as low-level as C, and almost as high-level as Python, at the same time.
You will not regret leaving behind the muscle memory for all the preprocessor tricks, workarounds for gratuitous platform differences and 40-year-old footguns, all the trivia for old compilers, the never ending tweaking of snowflake build scripts, and the skill of writing yet another half-assed hash table with your eyes closed. You'll wonder how you ever got anything done in a language that kept you busy calculating malloc sizes by hand.
The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences. If you were an expert and highly productive C programmer, your productivity will go out the window for what feels like a long time until you feel even just comfortable writing Rust. That makes Rust a very hard sell for C programmers who simply want to get things done. This is an area, by the way, that I think Zig does extremely well at—it provides safer semantics (despite its lack of guaranteed memory safety à la Rust) in a rather simple language and without rendering so much of your experience useless.