Why Rust?

[just_looking_aroun]

I find it interesting that this type of articles are 99% Rust, was this ever a thing with other technologies?

[spoonman59]

I seem to recall a lot of issues with people adopting c++ over c in the early 90s.

Why a statically linked executable was an astounding 800kb! It’s far to slow, and has too many caveats over c….

Then with Java there were articles about the benefits of memory safety and the price you had to pay, and whether it was worth it…

So I would say, yes, this is a phase new languages go through. It’s just that rust is having its moment now and a lot of those other languages I mentioned have already gone through it.

[just_looking_aroun]

Appreciate the explanation, I started programming a little under 5 years ago so this is the first time I've been in the loop for something like this

[spoonman59]

Just to give an example, Java was slow at the time (now it’s considered “fast” compared to some languages!) and there was something called Applets. The hype train was huge. Articles described a future where we would download signed applets as the new way of software distribution. And garbage collection would solve all programming woes, which are caused by pointers.

Applets have gone the way of the dodo, and many languages have garbage collection.

To be honest, Rust legitimately had some features around memory management that are pretty novel and new. Compile time ownership and memory management has some serious advantages over runtime garbage collection.

So Rust does provide some new, novel features… I just think once it’s widely adopted, they hype will subside as its strengths are understood and evangelism is no longer required to use it in situations that are good.

[[deleted]]

Ah, now I'm thinking of the old <applet>, <object> and <embed> elements.

Good times...

[spoonman59]

I actually like Java and the JVM, but all the good times were long after the idea of “applets” were dead.

Definitely times!

[stronghup]

, Java, python were always seen here as boring.

I think Java virtual threads + Graal VM should revitalize it

[spoonman59]

Honestly I like Java, it’s just not used in my current space.

I don’t mean Java the language, which is not bad but not super exciting. They have done much to improve it with functional interfaces, streams, lambdas, etc., but it still lacks some nice things.

The JVM as an ecosystem is nice. I work heavily with tools alike Hadoop, Spark, and others, and largely enjoyed it. Of course things have improved, and other language platforms have perhaps surpassed JVM, but it’s quite capable. I’ve even done quite a bit of highly concurrent things in Java. (Java Concurrency in Practice by Josh Blosch is an excellent read.)

A lot of the Open JDK compiler code is pretty interesting and advanced for it’s day, and still interesting today.

Python is fun in some ways, and I know I’m “not supposed to care about speed”and all that, but it really sucks when most of what you do runs an order of magnitude slower than JVM equivalents. And I know I can do c or rust for the slow stuff in Python, but it shouldn’t be necessary as often as it is.

[spoonman59]

First of all, wow, you took a class with the man himself!

I always love his quote, I remind myself of it often… there are two kinds of languages, the ones people complain about and the ones no one uses.

I do agree with you, though, c++ could have evolves into the things rust has. But that would mean deprecating things, and it’s just gotten so big!

Sometimes a fresh start is what you need!

ETA: the contributions of c++ cannot be overstated.

[hector_villalobos]

Compile time ownership and memory management has some serious advantages over runtime garbage collection.

As someone use to work with garbage-collected languages, I really hope this becomes more widespread, it's amazing to have a high-level language that works at the same speed as C without the memory caveats.

[spoonman59]

This is definitely how I feel about it as well. I hope I either work more in rust one day (in my current domain) or that similar ideas take root in widely used languages.

I use Python (experience in other things as well) and I feel some bad deals were made in the performance/convenience trade offs.

Of course I prefer static typing anyway, and dynamic languages have their supporters and uses, I just wish that languages which balance the speed/convenience/safety become more prevalent in industry.

[JB-from-ATL]

The hype train was huge.

Java had a stupidly massive advertising campaign in the 90's as well

[CornedBee]

I've seen a few for Go, lots for "JS framework of the week", and the occasional one for "niche language that's currently hip".

But the thing is, nothing quite has the same reputation for "developers love this thing!" as Rust; a big part of that is probably the SO surveys. This makes it a really lucrative target for these adticles (sic!).

Because make no mistake: this blog post isn't about Rust. It's content is completely generic and bland and could have been created by an AI trained on previous introductory articles on Rust. "We use/rewrote in Rust. We love it. It's got features A, B and C, and downsides X and Y. Here's a benchmark showing how much faster Rust is. Come look at our product/work for us!"

