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".

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.)

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

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.)

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.

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.

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.

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 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++. ¯ \ _ ( ツ ) _ / ¯

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.

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”

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.

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?

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.

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)

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...

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.

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

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.