Some people are going to embrace what they want to hear. Rust has a different use-case than C, and just like C people tried to apply it in every situation regardless of whether it was appropriate.
Personally, running some shell script on a website is not the preferred installation method of a trusted compiler. Also, porting something that must make low-level memory unsafe operations anyway... into another bodged build ecosystem is pointlessly ridiculous, and outright dangerous in some settings.
At this point, the Rust AstroTurf campaign has gone full Troll. lol =3
It makes no sense to write ultra low-level code in Rust. You're gonna have to do unsafe operations and pointer arithmetic by design in those situations. Unsafe Rust is hardly ergonomic.
My point was if you are going for a safer high-level llvm language, than there are far better options than Rust... which includes many of the same core issues C encountered.
All software is terrible, but some of it is useful... We have seen several languages go on the same trajectory Rust is taking.
All programming languages are toys from my perspective, so your question only can receive a paradoxical opinion.
In general, I'm a Julia Fan, and Xcode escapee (supports: Swift, C++, Objective-C, Objective-C++, Java, AppleScript, Python, Ruby, C, Pascal, Ada, C#, Go, Perl, and D.)
However, I'd trust only C in a non-llvm compiled role for real-time firmware. The answer as to "why?" takes about a decade to fully understand... Sometimes a bit longer for some... Sometimes never for others... =3
You keep making odd references to llvm. Is there some reason you believe a decent compiler cannot be built using llvm, or are you harboring some misconceptions about what llvm is based on the "vm" part of the name?
ARM released several SoC products that blurred the use-cases in "A"pplications, "R"eal-time systems, and embedded "M"icrocontrollers. However, the llvm compilers performance gains are only justifiable in multitasking/Application contexts, where one does not require predictable/verifiable real-time code motion behavior in well modeled stable execution use-cases.
Probably not cool enough to clear a project on Rust yet... and note repeating myself about why differing use-cases matter usually requires a paid invoice. =3
That still sounds like you might be failing to understand that a compiler based on llvm can (and usually does) produce native machine code that is fully compiled and not running in any kind of JIT or virtual machine environment. And compilers like clang let you turn of optimizations just like gcc does.
Clang and various gcc ports are my daily driver tool-sets. However, they are used in vastly different contexts for well specified reasons (notably, the very same reasons Rust is inappropriate where gcc shines.)
Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are... given they primarily revolve around cheese Goldfish Crackers.
We could talk about the endangered Breviceps macrops instead... those creatures are hilarious. =3
> Clang and various gcc ports are my daily driver tool-sets. However, they are used in vastly different contexts for well specified reasons
"Well specified" where exactly? You keep alluding to the existence of some significant, fundamental differences with llvm-based tools that disqualify them from their intended use cases, without providing any hint of what you think those differences are.
> Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are
It's so hard to understand what exactly it is you're trying to communicate that I cannot tell if you are being deliberately bad at communicating, and whether linking to a video of a frog is intended as an insult. Please put some effort into clearly stating fully-formed thoughts.
The llvm optimization essentially makes the source codes implicit structure execution time unpredictable each compilation ( https://en.wikipedia.org/wiki/Code_motion .)
If all you care about is perceived latency under human perception, than the cooked performance of llvm can improve 12% to 23% over traditional gcc for multitasking/Application use-cases in my observation ( https://llvm.org/docs/CompileCudaWithLLVM.html .)
Are you confusing Real-Time and guaranteed-latency-schedulers as being the same thing? This is a commonly conflated concept from marketers, and the naive.
I kind of like the newer RP204x chips designs (still would never use them commercially yet), as it tried to handle GPIO domain RT and Application coding paradigms on the same silicon in a way people could better comprehend ( https://en.wikipedia.org/wiki/Clock_domain_crossing .)
Don't worry about it, at some point it will make sense... or not... cheese Goldfish crackers nom nom nom =3
Ok, your first paragraph seems to indicate you're talking about compile-time behavior, but don't believe that optimizations can be disabled in llvm to the same extent as in gcc, and maybe don't believe that clang can be used for fully reproducible builds.
Your second paragraph does not appear to make any sense on its own or in the context of the rest of your comment. "the cooked performance of llvm" looks like a translation error. Nothing you're talking about has any relevance to a link about CUDA.
Repeating the assertion that using gcc with optimizations disabled is sometimes desirable does not help explain why it is desirable, nor why equivalent results cannot be achieved using llvm. If you actually understand what you're talking about, it sounds like there might be an opportunity for an interesting and enlightening discussion about the specifics of compiler internals. But instead you again veer toward the vague insults and totally off-topic. Please don't do that.
The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty understanding why it is a challenge.
A toy example:
1. set flag foo=1
2. check flag bar=1
3. set flag foo=0
4. check flag bar=0
These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution.
Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred.
Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric.
In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space.
This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3
It sounds to me like you're claiming gcc is superior on the basis of incorrect code that doesn't make proper use of the volatile keyword and explicit memory barriers.
> "volatile" will not help with this class of problem.
Well, it's a good thing my comment had more words past that one. "volatile" is only part of the solution, and when more than one MMIO location is in play (as in your example), "volatile" on its own is insufficient but proper use of "volatile" plus explicit memory barriers will enforce correct ordering of loads and stores.
I think you miss George Carlin, and fear people won't like the real you. Antagonizing strangers around yourself to sabotage ones own happiness out of fear of emotional connections is not a healthy place to live.
Maybe a nice walk in the sun, or volunteer with a local pet-rescue society would help one feel better.
As someone who writes, reviews, and maintains lots of C code professionally, here’s what I think a lot of Rust advocates don’t understand: We see and understand the benefits of Rust. That’s no longer something we need to be sold on. Every C programmer who’s written and reviewed any amount of nontrivial C code likely has firsthand experience dealing with memory safety bugs that would simply disappear with a memory-safe language.
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.
Having written quite a bit of C++ firmware and just now spending a few weeks getting into Rust, I have to say the learning curve was less challenging than I thought it would be, and that I feel pretty effective after a short amount of time. The feeling of how sturdy the program is after getting the additional compiler support during development feels very reassuring.
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).
My question would be is the learning curve better or worse than, say, Swift?
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
I wouldn't be able to answer for Swift as I don't know it. However Rust would seem to be a suitable replacement for all use-cases of C++ in an embedded context that I was involved with (including allocation control + static initialization + macro usage).
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.
Speaking as someone who has written C skirting both sides of the UB line & referenced the spec to see when something tipped too far over said line... The fear that I'd be less productive for a "long" time was quite overblown.
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.
> 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.
Rust interoperability with C is excellent, way easier than with C++, which is also pretty easy.
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.
Could you give an example of how Zig is more C-like for the seasoned C developer?
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.
So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?
> So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?
Can you point me to where I said or suggested any of that?
> 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
The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.
C is 52 years old; C++ is nearly 40. That's more than a generation. Yet, I'd bet that there are more up-and-coming developers learning C/C++ than Rust today.
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.
Inertia is doing things because you're used to doing them. This is pragmatism: until the arrival of mainstream Rust-based OSes, there's probably no escaping C/C++.
My point is that the arrival of Rust-based OSes is absolutely in the cards, so while I don't disagree that it would be very difficult to fully escape at the moment that is also actively changing.
The world has lots of important COBOL. You’re dead on. Even if everyone committed to all new code in Rust tomorrow, C/C++ will be around for a LONG time.
> This is a problem that will resolve itself with time as C developers retire and new projects start in Rust.
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.
From my perspective (college student), it is true that there is godly amount of C code in the world which would remain true for a long long time. In similar sense there are also quite a lot of new java developers who maintain the millions of lines of java code.
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.
Java is not an old “maintain the code” language as you seem to imply. Despite not being the new hotness for about 25 years it’s an extremely useful and productive language and I assure you there are tons and tons of new things being written in it every day. The language is still evolving and has been getting great improvements. Yeah it has some warts, but it’s been running and keeping backwards compatibility for 30 years despite evolving.
> 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.
The entire graphics driver for Apple Silicon Macs in Linux, with zero memory bugs in the code despite being deployed to a large number of machines. including a fully conformant OpenGL implementation and most/all of Vulkan (I’ve lost track of the current state).
Rust is interesting but still has some pain points.
- Compile times. This, above all else.
- As an embedded dev: no_std is still rough around the edges, which the original Google blog post captured pretty well. They didn’t talk about PACs - the PAC paradigm also feels needlessly complicated - whoever wrote it really loves their zero-sized types and made it verbose to the point where the solution feels worse than the problem (at least to me) for things like using GPIO lines.
- Rust has a history of shipping serious bugs (see, floating point recently), and you basically have to constantly update your rust version. Not ideal for commercial products, which want stability.
- All of the RTOS options are also young. None of the major existing ones (e.x. FreeRTOS) support Rust natively. You’re not just asking people to learn the language, but start over on libraries and platform as well.
- The community is weird. If you don’t drink the koolaid you will be attacked.
Rust is constantly getting better, and the pain points of C impact real peoples lives in very real ways (security bugs that have led to people truly getting hurt), so Rust feels inevitable, but it’s still early days and pain.
Basically, anything that gets a .1 or .2 type release.
Also, shout out to the Rust community for maintaining and fixing issues quickly; not trying to pick on them, just trying to show some examples to show Rust is still young and very much a moving target.
To be fair, that affected a bunch of other languages as well so Rust is in (questionably) good company there.
I feel the need to keep your Rust install up to date might arguably be more ecosystem-dependent than anything to do with Rust itself. If stuff you're using requires a newer rustc then you don't have much choice but to upgrade, but if you're fine using something older and/or your dependencies keep support for older versions of rustc then you can probably get away with a lot fewer updates.
I just can't bring myself to spend time learning Rust when all the demand is for C++, C, Java, Typescript, Python, etc. Feels like we're going to be stuck in this limbo forever similar to languages like Kotlin.
It seems to me that the point of the article is that "all the demand" is not just for C++, C, Java, Typescript, Python, etc. There is increasing demand from larger companies for Rust.
No one is forcing you to learn Rust. You don't have to bring yourself spend time learning it. You can keep writing those other languages.
Those languages have been around for a while and they'll continue to be around for a while more. Rust is just getting some time on that stage as well now.
I think some dyed in the wool programmers are not afraid to learn something new but from experience see some nightmarish patterns in rust (e.g. c++ style templates for generics, phantom) and also watch less experienced programmers/architecture astronauts successfully argue to move things to rust without considering the future pain and are legitimately worried about being eventually forced to use it. Doesn't help that e.g. government is now saying "don't use memory unsafe languages".
I learned C++ first and Rust only within the past couple years, and I'd never willingly choose write a project in C++ again with the option to use Rust instead. Generics can get messy and the phantom data is indeed awkward, the difference to me is that in Rust if you go wrong the compiler most often can highlight the exact issue and suggest accurately how to fix it. My experience with C++ is that the compiler errors tend towards being so incomprehensible they sometimes felt intentionally misleading. The Rust compiler enforces correctness to a degree that gives me significantly more confidence in the programs I write; C++ is a major improvement on C here but still gives you so many ways to shoot yourself in the foot that would just not compile in a Rust project.
I haven't actually, glad to hear it! I still see big advantages to the extra compile time safety provided by Rust, and despite the mentioned similarities I find its syntax significantly clearer to read and write. C++ templates took me forever to really wrap my head around where a similar declaration in Rust feels immediately intuitive even where I don't fully understand all the nuances.
Almost ten years ago I was really excited about rust, but the sort of thing you describe has really put me off. It's become 'C++ but with better guarantees', whereas I liked it for being 'python ergonomics with stricter correctness' or something.
I really think there's room for a language more focussed on (sacrificing a bit for) usability/readability/DX - rust has great features like doc tests, in-module tests, structural pattern matching, macros, traits, .. but<some<of<the<container<crap, 'that>, ends<up, necessary>>>>> really ruins it for me. And on the one hand yes it is trivial, it is just syntax. But I do think it matters?
(It's late, I'm tired, not a very well formed thought, but coincidentally I was daydreaming about designing a language earlier today, so here we are.)
A compositional type is just a consequence of having a good type system. It means that you can slice your requirements into multiple independent types because they are individually describable in the type system. The converse is not true, which is why C++ also seems to have a compositional type. (C++ doesn't really have a true compositional type; C++ templates have no such guarantees, and thus even harder to use than true compositional types.)
Non-Apple development keeps getting better. It’s a very easy to read language with lots of safety, strong types,good standard library, await, and tons of users (thanks to Apple). Integrates easily with C/C++/Obj-C/Obj-C++, or anything else that can do C interop. Just gained neat macros and tests.
It’s probably my current “if I could pick anything” language.
On top of all the rest, it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
Ladybird browser decided to use Swift of all things. I am just confused on how can one use a ARC based language for extreme performance software like a browser . Don't you need manual memory control or custom memory paradigms like arenas ?
Nice, but like the extinct Dodo, these are all affectionate memorials to dead software. The web browser is still alive and kicking after 30 years. And is the world's most popular software application. And all the mainstream browsers are mostly written in C++. Even the massively hyped Servo never got adopted into Firefox.
Swift has always been designed with the potential for more manual memory control. Recently, non-copyable types were introduced, and non-escapable types are currently being proposed. Additionally, more ownership control features are being added. While there is still much work to be done, progress is steady.
> it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
I mean, maybe at a surface level. But under the covers with stuff like existential containers, opaque types, boxed types, ARC, etc it's a lot more complicated
Maybe the syntax "looks" modern like python but writing in it feels like smart pointer C++ with more safety features built in
Personally I'd rather just use C++ with a strict style guide, fewer new semantics to relearn
It's also funny that apple presents it as a "beginner friendly" language. Maybe it's possible for people to write in it without getting too far in the weeds, but like C++ it feels like a kitchen sink
Maybe all languages are like this to some degree, where there's a big gap between being proficient enough to write something and knowing it well enough to write something properly. It feels like Swift has a low barrier of entry but doing things properly has a much higher learning curve
Do you expect people to become expert rust programmers over night? I have 15 years of c++ under my belt and only recently got the chance to do some rust. Of course some of my rust code is going to look like c++ until I get some practice, some code review criticism, and personal study in. I’m here for the journey, and I am enjoying rust’s perks and mostly less mental overhead.
Rust superficially looks like C++ to avoid looking weird to existing C/C++ programmers, but semantically it's quite far from C++. Rust's generics are not like C++ templates: they're only type based, and don't use syntax-based matching, don't have tricks like SFINAE. ODR is guaranteed by construction. Trait lookup is simpler: there's no overloading, no inheritance, no implicit conversions, and interaction with namespaces is simple (ambiguity is an error).
Phantom type looks alien if you haven't used it, but for what it does, it's actually a pretty simple. It's there to explain in Rust's terms what an opaque type or a foreign C/C++ type does. You just need to give Rust an example of an equivalent type, and you get a correct as-if behavior, and you don't need to even know that you've just configured type's variance and destruction order checking.
Fair enough. I have personally experienced pain with phantoms.
But then what would you advice to do ? There are nightmare patterns in rust and c++. Looks to me as pick your poison just that one is new and other has been around for fair bit.
I am sorry. I really don't see your point. Typescript is in a completely different league of languages than rust/c/c++ with vastly different use cases.
Also, the world still mostly speaks C99 when iterative improvements are constantly being made up to C23.
The point is that Typescript was able to replace JavaScript by adding to it. Converting a codebase from js to ts was simple. Going from C++ to Rust is not.
I think C23 is going in the right direction, but it needs to go further.
There's always demand, but at what cost? Mixing languages sucks. Rewriting stuff is not always an option. New projects could use Rust, but will you be able to get the head count? There are whole armies of skilled C++ devs, but only a small group of competent Rust devs. This is the exact same problem Kotlin ran in to.
It is great that the ecosystem is growing, but there is still time for things to trickle down.
As college student I have invested time into rust because I see value in the language but there are absolutely zero entry level jobs or internships. To get my foot in, my only real options are C/C++.
a few years ago there was a big thrust here for haskell. and now it has all but gone. i do get a feeling that the same will happen with rust - but we will see.
I always had the impression that Haskell was primarily an academic language. Not that you can't use it for practical things, but a bit different in purpose compared to Rust.
If you're familiar with systems programming in C++ then learning Rust is like having an automated code reviewer when you run `cargo check`.
That said the biggest obstacle I've seen has come from C++ programmers traumatized by heavily templated codebases or dependencies equating Rust generics to templates. To which I say:
C++ templates are a bastard product of preprocessors and macro systems more than proper generic programming. The errors you get from Rust generics are much higher up the chain than template errors and while both impact compile times, with Rust it's less pronounced.
There is very little jobs in Rust and as of recently almost nothing. A couple years ago it was mostly crypto but now only a few big companies are hiring for Rust.
I notice, outside of Sydney there a few. There seem to be a bunch of Binance jobs. Are they the ones that are scams? They look kinda wacky, the Rust job says "Who may apply
Current university students and recent graduates who can work at least 4 days per week."
Maybe this is some way to avoid Australian salary regulation and pay $10 an hour?
If you are specializing in the kind of lower level systems that are still built in C++, learning Rust will probably be useful since those systems are good targets for Rust. If you are in the Java, Typescript, Python world, then you can gnome it. Are their programmers that specialize in a weird combination like C++ and Typescript (Python makes some sense for systems code, as does Go)? I get learning and using both as a unspecialized student/junior, but I can’t see that lasting beyond mid-career.
I work for a FAANG and I haven’t. Unless you would count webrtc and any thing that uses as part of the same project? I can’t imagine other cases, there are underlying native libraries like electron or webrtc, but they wouldn’t count as a same project with client code.
I admit we (non-native devs) still need to edit C++ code sometimes, but we aren’t the primary or even really secondary developers on such code.
A lot of projects at these places have C++ backends because the performance gains matter at their scale. It's also not unusual for developers to be fullstack, even for large projects.
Jack of all trades master of none fullstack devs are rarer the higher up seniority you go. They are much more likely to become people managers given the way influence is wielded at a big company. I can see them at smaller companies, but it sounds like a waste of potential.
In my experience it's the exact opposite. Junior devs can only handle small parts of the stack at once, but more senior people can handle everything. Senior people specialize by gaining domain knowledge.
The senior people can still handle as much as the stack as they could as juniors, but they have deep experience in a few areas where they are considered experts.
As someone who specializes in the type of low level systems that are still built in C, C++ is considered high risk let alone rust. That is largely the reality of the industry. Some co-workers and I hope to introduce C++ as an experimental project next year. We also have some data processing code written in C++ that we would like to integrate as is. The reality on the ground is that C is often used over C++. ¯ \ _ ( ツ ) _ / ¯
How about the subset of simple classes, RAII, basic containers(vector, map, duque), single inheritance, overloads for type safety/less casting, stronger casting features, references. Things that c programmers can pick up quickly and use in both c-style and c++ style? That’s what we do and it works out well our embedded. There are a host of embedded STL libraries to let you do hard limits and checks on containers to prevent “hidden” dynamic memory allocation and the like. Of course you’ll have to depend more on the quality of your compiler’s reputation for the processor, c++ is much much more complicated compiler than c and more apt to have bugs. But we’ve yet to encounter anything that forced us to say “f this generated incorrect assembly because of a compiler bug”
Depending on your field, I can definitely understand the hesitation. It's fairly easy to imagine what kind of machine code will be generated from C, but much harder with C++/Rust.
Is there game for a Rust like native language over a close to assembly procedural language like C? It seems the only thing that makes predictions hard are things like fptrs and their structured v-table organization (which you can roll your own in C if you want, which almost any large project will).
I think fptrs and v-tables are fairly predictable once you know how they work. The main issue is that "good" C++ code makes heavy use of the STL, meaning that you need to know exactly how everything is implemented to understand what code will be generated. In embedded environments there can be strict timing requirements, memory restrictions, etc. That makes C++/Rust a little more scary. You might wanna ban stuff like std::vector because you never know when it will reallocate and double in size. Better to just use dumb arrays so everything is obvious.
You can implement a self expanding vector in C though, so I’m not really sure what you are gaining/losing by using C++, I guess it’s just a matter of standard library, but you can create build rules that restrict what you can depend on in low level code.
The point is that having all these complex libraries and abstractions moves you away from understanding what your code is actually doing, which is not ideal in some domains.
Rust screams a nightmare to maintain (coworkers endlessly bikeshedding over the type signatures, insanely long PRs for refactors needed prior to feature work)
3.5 years into maintaining a large rust codebase and this is not my experience at all.
Type signature bikeshedding is extremely rare in PRs.
Refactors can be large, but the fact that they are possible to do safely across the entire codebase with confidence in the result is a major improvement over most other languages.
I wouldn’t go back to writing most other languages if I could avoid it, especially for anything large or performance-sensitive.
You examples seems to be for a dynamic environment where things are changing. Rust is naturally at slight odds in such a scenario
Instead of quick and dirty, it allows to embed the logic in the type system such that the compiler can help you. Getting off the ground is much harder but staying there is easier.
Maybe the compiler (and the syntax) isn't the right place to put these guarantees.
Surely there is some middle ground in design space between rust and ada on one side (fully in the compiler) and c (with sel4-style checking - proof checking on a post compilation artifact) on the other.
Note that the c in sel4 and ada have stronger safety and correctness guarantees than rust
> Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
In theory you can do that, in practice you can't. Becoming a good $language programmer necessarily involves reading other people's code, for example when diagnosing issues in misbehaving libraries. You have to be familiar with every common language feature that other developers use, otherwise you won't be able to do your job properly.
I'm curious about the c with sel4-style checking that was mentioned. Does sel4 have a style checker and/or proof checker that you can run on your c code? Or do they just have some style guide you have to read and memorize?
> Does sel4 have a style checker and/or proof checker that you can run on your c code?
The specification and proofs are open-source [0], but I suspect that they are tailored for seL4-related uses and probably aren't well-suited for "general-purpose" C code. I think using their proofs would also necessitate writing a specification for your own code which is probably going to be an ordeal in and of itself.
They do have a style guide [1] as well, but that's just a small part of the full verification process (described in [2]).
No? What xame to mind when someone talks about jobs in programming ans the list presented just refers to long lived langagues and existing code bases along side the need yo maintain them.
Then theres the double entndre with rust and the potsntial yo reduce maintenance and how what really matters is some kund of metric like loc per dev hours for maintenance. So like, if two language are comparable and one requires 2 prgrammers to maintian and the other 2.5, the second one would potentially have more jobs based entirely on how maintainable it is.
So claiming "these have more jobs" really is a fecestious statement
The title is "Google says". It's pretty normal for people to assume some public statement is like this would be a company thing, not just some single person of very small team.
It's more like 'Android engineers say [...]' than 'Google says [...]', which kind of implies PR dept. or someone very senior but not so senior they're just named.
I mean, on the plus side, this article doesn't have broken javascript regexes that trigger browser safety aborts like the javascript on the original source..
[edit] hum. couple of people didn't appreciate that clearly, but if you review the comments on the linked HN post, a large number of them are the discussion of the page being completely blank in firefox. If you review the firefox bug, it is apparently about a recursion overflow in the regex, where they note that chrome does some disturbing things to make it complete...
(not a judgement, just an observation) Google, the conglomerate with the resources to bless us with Go and Kubernetes; another language and a container orchestration platform created with it. Their easy isn't my easy.
You would think distributing firmware and flashing would be routine; several vendors have shown me it isn't
All this talk is pointless. The DoD is what will incentivize people to finally make the switch permanent. You want the real funds, you’re gonna have to write in a memory safe language going forward. At least that’s what the US government says.
> Google was already sold on the idea, having concluded that its Rust developers are twice as productive as its C++ engineers.
Not so. The actual study compared the cost of writing something in C++ to the cost of porting it to Rust.
Some people are going to embrace what they want to hear. Rust has a different use-case than C, and just like C people tried to apply it in every situation regardless of whether it was appropriate.
Personally, running some shell script on a website is not the preferred installation method of a trusted compiler. Also, porting something that must make low-level memory unsafe operations anyway... into another bodged build ecosystem is pointlessly ridiculous, and outright dangerous in some settings.
At this point, the Rust AstroTurf campaign has gone full Troll. lol =3
Don't be mad that C is being deprecated. Be happy that it existed. Lol =3
It makes no sense to write ultra low-level code in Rust. You're gonna have to do unsafe operations and pointer arithmetic by design in those situations. Unsafe Rust is hardly ergonomic.
My point was if you are going for a safer high-level llvm language, than there are far better options than Rust... which includes many of the same core issues C encountered.
All software is terrible, but some of it is useful... We have seen several languages go on the same trajectory Rust is taking.
https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
(you should probably assume the Von Neumann architecture will end soon too... half joking... )
Have a nice day, =3
>My point was if you are going for a safer high-level llvm language, than there are far better options than Rust
Mind naming any? Mind naming any that aren't just toy languages?
All programming languages are toys from my perspective, so your question only can receive a paradoxical opinion.
In general, I'm a Julia Fan, and Xcode escapee (supports: Swift, C++, Objective-C, Objective-C++, Java, AppleScript, Python, Ruby, C, Pascal, Ada, C#, Go, Perl, and D.)
However, I'd trust only C in a non-llvm compiled role for real-time firmware. The answer as to "why?" takes about a decade to fully understand... Sometimes a bit longer for some... Sometimes never for others... =3
You keep making odd references to llvm. Is there some reason you believe a decent compiler cannot be built using llvm, or are you harboring some misconceptions about what llvm is based on the "vm" part of the name?
ARM released several SoC products that blurred the use-cases in "A"pplications, "R"eal-time systems, and embedded "M"icrocontrollers. However, the llvm compilers performance gains are only justifiable in multitasking/Application contexts, where one does not require predictable/verifiable real-time code motion behavior in well modeled stable execution use-cases.
Probably not cool enough to clear a project on Rust yet... and note repeating myself about why differing use-cases matter usually requires a paid invoice. =3
> predictable/verifiable real-time code motion behavior
That still sounds like you might be failing to understand that a compiler based on llvm can (and usually does) produce native machine code that is fully compiled and not running in any kind of JIT or virtual machine environment. And compilers like clang let you turn of optimizations just like gcc does.
Clang and various gcc ports are my daily driver tool-sets. However, they are used in vastly different contexts for well specified reasons (notably, the very same reasons Rust is inappropriate where gcc shines.)
Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are... given they primarily revolve around cheese Goldfish Crackers.
We could talk about the endangered Breviceps macrops instead... those creatures are hilarious. =3
https://youtu.be/HBxn56l9WcU?feature=shared&t=8
> Clang and various gcc ports are my daily driver tool-sets. However, they are used in vastly different contexts for well specified reasons
"Well specified" where exactly? You keep alluding to the existence of some significant, fundamental differences with llvm-based tools that disqualify them from their intended use cases, without providing any hint of what you think those differences are.
> Perhaps there is some subtlety lost in my words, but I assure you it will be unproductive to guess what my thoughts are
It's so hard to understand what exactly it is you're trying to communicate that I cannot tell if you are being deliberately bad at communicating, and whether linking to a video of a frog is intended as an insult. Please put some effort into clearly stating fully-formed thoughts.
The llvm optimization essentially makes the source codes implicit structure execution time unpredictable each compilation ( https://en.wikipedia.org/wiki/Code_motion .)
If all you care about is perceived latency under human perception, than the cooked performance of llvm can improve 12% to 23% over traditional gcc for multitasking/Application use-cases in my observation ( https://llvm.org/docs/CompileCudaWithLLVM.html .)
The non-optimized gcc C builds are sometimes desirable for fixed latency real-time use-cases like 2/3rds of ARMs chip lines intended markets ( https://developer.arm.com/downloads/search?programme=Free+to... )
Are you confusing Real-Time and guaranteed-latency-schedulers as being the same thing? This is a commonly conflated concept from marketers, and the naive.
I kind of like the newer RP204x chips designs (still would never use them commercially yet), as it tried to handle GPIO domain RT and Application coding paradigms on the same silicon in a way people could better comprehend ( https://en.wikipedia.org/wiki/Clock_domain_crossing .)
Don't worry about it, at some point it will make sense... or not... cheese Goldfish crackers nom nom nom =3
Ok, your first paragraph seems to indicate you're talking about compile-time behavior, but don't believe that optimizations can be disabled in llvm to the same extent as in gcc, and maybe don't believe that clang can be used for fully reproducible builds.
Your second paragraph does not appear to make any sense on its own or in the context of the rest of your comment. "the cooked performance of llvm" looks like a translation error. Nothing you're talking about has any relevance to a link about CUDA.
Repeating the assertion that using gcc with optimizations disabled is sometimes desirable does not help explain why it is desirable, nor why equivalent results cannot be achieved using llvm. If you actually understand what you're talking about, it sounds like there might be an opportunity for an interesting and enlightening discussion about the specifics of compiler internals. But instead you again veer toward the vague insults and totally off-topic. Please don't do that.
The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty understanding why it is a challenge.
A toy example:
1. set flag foo=1
2. check flag bar=1
3. set flag foo=0
4. check flag bar=0
These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution.
Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred.
Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric.
In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space.
This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3
It sounds to me like you're claiming gcc is superior on the basis of incorrect code that doesn't make proper use of the volatile keyword and explicit memory barriers.
"volatile" will not help with this class of problem.
Don't worry about it... if your primary use-case is in Application space, than it won't matter most of the time. =3
> "volatile" will not help with this class of problem.
Well, it's a good thing my comment had more words past that one. "volatile" is only part of the solution, and when more than one MMIO location is in play (as in your example), "volatile" on its own is insufficient but proper use of "volatile" plus explicit memory barriers will enforce correct ordering of loads and stores.
[flagged]
Very rude, did you actually have constructive input, or just the vitriol?
Have a nice day, =3
Warning others that you're schizoposting is constructive input.
I think you miss George Carlin, and fear people won't like the real you. Antagonizing strangers around yourself to sabotage ones own happiness out of fear of emotional connections is not a healthy place to live.
Maybe a nice walk in the sun, or volunteer with a local pet-rescue society would help one feel better.
Have a nice day, =3
>I think you miss George Carlin
What does this mean?
>and fear people won't like the real you
Projecting like AMC.
>Antagonizing strangers around yourself to sabotage ones own happiness out of fear of emotional connections is not a healthy place to live.
I'm not antagonizing anyone, and you're not around me.
>Maybe a nice walk in the sun
Already do.
>or volunteer with a local pet-rescue society would help one feel better.
Also already do this.
>Have a nice day, =3
You too.
Until someone rewrites the entire Linux kernel in Rust, (without unsafes) its not going away.
And to do that, a lot of the logic has to be re-thought to fit into Rust memory safe runtimes, which is not a straightforward thing.
Basically, at this point, AI checking C code and making it memory safe is going to come way sooner than Rust adoption.
Don't fall for the troll my friend... As Linux is also vulnerable to weird architecture changes that seem to favor microkernels/nanokernel instead. =3
As someone who writes, reviews, and maintains lots of C code professionally, here’s what I think a lot of Rust advocates don’t understand: We see and understand the benefits of Rust. That’s no longer something we need to be sold on. Every C programmer who’s written and reviewed any amount of nontrivial C code likely has firsthand experience dealing with memory safety bugs that would simply disappear with a memory-safe language.
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.
Having written quite a bit of C++ firmware and just now spending a few weeks getting into Rust, I have to say the learning curve was less challenging than I thought it would be, and that I feel pretty effective after a short amount of time. The feeling of how sturdy the program is after getting the additional compiler support during development feels very reassuring.
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).
My question would be is the learning curve better or worse than, say, Swift?
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
Rust can be written simply if you avoid more complicated features of the language. It depends on what you want to get out of it.
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.
I wouldn't be able to answer for Swift as I don't know it. However Rust would seem to be a suitable replacement for all use-cases of C++ in an embedded context that I was involved with (including allocation control + static initialization + macro usage).
Productivity tanks only temporarily.
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.
Speaking as someone who has written C skirting both sides of the UB line & referenced the spec to see when something tipped too far over said line... The fear that I'd be less productive for a "long" time was quite overblown.
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.
> 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.
>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?
People who still use C rather than C++, which has this exact feature?
https://open.substack.com/pub/ryanfleury/p/untangling-lifeti...
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!
As for the HN guidelines. Sorry if you felt like I crossed a line. Never my intention.
> 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.
> 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.
[0]: https://news.ycombinator.com/newsguidelines.html
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.
Rust doesn't require nearly as much muscle memory as C.
Rust interoperability with C is excellent, way easier than with C++, which is also pretty easy.
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.
Could you give an example of how Zig is more C-like for the seasoned C developer?
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.
You can use methods in Rust for volatile reads/writes.
https://doc.rust-lang.org/std/ptr/fn.write_volatile.html
https://doc.rust-lang.org/std/ptr/fn.read_volatile.html
> One notable omission is `volatile` but that sorta beside the point.
What do you mean here?
Basically this note: https://doc.rust-lang.org/std/ptr/fn.write_volatile.html#not...
I see, thanks!
So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?
> So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?
Can you point me to where I said or suggested any of that?
> 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
The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.
> 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.
[0]: https://news.ycombinator.com/newsguidelines.html
You're correct. A slip of etiquette.
This is a problem that will resolve itself with time as C developers retire and new projects start in Rust.
C is 52 years old; C++ is nearly 40. That's more than a generation. Yet, I'd bet that there are more up-and-coming developers learning C/C++ than Rust today.
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.
How is "too much existing software uses C/C++" not just inertia? That can also change with time.
Inertia is doing things because you're used to doing them. This is pragmatism: until the arrival of mainstream Rust-based OSes, there's probably no escaping C/C++.
My point is that the arrival of Rust-based OSes is absolutely in the cards, so while I don't disagree that it would be very difficult to fully escape at the moment that is also actively changing.
The world has lots of important COBOL. You’re dead on. Even if everyone committed to all new code in Rust tomorrow, C/C++ will be around for a LONG time.
There’s just too much pre-existing code.
> This is a problem that will resolve itself with time as C developers retire and new projects start in Rust.
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.
From my perspective (college student), it is true that there is godly amount of C code in the world which would remain true for a long long time. In similar sense there are also quite a lot of new java developers who maintain the millions of lines of java code.
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.
Java is not an old “maintain the code” language as you seem to imply. Despite not being the new hotness for about 25 years it’s an extremely useful and productive language and I assure you there are tons and tons of new things being written in it every day. The language is still evolving and has been getting great improvements. Yeah it has some warts, but it’s been running and keeping backwards compatibility for 30 years despite evolving.
Many seem to forget all the time, that the Java ecosystem powers the most widely sold mobile OS platform across the globe.
Including me! I was referring to server stuff, since server side Java is my job and thus front of mind.
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.
There are a ridiculous number of greenfield Java projects being started every day. Far more than Rust by orders of magnitude.
> 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.
I fully agree with that.
[flagged]
The entire graphics driver for Apple Silicon Macs in Linux, with zero memory bugs in the code despite being deployed to a large number of machines. including a fully conformant OpenGL implementation and most/all of Vulkan (I’ve lost track of the current state).
Rust is interesting but still has some pain points.
- Compile times. This, above all else.
- As an embedded dev: no_std is still rough around the edges, which the original Google blog post captured pretty well. They didn’t talk about PACs - the PAC paradigm also feels needlessly complicated - whoever wrote it really loves their zero-sized types and made it verbose to the point where the solution feels worse than the problem (at least to me) for things like using GPIO lines.
- Rust has a history of shipping serious bugs (see, floating point recently), and you basically have to constantly update your rust version. Not ideal for commercial products, which want stability.
- All of the RTOS options are also young. None of the major existing ones (e.x. FreeRTOS) support Rust natively. You’re not just asking people to learn the language, but start over on libraries and platform as well.
- The community is weird. If you don’t drink the koolaid you will be attacked.
Rust is constantly getting better, and the pain points of C impact real peoples lives in very real ways (security bugs that have led to people truly getting hurt), so Rust feels inevitable, but it’s still early days and pain.
> Rust has a history of shipping serious bugs (see, floating point recently)
For those of us who may be out of the loop, could you elaborate on these points?
https://github.com/rust-lang/rust/pull/128271
This one was fun too: https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
Basically, anything that gets a .1 or .2 type release.
Also, shout out to the Rust community for maintaining and fixing issues quickly; not trying to pick on them, just trying to show some examples to show Rust is still young and very much a moving target.
Ah, optimizer bugs are fun. Does make me wonder how their error rates compares to that of the other major compilers.
> This one was fun too: https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
To be fair, that affected a bunch of other languages as well so Rust is in (questionably) good company there.
I feel the need to keep your Rust install up to date might arguably be more ecosystem-dependent than anything to do with Rust itself. If stuff you're using requires a newer rustc then you don't have much choice but to upgrade, but if you're fine using something older and/or your dependencies keep support for older versions of rustc then you can probably get away with a lot fewer updates.
I just can't bring myself to spend time learning Rust when all the demand is for C++, C, Java, Typescript, Python, etc. Feels like we're going to be stuck in this limbo forever similar to languages like Kotlin.
It seems to me that the point of the article is that "all the demand" is not just for C++, C, Java, Typescript, Python, etc. There is increasing demand from larger companies for Rust.
No one is forcing you to learn Rust. You don't have to bring yourself spend time learning it. You can keep writing those other languages.
Those languages have been around for a while and they'll continue to be around for a while more. Rust is just getting some time on that stage as well now.
I think some dyed in the wool programmers are not afraid to learn something new but from experience see some nightmarish patterns in rust (e.g. c++ style templates for generics, phantom) and also watch less experienced programmers/architecture astronauts successfully argue to move things to rust without considering the future pain and are legitimately worried about being eventually forced to use it. Doesn't help that e.g. government is now saying "don't use memory unsafe languages".
I learned C++ first and Rust only within the past couple years, and I'd never willingly choose write a project in C++ again with the option to use Rust instead. Generics can get messy and the phantom data is indeed awkward, the difference to me is that in Rust if you go wrong the compiler most often can highlight the exact issue and suggest accurately how to fix it. My experience with C++ is that the compiler errors tend towards being so incomprehensible they sometimes felt intentionally misleading. The Rust compiler enforces correctness to a degree that gives me significantly more confidence in the programs I write; C++ is a major improvement on C here but still gives you so many ways to shoot yourself in the foot that would just not compile in a Rust project.
Did you write C++ after C++ 20 came out ? With concepts and a modern code base, the incomprehensible errors are a thing of the past.
I haven't actually, glad to hear it! I still see big advantages to the extra compile time safety provided by Rust, and despite the mentioned similarities I find its syntax significantly clearer to read and write. C++ templates took me forever to really wrap my head around where a similar declaration in Rust feels immediately intuitive even where I don't fully understand all the nuances.
Almost ten years ago I was really excited about rust, but the sort of thing you describe has really put me off. It's become 'C++ but with better guarantees', whereas I liked it for being 'python ergonomics with stricter correctness' or something.
I really think there's room for a language more focussed on (sacrificing a bit for) usability/readability/DX - rust has great features like doc tests, in-module tests, structural pattern matching, macros, traits, .. but<some<of<the<container<crap, 'that>, ends<up, necessary>>>>> really ruins it for me. And on the one hand yes it is trivial, it is just syntax. But I do think it matters?
(It's late, I'm tired, not a very well formed thought, but coincidentally I was daydreaming about designing a language earlier today, so here we are.)
A compositional type is just a consequence of having a good type system. It means that you can slice your requirements into multiple independent types because they are individually describable in the type system. The converse is not true, which is why C++ also seems to have a compositional type. (C++ doesn't really have a true compositional type; C++ templates have no such guarantees, and thus even harder to use than true compositional types.)
I’d suggest looking at Swift.
Non-Apple development keeps getting better. It’s a very easy to read language with lots of safety, strong types,good standard library, await, and tons of users (thanks to Apple). Integrates easily with C/C++/Obj-C/Obj-C++, or anything else that can do C interop. Just gained neat macros and tests.
It’s probably my current “if I could pick anything” language.
On top of all the rest, it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
Ladybird browser decided to use Swift of all things. I am just confused on how can one use a ARC based language for extreme performance software like a browser . Don't you need manual memory control or custom memory paradigms like arenas ?
Now imagine using such a language for a full blown graphical workstation!
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"Project Oberon"
http://www.projectoberon.net/
"The Midori Operating System Overview"
https://www.youtube.com/watch?v=37WgsoZpf3k
https://joeduffyblog.com/2015/11/03/blogging-about-midori/
Nice, but like the extinct Dodo, these are all affectionate memorials to dead software. The web browser is still alive and kicking after 30 years. And is the world's most popular software application. And all the mainstream browsers are mostly written in C++. Even the massively hyped Servo never got adopted into Firefox.
As usual, the usual mistake to mix up technology with political mistakes, and lack of budget.
Apple and Google show on their mobile OSes how to make developers dance to the music of modern systems languages.
Swift has always been designed with the potential for more manual memory control. Recently, non-copyable types were introduced, and non-escapable types are currently being proposed. Additionally, more ownership control features are being added. While there is still much work to be done, progress is steady.
> it looks more like JS/Python than the pile of symbols C++ or Rust or even Obj-C can turn into.
I mean, maybe at a surface level. But under the covers with stuff like existential containers, opaque types, boxed types, ARC, etc it's a lot more complicated
Maybe the syntax "looks" modern like python but writing in it feels like smart pointer C++ with more safety features built in
Personally I'd rather just use C++ with a strict style guide, fewer new semantics to relearn
It's also funny that apple presents it as a "beginner friendly" language. Maybe it's possible for people to write in it without getting too far in the weeds, but like C++ it feels like a kitchen sink
Maybe all languages are like this to some degree, where there's a big gap between being proficient enough to write something and knowing it well enough to write something properly. It feels like Swift has a low barrier of entry but doing things properly has a much higher learning curve
Faster with Python ergonomics is Go. Safer with C++ perf is Rust.
(my rule of thumb)
If you haven't checked it out, nim sits at a really good middle ground for ergonomics, safety, and speed.
I haven't looked at it in years, but that's what I've been hearing indeed.
For faster with Python ergonomics,
Common Lisp, Scheme, Julia, OCaml, F#, C#, Scala, Kotlin, TypeScript, Clojure
Do you expect people to become expert rust programmers over night? I have 15 years of c++ under my belt and only recently got the chance to do some rust. Of course some of my rust code is going to look like c++ until I get some practice, some code review criticism, and personal study in. I’m here for the journey, and I am enjoying rust’s perks and mostly less mental overhead.
Rust superficially looks like C++ to avoid looking weird to existing C/C++ programmers, but semantically it's quite far from C++. Rust's generics are not like C++ templates: they're only type based, and don't use syntax-based matching, don't have tricks like SFINAE. ODR is guaranteed by construction. Trait lookup is simpler: there's no overloading, no inheritance, no implicit conversions, and interaction with namespaces is simple (ambiguity is an error).
Phantom type looks alien if you haven't used it, but for what it does, it's actually a pretty simple. It's there to explain in Rust's terms what an opaque type or a foreign C/C++ type does. You just need to give Rust an example of an equivalent type, and you get a correct as-if behavior, and you don't need to even know that you've just configured type's variance and destruction order checking.
Rusts generics might wind up adopting constexpr like abilities and also on the docket are keyword generics.
Fair enough. I have personally experienced pain with phantoms.
But then what would you advice to do ? There are nightmare patterns in rust and c++. Looks to me as pick your poison just that one is new and other has been around for fair bit.
Looking at Typescript, the latest successful language, I think the way forward is to make C and C++ safe by gradually adding and deprecating features.
I am sorry. I really don't see your point. Typescript is in a completely different league of languages than rust/c/c++ with vastly different use cases.
Also, the world still mostly speaks C99 when iterative improvements are constantly being made up to C23.
The point is that Typescript was able to replace JavaScript by adding to it. Converting a codebase from js to ts was simple. Going from C++ to Rust is not.
I think C23 is going in the right direction, but it needs to go further.
Typescript isn’t a separate language though, nor does it replace Javascript, you’re comparing apples and oranges.
[dead]
There's always demand, but at what cost? Mixing languages sucks. Rewriting stuff is not always an option. New projects could use Rust, but will you be able to get the head count? There are whole armies of skilled C++ devs, but only a small group of competent Rust devs. This is the exact same problem Kotlin ran in to.
It is great that the ecosystem is growing, but there is still time for things to trickle down.
As college student I have invested time into rust because I see value in the language but there are absolutely zero entry level jobs or internships. To get my foot in, my only real options are C/C++.
a few years ago there was a big thrust here for haskell. and now it has all but gone. i do get a feeling that the same will happen with rust - but we will see.
Rust already has orders of magnitude more adoption in the real world than Haskell
I always had the impression that Haskell was primarily an academic language. Not that you can't use it for practical things, but a bit different in purpose compared to Rust.
If you're familiar with systems programming in C++ then learning Rust is like having an automated code reviewer when you run `cargo check`.
That said the biggest obstacle I've seen has come from C++ programmers traumatized by heavily templated codebases or dependencies equating Rust generics to templates. To which I say:
C++ templates are a bastard product of preprocessors and macro systems more than proper generic programming. The errors you get from Rust generics are much higher up the chain than template errors and while both impact compile times, with Rust it's less pronounced.
I remember a long time ago when the Java crowd had a similar attitude towards C++ and C. Fascinating.
There's tons of Rust jobs out there, and they tend to be on the high end of salary. Java devs are a dime a dozen.
There is very little jobs in Rust and as of recently almost nothing. A couple years ago it was mostly crypto but now only a few big companies are hiring for Rust.
I just looked on Seek, the platform people mainly user here in Sydney, there is one job, outside panel beaters.
In Australia the Rust jobs are mostly crypto scam listings unfortunately.
I notice, outside of Sydney there a few. There seem to be a bunch of Binance jobs. Are they the ones that are scams? They look kinda wacky, the Rust job says "Who may apply Current university students and recent graduates who can work at least 4 days per week."
Maybe this is some way to avoid Australian salary regulation and pay $10 an hour?
If you are specializing in the kind of lower level systems that are still built in C++, learning Rust will probably be useful since those systems are good targets for Rust. If you are in the Java, Typescript, Python world, then you can gnome it. Are their programmers that specialize in a weird combination like C++ and Typescript (Python makes some sense for systems code, as does Go)? I get learning and using both as a unspecialized student/junior, but I can’t see that lasting beyond mid-career.
If you work at a FAANG company you can definitely expect to see C++ and Typescript in the same project.
I work for a FAANG and I haven’t. Unless you would count webrtc and any thing that uses as part of the same project? I can’t imagine other cases, there are underlying native libraries like electron or webrtc, but they wouldn’t count as a same project with client code.
I admit we (non-native devs) still need to edit C++ code sometimes, but we aren’t the primary or even really secondary developers on such code.
A lot of projects at these places have C++ backends because the performance gains matter at their scale. It's also not unusual for developers to be fullstack, even for large projects.
Jack of all trades master of none fullstack devs are rarer the higher up seniority you go. They are much more likely to become people managers given the way influence is wielded at a big company. I can see them at smaller companies, but it sounds like a waste of potential.
In my experience it's the exact opposite. Junior devs can only handle small parts of the stack at once, but more senior people can handle everything. Senior people specialize by gaining domain knowledge.
The senior people can still handle as much as the stack as they could as juniors, but they have deep experience in a few areas where they are considered experts.
As someone who specializes in the type of low level systems that are still built in C, C++ is considered high risk let alone rust. That is largely the reality of the industry. Some co-workers and I hope to introduce C++ as an experimental project next year. We also have some data processing code written in C++ that we would like to integrate as is. The reality on the ground is that C is often used over C++. ¯ \ _ ( ツ ) _ / ¯
How about the subset of simple classes, RAII, basic containers(vector, map, duque), single inheritance, overloads for type safety/less casting, stronger casting features, references. Things that c programmers can pick up quickly and use in both c-style and c++ style? That’s what we do and it works out well our embedded. There are a host of embedded STL libraries to let you do hard limits and checks on containers to prevent “hidden” dynamic memory allocation and the like. Of course you’ll have to depend more on the quality of your compiler’s reputation for the processor, c++ is much much more complicated compiler than c and more apt to have bugs. But we’ve yet to encounter anything that forced us to say “f this generated incorrect assembly because of a compiler bug”
Depending on your field, I can definitely understand the hesitation. It's fairly easy to imagine what kind of machine code will be generated from C, but much harder with C++/Rust.
Is there game for a Rust like native language over a close to assembly procedural language like C? It seems the only thing that makes predictions hard are things like fptrs and their structured v-table organization (which you can roll your own in C if you want, which almost any large project will).
I think fptrs and v-tables are fairly predictable once you know how they work. The main issue is that "good" C++ code makes heavy use of the STL, meaning that you need to know exactly how everything is implemented to understand what code will be generated. In embedded environments there can be strict timing requirements, memory restrictions, etc. That makes C++/Rust a little more scary. You might wanna ban stuff like std::vector because you never know when it will reallocate and double in size. Better to just use dumb arrays so everything is obvious.
You can implement a self expanding vector in C though, so I’m not really sure what you are gaining/losing by using C++, I guess it’s just a matter of standard library, but you can create build rules that restrict what you can depend on in low level code.
The point is that having all these complex libraries and abstractions moves you away from understanding what your code is actually doing, which is not ideal in some domains.
Those lanagues scream maintenance window.
Rust screams a nightmare to maintain (coworkers endlessly bikeshedding over the type signatures, insanely long PRs for refactors needed prior to feature work)
I've been writing rust code in production for 2 years and none of that happens, and this is with a team that was relatively new to rust.
3.5 years into maintaining a large rust codebase and this is not my experience at all.
Type signature bikeshedding is extremely rare in PRs.
Refactors can be large, but the fact that they are possible to do safely across the entire codebase with confidence in the result is a major improvement over most other languages.
I wouldn’t go back to writing most other languages if I could avoid it, especially for anything large or performance-sensitive.
You examples seems to be for a dynamic environment where things are changing. Rust is naturally at slight odds in such a scenario
Instead of quick and dirty, it allows to embed the logic in the type system such that the compiler can help you. Getting off the ground is much harder but staying there is easier.
.
Maybe the compiler (and the syntax) isn't the right place to put these guarantees.
Surely there is some middle ground in design space between rust and ada on one side (fully in the compiler) and c (with sel4-style checking - proof checking on a post compilation artifact) on the other.
Note that the c in sel4 and ada have stronger safety and correctness guarantees than rust
If you’re ok with sacrificing a small amount of performance for usability, just throw `clone()` everywhere. It will satisfy the compiler.
Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
> Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
In theory you can do that, in practice you can't. Becoming a good $language programmer necessarily involves reading other people's code, for example when diagnosing issues in misbehaving libraries. You have to be familiar with every common language feature that other developers use, otherwise you won't be able to do your job properly.
I'm curious about the c with sel4-style checking that was mentioned. Does sel4 have a style checker and/or proof checker that you can run on your c code? Or do they just have some style guide you have to read and memorize?
> Does sel4 have a style checker and/or proof checker that you can run on your c code?
The specification and proofs are open-source [0], but I suspect that they are tailored for seL4-related uses and probably aren't well-suited for "general-purpose" C code. I think using their proofs would also necessitate writing a specification for your own code which is probably going to be an ordeal in and of itself.
They do have a style guide [1] as well, but that's just a small part of the full verification process (described in [2]).
[0]: https://github.com/seL4/l4v
[1]: https://docs.sel4.systems/processes/style-guide.html#verific...
[2]: https://trustworthy.systems/publications/nicta_full_text/737...
Are you referring to https://repairmanjack.com/books/the-lanague-federation-serie...? ;)
No? What xame to mind when someone talks about jobs in programming ans the list presented just refers to long lived langagues and existing code bases along side the need yo maintain them.
Then theres the double entndre with rust and the potsntial yo reduce maintenance and how what really matters is some kund of metric like loc per dev hours for maintenance. So like, if two language are comparable and one requires 2 prgrammers to maintian and the other 2.5, the second one would potentially have more jobs based entirely on how maintainable it is.
So claiming "these have more jobs" really is a fecestious statement
Android engineers don't really speak for the whole of Google
Is that true of any group at Google? What’s your point?
The title is "Google says". It's pretty normal for people to assume some public statement is like this would be a company thing, not just some single person of very small team.
It's more like 'Android engineers say [...]' than 'Google says [...]', which kind of implies PR dept. or someone very senior but not so senior they're just named.
Not surprised, rarely is it worth rewriting an entire codebase though.
Not sure who would do that or what the implications might be for replacing all the say Python code with cpp.
Original source: https://news.ycombinator.com/item?id=41458508
I mean, on the plus side, this article doesn't have broken javascript regexes that trigger browser safety aborts like the javascript on the original source..
[edit] hum. couple of people didn't appreciate that clearly, but if you review the comments on the linked HN post, a large number of them are the discussion of the page being completely blank in firefox. If you review the firefox bug, it is apparently about a recursion overflow in the regex, where they note that chrome does some disturbing things to make it complete...
(not a judgement, just an observation) Google, the conglomerate with the resources to bless us with Go and Kubernetes; another language and a container orchestration platform created with it. Their easy isn't my easy.
You would think distributing firmware and flashing would be routine; several vendors have shown me it isn't
All this talk is pointless. The DoD is what will incentivize people to finally make the switch permanent. You want the real funds, you’re gonna have to write in a memory safe language going forward. At least that’s what the US government says.
[dead]