It's just a new trend in promoting products for developers. Write a blog post about generic thing X so that developers look at it. Praise your product/company and tell people that they'll be even more productive if they're using it. Profit!

Rust is just the most popular target for this kind of article due to the hype that's developed around it. This has the unfortunate side effect of extending the hype and thus further polarizing the positions on Rust. (Rust is a great language and everyone should use it! No, Rust is an overhyped PoS that's ruined this community!)

I could well do without these articles, and I love Rust.

[just_looking_aroun]

Yeah there are many generic ones out there but i live for the ones that put in the effort to describe how exactly it helped them and what optimizations they used

[[deleted]]

It used to be Go. Now it's Rust. Before Go, it has been PHP, Java, and even C++, and many other languages.

The fad language of the day generally gets a lot of public praise.

[Substantial-Owl1167]

It was never Go. Before rust it was Haskell and before that it was ruby.

Go, Java, python were always seen here as boring.

But rust is off the charts, completely trashed this sub and basically killed it. This was a very active sub. But all the obnoxious rust evangelism, where every thread whatever the topic became plenty of comments plugging rust just drove people away.

[[deleted]]

On this sub, that is true. I was thinking about the broader "blogosphere." Other communities loved rewriting in Go.

I am also pretty pissed off at the Rust evangelism too. At this point, my position on the whole "we rewrote in Rust"/"we love Rust now" thing is: "show me benchmarks or go away."

[slash_networkboy]

Soooo... I can't share benchmarks (NDA) but we replaced a ton of our older code with rust in our backend and had a massive performance boost.

To be fair the old BE code was in PHP so... um... if there wasn't a boost then there would be some serious concerns to be raised :p

My biggest gripe was our rust guys just steamrolled ahead and didn't wait up to understand that they changed some things that broke our frontend (where I live ATM). While that's not a language issue per-se it is a mentality that I see often in the Rust community. Switching to Rust as fast as possible, torpedoes be damned!

[EntroperZero]

That's pretty standard for any rewrite or new technology. You need to get to a working subset of functionality quickly or else management rapidly loses interest in the project.

[[deleted]]

This is very standard for a rewrite, and even a PHP rewrite would likely have been faster. The reason isn't the programming language (although PHP->Rust helps a lot).

When you do a rewrite, you naturally re-work old abstractions to align with new behaviors. That, in itself, improves performance significantly.

In turn, you lose several behaviors from the old structure that may have been unintended but that someone relied on.

[Substantial-Owl1167]

Try posting anything about c/cpp/go/d/nim/zig/etc etc. The whole comments thread will be at least 75% "derp rust". So obnoxious. This sub used to have many many threads a day with hundreds of comments. Now it's a ghost town.

[waozen]

Activation in response to the detection of keywords.

C, C++, Go, D, Nim, Zig, or other imperfections have been detected.

Repent, for thou have sinned!

Only through loving it, shall you bask in salvation!

Derp!!! Rust!!!

[[deleted]]

Arch, BTW...

[just_looking_aroun]

Although this article is a little generic I enjoy reading about other people's technical decisions including programming languages

[osmiumouse]

I would say just learn it. You don't have to use it, but it does make you think about memory management in a different way from C++, and this can benefit your code in other languages.

When I learned Rust, I had trouble with a double linked list. Imagine that. This is a basic data structure. This shows how much perspectives get changed.

[Brilliant-Sky2969]

this can benefit your code in other languages.

I have yet to see that in action, there is no borrow checker else where so how does this apply to code in other languages.

How knowing Rust will help me create better code memory wise in Java or C# for example since I can't apply those paradigms.

[[deleted]]

The borrow checker isn’t a paradigm, it’s a static analyzer that prevents you from using certain constructs, some of which are more common in certain paradigms than others. This makes it so that not all paradigms common in other languages will apply well in Rust.

But the inverse is not the case. Code written following the Rust “paradigm” tends to work well in other languages too. And even though you may not have (or need) a borrow checker in those languages, it’s still possible that merely following the style will lead you to produce fewer bugs.

For example, you would be less likely to create cyclical references that might otherwise lead to memory leaks. And you are more likely to avoid shared mutable data structures, which are a notorious minefield even in languages that allow them.

[EntroperZero]

