> The fear that I'd be less productive for a "long" time was quite overblown.
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.
Who are these C programmers who are a hard sell on this? Any C programmer who knows how to write working code knows a lot of Rust’s rules implicitly because they have to deal with it manually!
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.
Did you make it to the end of that section you linked? It's pretty clear on Rust having significant advantages here still:
"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 feel like most discussions touching on Rust revolve around the same lines - one person says they don’t want to use Rust (for whatever reason), a proponent starts regurgitating the selling points, the former feels misunderstood (because that all has been heard many times before), the latter snubs at taking the former as being stubborn.
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.
Good points, the JVM is absolutely underrated these days imo and Rust won't always be a strictly better choice especially for established teams. From what I see though a lot of this repetitive back-and-forth starts with somebody saying that they personally prefer Rust or simply describing its advantages over other languages from their perspective, and every time there's backlash from people responding as if the author were trying to personally force them into using Rust in their own projects.
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.
The real argument from that piece is that heap allocation is something to be avoided, and there are alternatives to malloc/free pairs. There are other benefits, but specifically having the compiler insert lots of frees is not one of them, for developers that prefer arena memory management for efficiency, simplicity, organization, and cache behavior.
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.
> 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?
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.
> Your point was that some developers you know would spend months getting comfortable with the language and semantics.
>
> 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.
There were quite a few times when patterns I expected to work were forbidden, but each time I learned why I learned something important (can't iterate a list of callbacks and pass a mutable reference of the list in? Iterator invalidation lesson incoming).
I think it’d be interesting to see improvements to the ergonomics of unsafe rust (which already offers a lot of safety improvements over C), such that it becomes an easier on-ramp for experienced C programmers. Something to allow you to write Rust that feels more C-like while you get used to the language.
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.