[ActorNightly]

Rust is by far not mature enough for serious development. Recent shenanigans with crablang are a strong sign of it going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.

[duped]

> Rust is by far not mature enough for serious development

Except it's being used for serious development today

> going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.

So one of the most widely used applications programming languages in the world?

[ActorNightly]

>Except it's being used for serious development today

No, its being used for pet projects by people. Serious development = major companies using it in backends.

>So one of the most widely used applications programming languages in the world?

Because of CS programs, and legacy software written in java. Java has a community dedicated to pushing theoretical CS concepts into the language (much like Rust), while allowing things like a logging library to fetch code from anywhere on the internet and execute it, by default (which I would bet on would be the future of Rust given current trajectory)

[c-cube]

> No, its being used for pet projects by people. Serious development = major companies using it in backends.

You mean companies like Dropbox, Cloudflare, Amazon, Microsoft...? Are they too small to be relevant?

[ActorNightly]

Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons

https://github.com/firecracker-microvm/firecracker/search?q=...

The fact that 'unsafe' even exists in Rust means it's no better than C with some macros.

Don't get me wrong, Rust has it's place, like all the other languages that came about for various reasons, but it's not going to gain wide adoption.

Future of programming consists of 2 languages - something like C that has a small instruction set for adopting to new hardware, and something that is very high level, higher than Python with LLM in the background. Everything in the middle is fodder.

[c-cube]

You're moving the goalposts here. Rust is being used, in significant projects (eg: proxies at Cloudflare, a company where http is somewhat of a big deal: https://blog.cloudflare.com/introducing-oxy/ ; Dropbox's new sync algorithm, a company where file syncing id kind of a big deal : https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...).

Equating the existence of unsafe with C is laughable imho (it'd be barely comparable even if 100% of the rust code was in unsafe blocs, which never happens). Not even then it doesn't matter for the original point : rust is used in production for business critical functions, in large companies.

[ActorNightly]

When an OS is written in Rust fully, then we can talk about acceptance.

Parts of systems written in a language doesn't really mean anything for its adoption into mainstream. For example, Amazon uses Ruby heavily for a bunch of deployment stuff, but Ruby (sans Ruby on Rails that is in decline), is not really a mainstream language any more.

>Equating the existence of unsafe with C is laughable imho

Im not comparing it. The point is to demonstrate that unsafe exists for the sole reason of performance. In fast code you often want to directly access x[y] where x and y are variables, without having to run extra code around it. Its a well known computer science thing, as most of the code challenges given in interviews rely on this access pattern for optimal solutions.

And because of Rice theorem, a compiler cannot determine whether x[y] is always safe, as determining all the values y could take would involve running the program.

So as such, for all the advantages that Rust offers, you can have the same advantages with C with macros and LLVM extensions, albeit with less concise syntax.

https://www.microsoft.com/en-us/research/project/checked-c/

Similar arguments were used to justify Haskel about 6-7 years ago, and Haskel is pretty much dead in the water at this point.

The modern way to make a memory safe language is to focus on a high level language that doesn't require programmer to deal with memory directly, and then work on the compiler to make the resultant code optimal.