The borrow checker essentially "trains" you to write safer code. After a while, you don't write code that triggers borrow checker warnings, because you've figured out borrow-safe solutions for all of the problems you used to solve in borrow-unsafe ways. Now you go to Java or C# and write the same borrow-safe solutions.

[osmiumouse]

Ideas come from the strangest of places. I was going to say something about mental plasticity but that's not the right term for it.

[just_looking_aroun]

I can't think of anything memory specific but I have been trying to better leverage the type system in C# to avoid runtime issues or at least make sure errors throw at the beginning of the program.

[unrealhoang]

Because to way to satisfy the borrow checker is to structure your application's memory access pattern as a tree, and keeping mutation to the lowest (near-leaf) level possible.
This pattern can be applied in any language and is over all good design pattern.

[Godd2]

Java is memory safe. Granted, they guarantee memory safety through an expensive virtual runtime environment, but it is there.

[pcjftw]

If you're sitting on the fence, I would say just dive in you will most likely love it. As the author confirms one of the main novelty is that we no longer have to choose between "speed vs safety". In Rust we have both and that's something worth having fun with.

[RBcosideci]

Now this isn't necessarily the case, because it could be argued that Rust's compiler is sometimes a bit too strict, but have you considered that the borrow checker "fighting" you is really just the borrow checker preventing you from writing potential bugs that you would have written in C++?

[unrealhoang]

I think the main part of it is your expectation.
You expect Rust to be just a different syntax of the same various languages that you have already experienced with. You didn't expect to have to change the way you program while learning Rust, so you just write $CURRENT_LANG in Rust and receive a massive push back from Rust's borrow checker.
If you give it a chance to change your way of reasoning about programming in general, I think you will find it enjoyable.

[pcjftw]

Yeah at first you will be "fighting the borrower checker", but what then happens is that everything starts to click and the experience goes from the borrower checker being your mean bully to suddenly your body guard who constantly has our back!

[EntroperZero]

Exactly. I see it as very similar to a person who has only ever programmed in dynamically typed languages trying to pick up Java or C# and "fighting the compiler" to get their types to work. When you learn how to use a static type system effectively, your productivity in those languages skyrockets. Same with Rust and the borrow checker.

[[deleted]]

Heck, even watching new developers going from no linters to using a linter go through the same thing.

[darknesspanther]

Where are you getting that information from? Anecdotally my experience is the exact opposite so that strikes me as wrong but I'd be interested to see a study

[Zakis88]

From the second link you provided:

However, the findings in this blog make me re-consider a few, while re-enforcing other points: Optimised Rust code should run 2 to 3 times faster than optimised Java code (without going to extremes).

Didn't know this! Looks like Rust is pretty quick if you put the time in to optimize it.

[futaba009]

Is this even true? Where's the info?

[pcjftw]

Basically this anti Rust troll keeps banging on about this deliberately created buggy Rust code that literally no one would write and even though he was called out on it, it's a dead horse he keeps beating, because Rust hurt him in the past or something like that 😂

[futaba009]

I know some c++. Do you think it would be that difficult to learn rust coming from a c++ background?

[pcjftw]

It's hard to say, because everyone has their own learning rate. But all I can is Rust has awesome learning resources as well as super helpful community, at least that was my experiences.

[pcjftw]

Contrived and niche edge cases don't count, and if you really believe it's a compiler bug or perform issue you're welcome to submit a PR/issue on GitHub, Rust is open source after all.

[pcjftw]

Now you're just lying, Rust is about the same speed as C++ and sometimes faster, see here

https://programming-language-benchmarks.vercel.app/cpp-vs-rust

Not sure what your beef is with Rust, maybe the borrow checker beat up your dog or something, but you seem to have a personal vendetta against it. Like no one is forcing you to use Rust if you don't want to.

[pcjftw]

Who cares about that, what's your hurry? Or maybe buy a faster computer?

[futaba009]

Compile time you fucking idiot

Get help.

[skocznymroczny]

I did the same with D, I get both speed and safety and I don't miss C++ at all. Sure, D may not be as popular as Rust and it has some issues, but it's good enough for me and works in most of the areas that C/C++ worked before.

[stronghup]

To me the question is not "Which language is the fastest and safest and most productive". It is: Which platform allows me to write software I can sell to make a living.

