3a2d29

I’m curious if the gaming industry will switch languages, it feels like with the current game engines that it’s heavily entrenched in C and C++. Feels like something like Carbon has the best chance to break in.

It seems to be a “better C”.

Isn’t that what D / Zig try to do? What’s the advantage?

2. No. It is not at the expense of safety. Again, Rust allows you to do unsafe things using the “unsafe” keyword. GC languages simply will not allow it.

3. Strong reference counting memory leaks is not easy to track down. Many embedded systems have been taken down by them.

Speed is the only one you may possibly not, but I think speed is an non-issue. Speed in programming never matters except in the systems space. No one is gonna be able to tell Rust vs Go in a web API and depending on how you do the benchmark, I think many GC languages can probably tie Rust.

Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing.

You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker.

Is there any advantage?

Also to point out, you can 100% leak memory in safe rust

If you forget err != nil, well your value does actually have a value and you would think your result was 0.

"Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.

GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.

1. The risk of future unsafety (a GC language will always safer than rust)

2. Faster development that's easier to change on a dime.

3. No risk of memory leaks (which can happen in safe rust)

This is a great point. I understand liking a language, but don't bring Rust into a GC space (in industry, personal projects can be what you like!) You can find a GC language with all the features of rust you like.

Result<> or Go returning many values is wayyyy better.

Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue?

If you like Result<> or concurrency, use a GC language with those things. Go may not have them, but your choice isn't just Go.

Scripting == interpreted

Is that not the case?

Most workers if you fire 80%, there is an immediate drop in production.

I think the loss of engineers is felt on a more long-term basis.

Over 200 memory safety issues were found in public crates in rust.

If code reviews were all it took to ensure memory safety, then we wouldn’t need the borrow checker in the first place.

And then OP lists only C++ and Rust. Both known well for having no garbage collector. I think my comment is still valid.

OP wants a systems language.

I agree no one writes actual kernels in GC languages. 100% Rust is the best choice where GCs can’t be.

I think my argument is that if you can use a GC, I think it’s considered best practice to use a GC. If you need thread safety, use a GC language like Elixir that handles concurrency well.

Like there’s no reason to act like Java community and try to force rust into every area. It’s very good at what it does, let it stay there.

Isn’t the whole argument rust vs C++ that rust gives you memory safety even though it’s more complex?

Like if you can tolerate memory issues all of the sudden to avoid complexity then there was no argument against C++ in the first place.

Way easier in C# to avoid that issue. Just don’t use reference counters and use GC.

No way to avoid that in Rust. If you need many references, you must use ARC.

Memory leaks in all languages are safe, they just slow performance and cause crashes.

Rust still memory leaks.

Just like it’s harder to have a memory safety issue in rust than C++.

if you are worried about data races, use a language like elixir that’s more safe than rust and is great for concurrency.

If you are a rust dev that forces your language into areas where a GC would suffice, than you are just like C++ devs who refuse to use rust for memory safety.

You are introducing memory issues just cause you don’t want to use a better tool.

It’s the whole case for Rust > modern C++ based on that?

Rust can have memory issues, but “it doesn’t use unsafe as much” as modern C++. Forbidding unsafe code doesn’t guarantee vulnerabilities are gone.

why is it that when talking about C++ memory safety, even a bit more is worth everything, but when talking about rust vs python, suddenly it doesn’t matter if it’s less.