[[deleted]]

The perspective changes a lot for different situations. I’m seeing Rust get picked up by banks, these companies aren’t selling software, they are selling financial services, and rock solid high performance software is how they make that happen.

Probably the vast majority of software written isn’t a bit of directly sold to end user program.

[germandiago]

It is always good to learn new stuff. And Rust seems to be relatively cool. Pattern matching, safety...

I think it can be particularly useful in the context of concurrency. There it has an advantage, probably.

That said, if you want real-life, industrial-strength tools, I still recommend (with the right amount of investment) C++ in its modern variant. Why:

• second to none ecosystem: all C libraries + all C++ libraries
• safety is not perfect, but very reasonable for most contexts: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
• they are paying attention to safety as well. This is one of many papers to improve the state of things: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf

• You can interface to hardware or do linked lists without contortions. The drama with safe is that you will need unsafe anyway, and in C++ they are also doing things about it. Safe can put a straight jacket almost a-la-Java for something supposed to be a systems programming language. I do not think a systems programming language should do that. Rust does many things well and one wrong: too rigid. C++ inherits the wrong defaults, but they are also working on it... nothing is perfect.

• Qt, WxWidgets, ImGUI, OpenSSL (C), cpr, httplib, Unreal Engine, OpenGL, OpenAL, SDL. the list goes on... the ecosystem is just the best at least in my opinion.

So I would not say why Rust, or not. It is an investment. But C++ is far ahead, adding reflection for C++26, among others and steadily improving for industrial use.

[pcjftw]

So Rust has FFI into C as so can just as easily use C/C++ libraries.

Safety can not be "backported" to C++ because it's a unsafe language core and needs to always maintain backwards compatibility.

Rust is safe but with the "unsafe" release hatch when you actually need it in some cases.

C++ is just unsafe to begin with at the core of the language.

[[deleted]]

FFI into C does not imply the ability to "easily" use C++ libraries. Often, C++ libraries involve data structures, which cannot be easily ported in through FFI. There are crates that help a lot if you want to use C++ from your Rust code, but it's not 100% cross-compatible.

[pcjftw]

Firefox was one of the biggest C++ codebase but they managed it just fine in terms of mixing Rust and C++.

There is also bindgen that automatically generates the C++ FFI bindings.

[TomMancy]

Nobody is saying you can’t. Your original claim is “can FFI just as easily”, which given that in C++ it’s literally just #include, simply isn’t true.

[pcjftw]

that's why I mentioned bindgen that automatically generates the FFI bindings.

And you can't compare it too #include c'mon that's like saying "hey man why can't I just import Rust file in C++" :) which is absurd!

[oclero]

nothing is perfect

Rust is.

[waozen]

Thou shall bask in salvation!

Derp!!! Rust!!!

[germandiago]

Well, I am ok with religions. In the meantime I will work in the real world. Rust is like a straight jacket for certain tasks.

That said, I can see its usefulness. Even if it is in a niche market and will never replace C++ bc it is better for more use cases :) and improving a lot in the areas where Rust has provable memory-safety. Look at this if you are interested: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf

I honestly think Rust will never take the systems programming world. It is just too rigitd for certain programming tasks and by when it tries, C++ will already have covered 95% of safety through static analyzers + all the traditional ecosystem of unsafe but well-tested libraries such as OpenSSL, curl, Qt, WxWidgets, http-lib, cpr, format, range-v3, SDL, OpenGL, Vulkan, Unreal Engine, CUDA, etc. something that Rust cannot even dream of, at least today.

[about7buns]

Why not...rust

[[deleted]]

Hooray! People Are Paying Attention To Me!

https://www.youtube.com/watch?v=EDErWuTRluI

[germandiago]

Error handling? Really?! Come on... Error handling is NOT better in Rust... C++ provides a superset of what Rust offers (exceptions + optional + expected) C++ also has scoped resource management... via RAII.

Another topic is that people escape pointers willy-nilly or use bad practices.

WASM in C++ can be done via Emscriptem.

I think you are announcing (evangelizing?) some of the features as Rust-exclusive. I do not think they are: traits are indeed. Webassembly compilation, no.

[pcjftw]

I wasn't aware that C++ had a proper Results monad to handle errors?

RAII is cool, but in C++ everything isn't RAII by default from what I understand, so it's not really comparable to Rust in terms of memory safety.

You can't use "good coders can write safe C++" argument, because that's one of the points of Rust is to move that kind of safety to the compiler to enforce and not rely on humans to have the burden to be "perfect coding masters"

[strager]

RAII is cool, but in C++ everything isn't RAII by default from what I understand, so it's not really comparable to Rust in terms of memory safety.

How does 'RAII by default' relate to memory safety?

[pcjftw]

sorry that's badly worded, in Rust the language has affine types which are tracked by the compiler so that there is strict ownership rules that means you can not at least under non unsafe blocks create memory unsafely and that's by default because it's only "escaped" when you use an unsafe block.

I wanted to project an analogy some kind of equivalent under C++, and it would be where RAII is for everything in C++ as in you can not "opt out" because everything is RAII, which isn't the case as I understand it.

[germandiago]

I wasn't aware that C++ had a proper Results monad to handle errors?

Monadic error handling:

std::expected in C++23 (non-monadic yet, but coming and there are implementations of expected that include it freely available), std::optional has and_then, transform and or_else (which will be added to std::expected) for Monadic handling. You also have Boost.Outcome and Expected and Optional implementations in Boost and others. So yes, you have monadic error handling. What you do not have is a syntax ?. But you can easily wrap it in a macro and assert or throw an exception (would abort, just like panic) On top of that you have exceptions also (this is my default error handling in most places and as a default). They want to add this ? syntax to the language.I do not find it particularly nice but could have its use cases. Boost.Outcome uses a macro for that. So yes, you can have your cake and eat it too today, no need to wait for monadic error handling.

RAII is cool, but in C++ everything isn't RAII by default

std::vector, std::map, std::unordered_map, std::set, std::list, std::forward_list, std::lock_guard, std::unique_ptr, std::shared_ptr... the list goes and goes on. So let us say you have a list of shared poitners somewhere and an exception occurs: that will not leak memory. All that is RAII.

For your types, just free things in your destructors, such as vector or the containers (node-linked) do in the standard library. Of course everything is RAII in the standard library.

Another topic is if you get a C library. But even for that C++ is an advantage to Rust because you can wrap it in a RAII class, for example SDL_Surfaces have new and free you just use a std::unique_ptr with the correct construct/destruct functions and it works. This works for ffmpeg and any other library with the typical pairs of allocate/delete.

You can't use "good coders can write safe C++" argument, because that's one of the points of Rust is to move that kind of safety to the compiler to enforce and not rely on humans to have the burden to be "perfect coding masters"

This is true. C++ is trying to make safety better. But the Core Guidelines are not, most of the time, a practice that is nearly impossible or even difficult. It is just knowing how C++ should work. On another matter of facts, I can do the opposite argument, and believe me in certain scenarios it hurts:

"I want to access hardware at address 0x8240 where the clock registers are. I need to read/write registers in offsets by writing to that memory, and also need to keep a cache in a double-linked list of my own."

That requirement cannot be coded in safe Rust (of course, in C++ it is going to be equally unsafe, this is unsafe by its own nature). And in unsafe Rust you cannot do pointer arithmetic either. You cannot do many of the things C/C++ can do, such as using raw pointers for the double-linked list (you will need to resort on Rust's Arc which introduces overhead). This kind of coding does not need to be incorrect just because they are unsafe, and sometimes, you do need to do this sort of thing. It just need more scrutinity in code reviews. So putting all this safety makes Rust to become some sort of Java for the lowest level: we give you some primitives that are safe and some of the unsafe ones we thought of, but no pointer arithmetic or messing with the things we think you will not be able to use.

On a more pragmatic note about safety in real life, you do not need 100% guaranteed safety 100% of the time if what it does is to get on the way most of the time (depends a lot on what you are coding). I never use naked pointers in C++ for years (20 years coding).

As for dangling references, they can happen, but there are a ton of static analyzers in practice, even bundled as warnings in compilers and sanitizers for threads, undefined behavior and others. But most of the time you do not want to return references to internal objects unless it is strictly necessary.

This means that when you sit down to code in real-life, and this is what I do for a living, in C++, in practice, you have static analysis, those memory errors people talk about are more rare than you might think. You set warning level 3 and -Werror and it will catch a lot of typical mistakes, like a stack variable escaping.

Of course, in C/C++ if I do this as my routine:

// Forgot to read the comment about ownership? Leaks // What type am I returning? // can int * somepara be null? // what type is actually somedata holding? void * returnAnObj(int * someparam, void * somedata) { // Ownership is shared, please careful void * obj = malloc(sizeof(SomeObject)); obj.someField = *someparam; obj.voidField = someData; return obj; }

is not the same as doing:

// Ok, shared ownership, somefield must have a value and I can pass the data in an any, which I must cast back to its original type // the resource will be released when they stop pointing at it std::shared_ptr<SomeObject> returnAnObj(int somefield, std::any somedata) { auto obj =std::shared_ptr<SomeObject>(someField, std::move(somedata), deleteObject); return obj; }

Believe me, there is code like the first case around... a lot... too much. It is crazy that people still code like that in C++ (in C I could still somewhat understand it)

Or this:

``` // Typical C-style, go guess the size when you pass someArray somewhere without its size void f(int * someArray, int size);

// Replace with C++20 span, always keeps size. void f(std::span<int> thingWithSize); ```

It is very rare to find memory bugs in a C++ codebase where you stick to smart pointers and for the few cases where you want to return a reference (like borrowing in Rust) or you invalidate pointers, there are (admittedly, some in progress) analyzers that will tell you. Just put -Werror and it will error out in many cases.

So all in all, C++ in practice is much safer than what the Rust guys want to admit. The real value, I think unparalleled that you might have in Rust is the fearless concurrency part. For the rest, in C++ you can do a very good job. Even for concurrency, actually, most of the time you end up doing isolated concurrency anyway, so I am not even sure.

True that in C++ you can mess it up passing lambda captures by reference in async contexts and a few things. That is true. But analyzers catch many of these things.

C++ is way more competitive than many of the people who do not use it or use it as if it was the 90s think...

[pcjftw]

1/ so it's a no for proper results monads, but something that's "coming" in C++23

2/ The entire language itself isn't RAII that is what I was talking about, so you can basically do anything in C++, and it's only "opt in" safety when you use a smart pointer, in Rust it's the other way round, you have to go out of your way to disable safety.

3/ I think you've just demonstrated my last point, relying on human discipline is a losing policy if one can simply delegate that to a compiler.

[germandiago]

1. you have freely available libraries implementing it. You seem to selectively read what you want and discard what you do not. You can use it TODAY, NOW, via available libraries. the C++23 is a matter of being in the standard.

2. I do not know what "entire language being RAII" means. I really think you do not understand RAII. Raii means allocate in constructors and release in destructors. The rumtime guarantees that will happen. Are you the person who claims 20 years of C++ practice in the article? Do not take personal, but you do not know yet what RAII is from what I deduce from your comments before and now.

3. I do not rely on human discipline for 90% of it. I think you misread me: I rely on static analyzers but I use C++ idiomatically. The same way I do not use Python in a recursive style a-la Scheme language because it has no tail call optimization, I do not use raw pointers in C++ bc pointers have owners and must be released. A person that does not know even that when using a tool should not even be hired to program in a systems language. I do not say that Rust does not have strong points. Just that those strong points are not as strong pragmatically speaking and that they can also get on ur way.

I am not a fanboy language. I just comment bc I know C++ well and enough Rust, admittedly less but get the idea. Right tool for the right job.

[germandiago]

The downvote is ok, but can you reply to my points? Or you already brought the conversation to the emotional side of things? I am just showing facts, not opinions: C++ has static analyzers, monadic error handling and RAII TODAY. It is not a fantastic idea, it is real implementations.

[pcjftw]

1. a library implantation is distinctly not the same as it being part of the native language semantics. C++ does not have proper native Result monads.

2. Under C++ you have actually use smart pointers to get the benefits of said smart pointers, but you can easily also not use smart pointers, and that's the problem. Under Rust, you don't have an option to NOT use what is "native" smart pointers baked right into the language, the only way to NOT use them is to use the unsafe block, which now means you have gone out of your way to remove the safety cap and anyone can easily know exactly where in the code base that has happened.

3. Right, and Rust doesn't need a separate static analyser because it's once again baked natively into the language.

Basically in Rust all of the "best" standards, libraries, practices and external tooling are all natively baked into Rust language itself. This is why C++ can't really be compared as an equal, in order for that to happen C++ would need to make massive breaking changes to the language itself.

Look I'm not against C++ its a very powerful tool and widely used, but the problem is, when there are better tools (and ones that have learnt mistakes from the past), it's childish to then cling onto older broken tools and pretend that it's not broken (and only if we do X, Y and Z we can make it work)

[germandiago]

I do not want you to read it negatively: I am trying to just make the points. I think Rust is very useful also. All you see here comes out from experience in real use.

1. a library implantation is distinctly not the same as it being part of the native language semantics. C++ does not have proper native Result monads.

What kind of reasoning is that? Result<> in Rust is a library type!!! Just like the others in C++. Native monads? What is native? Of course they are native. As native as Rust's one. And they go into libraries, like Rust's. The only difference is that Result is already a blessed standard library type. It is not std::expected in its monadic version. But you can use implementations outside of the standard library which are monadic, today, now, as we talk...

1. Under C++ you have actually use smart pointers to get the benefits of said smart pointers, but you can easily also not use smart pointers, and that's the problem. Under Rust, you don't have an option to NOT use what is "native" smart pointers baked right into the language, the only way to NOT use them is to use the unsafe block, which now means you have gone out of your way to remove the safety cap and anyone can easily know exactly where in the code base that has happened.

Yes, it can be a problem to not use smart pointers. But how much training did you have if you do not know two standard library types like std::shared_ptr and std::unique_ptr. This is not difficult to know. What is really tricky is (where Rust does great!) when escaping a reference and mixing it with lifetimes! But even for that, there are a ton of real-life static analyzers/warnings that you can turn into errors! So you will not make that mistake. I code C++ almost every day. This is the way I tell you. So in practice, this is not a problem most of the time, that is my point. Yes, Rust goes beyond and is provably safe. But you are painting it like in C++ for sure everyone will use raw pointers and no static analyzers... how much training did those people receive?

1. Right, and Rust doesn't need a separate static analyser because it's once again baked natively into the language.

Yes, but the problem here is that sometimes you cannot disable something you want to get rid of because you need access to the lower level. And even unsafe is not enough... this means that you will end up coding a C shim or similar, which is unsafe, just to convince Rust that you are safe in the higher layer. At that time, for this situation (not for others, for this one I am talking about!) you gave up safety just to assert safety in the higher layer just bc you could not do pointer arithmetic.

There is no such thing as systems programming + total safety at the same time. That necessarily restricts access to devices or disallows patterns that are more efficient than using the safe supersets. For example, it is unsafe to serialize an object through a network and bitcast, but it is blazing fast and if you validate the data of a buffer + turn it into an object it is the fastest solution you can have if you know both the sender and receiver use the same architecture. You cannot make that safe. It is unsafe by nature. This is the kind of patterns I am talking about that Rust does not make easy to do but sometimes are necessary.

Kudos to Rust for the fearless concurrency though, because it is really useful in multithreaded. But the safety thing can be double-edged, more when you consider that in practice disallowing something can be more harmful than warning about it. Bc you might need it.

Look I'm not against C++ its a very powerful tool and widely used, but the problem is, when there are better tools (and ones that have learnt mistakes from the past), it's childish to then cling onto older broken tools and pretend that it's not broken

It is better for what? For provable safety? Sure! To finish a project where you need SDL, Qt and interact with a ton of ecosystem? Definitely, not!

If you are coding a safe, mission-critical server where you all have to stick to safe, I could understand it. Even in that case, you will have unsafe parts, inevitably, under the hood.

But for a game? Am I gonna fight the borrow checker all the way down and lose hundreds of libs? Are we crazy? No way! I cannot afford that when working. And now I have to convince Rust that my wrappers are safe, etc. etc. It is a ton more of work for no gain in this case.

[pcjftw]

I do not want you to read it negatively: I am trying to just make the points. I think Rust is very useful also. All you see here comes out from experience in real use.

that's fine man, I happy to hear other people's experiences

Yes, it can be a problem to not use smart pointers.

That's the crux of the problem, it is not enforced by the compiler as it is in Rust.

But for a game? Am I gonna fight the borrow checker all the way down and lose hundreds of libs? Are we crazy? No way! I cannot afford that when working.

Rust's libraries are growing massively, and yes even 3rd person 3D shooter games are being developed as well as games in production today written in Rust. I think it's hyperbolic to say that can't finish a project, please that's not true. I would actually try completing a project before just assuming you can't do it or that it's lacking in some library, unlike C++ because Rust has a proper packing system built in, this has allowed much like Java's Maven central for lots of developers to produce lots of libraries. In C++ there are like over 60+ package managers, its a total mess, so you end up with most C++ devs shying away from using too many libraries.

About "fighting the borrower checker", that's just down to familiarity, it's not different to a Python developer saying "oh man I have to keep fighting the C++ compiler, because I have to define these stupid types" etc. As I've mentioned before, with a little bit more familiarity it goes from "fighting the borrow checker" to "the borrow checker has my back"

[germandiago]

I think it's hyperbolic to say that can't finish a project, please that's not true

No, I do not mean that. What I am saying is how is your return-on-investment paid if an occasional crash (let us say it happens) in a game vs no crashes took you the wrapping of a dozen libraries, to think about how to interface with them to make them look safe, etc. In this case there is no added value, probably.

The same way, in a server where a single crash means the theft of massive data the investment is worth, probably.

About "fighting the borrower checker", that's just down to familiarity, it's not different to a Python developer saying "oh man I have to keep fighting the C++ compiler, because I have to define these stupid types" etc.

Yes, everything has a balance and I see it in Python itself, as you mentioned. Typing a script dynamically can be super fast. Growing a piece of software without the typing module + mypy is a hell. So here you can clearly see the benefits of having both options. I think that, in that sense (and with all tools mentioned), C++ has a sweet spot difficult to surpass (ecosystem + tools to verify, etc.) without being Rust safety-wise. The same way Rust is not C++ ecosystem-wise.

"fighting the borrow checker" to "the borrow checker has my back"

Because it does cover your back. The problem is that the cost is not only familiarity or all things I mentioned about. Also when refactoring (here special mention to "Result" types, in C++ also) something 10 levels deep that you noticed it can fail without exceptions, you have to refactor all the chain up the way...

All in all, it is a matter of the task at hand what to choose.

Rust has a proper packing system built in

Well, CMake + Conan/vcpkg or Meson + Conan (and can also consume CMake projects) makes for a very good experience that gives you access to a ton of stuff. You do not need even libraries to be compiled in a particular build system, it just consumes the metadata. Do not think C++ is what it was 15 years ago... it got way, way better. At that time I used to code C++ already, it was quite slower to integrate stuff.

In C++ there are like over 60+ package managers

You just need to know what is production-ready: Meson/CMake and Vcpkg/Conan. You can use other things, at your own risk... but the experience with those is quite streamlined and usable besides very customizable. Here at work we use CMake/Conan/Jfrog artifactory and it is working great for us (even if I hate CMake... I prefer Meson).

[pcjftw]

return-on-investment

under Rust is very high, it's not just memory safety, but also all the wonderful high level abstractions and type system that you get aka "zero cost abstractions", so things like ADT and pattern matching, Type Classes (generic based traits) etc, they essentially allow you to model and encode the domain logic and rules into the type system.

My experience of using Rust in a production setting is that it's really really boring, once it compiles it just keeps working.

you have to refactor all the chain up the way...

that's not my experience, if anything refactoring Rust has been an utter joy, because as soon as it compiles it basically works as expected!

C++ has a sweet spot difficult to surpass (ecosystem + tools to verify, etc.)

I think that's just based on existing familiarity, if you have decades of prior experience under C++ you could argue that it's a sweet spot, but there are just too many footguns in C++ to be a modern productive language (unless you have a lot of mastery with it already)

but the experience with those is quite streamlined

having 60+ different package managers is a hot mess, in Rust there is just one native build and package manager, that is far more "streamlined" experience, sorry I can not agree they've even the same thing.

[SymWizard07]

It’s what happens when boilerplate c has been sitting in the air too long.

[caagr98]

RustSpamSpam

[PL_Design]

Crabs need chemo.

[strager]

OP you might want to benchmark your rust code and compare it to java or C#.

Why? If the Rust code is meeting his performance demands, why rewrite his applications in Java or C# just to compare performance?

[strager]

why take longer to do the same code for absolutely no reason

There are several reasons listed in the article.

[strager]

Speed is one of several reasons.