[abuyalip]

I still don’t buy this “safer more modern” mentality. Modern C++ pretty much solves the safety issues. People need to learn how to use tools properly.

If you ask me, Go is a better Rust. Rust is an ugly version of C++ with longer compile times and a band of zealous missionaries.

I mean the keywords mut and fn very annoying to read just get rid of them or spell the f*n thing function.

[panstromek]

> Modern C++ pretty much solves the safety issues.

I always wonder how can one come to such a conclusion. Modern C++ has no way to enforce relationship between two objects in memory and the shared xor mutable rule, which means it can't even do the basic checks that are the foundation of Rust's safety features.

Of course, this statement is also trivially debunked by the reality of any major C++ program with complexity and attack surface of something like a browser. Modern C++ certainly didn't save Chrome from CVEs. They ban a bunch of C++ features, enforce the rule of two, and do a bunch of hardening and fuzzing on top of it and they still don't get spared from safety issues.

[GoblinSlayer]

FWIW Chrome includes third party libraries like freetype and lots of bugs are in javascript. I imagine defensive checks in javascript will be controversial since performance of javascript is controlled by webdev, not by browser.

[Koranir]

Note that Chrome is replacing[1] FreeType with Skrifa[2], which is a Rust-based library that can handle a lot of the things FreeType is being used for in Chrome. A lot of Chrome's dependencies are being rewritten in Rust.

[1]: https://developer.chrome.com/blog/memory-safety-fonts

[2]: https://github.com/googlefonts/fontations/tree/main/skrifa

[abuyalip]

Yeah sure. Thing is, C does just fine people are making “safe” ways to run libc. Rust is a complicated monstrosity with a bunch of “unsafe” sprinkles.

What does the memory safety even matter when hackers poison heavily used crates?

[nicoburns]

> Modern C++ pretty much solves the safety issues.

The statistics from projects that have adopted Rust and measured the effect say otherwise. See https://security.googleblog.com/2025/11/rust-in-android-move... for example.

[steve1977]

This article is not really specifying if Rust is compared against "Modern C++" or "Old School C++". The only thing we can assume is that at least part of it is "Google C++".

Maybe we would see similar effects adopting Modern C++. Maybe not. The article doesn't tell us.

[bogeholm]

Yeah I guess most True Scotsmen write modern C++ after all.

[staticassertion]

This is a very shallow, very boring criticism. I doubt it will resonate. Modern C++ does not solve the safety issues, it has plenty of brand new footguns like string_view. Who cares if Go is better than Rust? Feel free to write Go, no one cares.

"mut and fn very annoying to read" like okay lol who cares? What should anyone take from your post other than that you aren't that into Rust?

[hypeatei]

> Modern C++ pretty much solves the safety issues

The data says otherwise, three overflows and two UAFs this month in Chrome alone: https://www.cvedetails.com/vulnerability-list/vendor_id-1224...

[josephg]

> Go is a better Rust. Rust is an ugly version of C++ with longer compile times and a band of zealous missionaries.

Eh. There's a lot I like about Go. I adore its compilation speed and the focus on language simplicity. But its got plenty of drawbacks too. Default nullability is a huge mistake. And result types (zig, swift, rust) are way better than go's error handling. Sum types in general are missing from Go, and once you start using them its so hard to go back. Go also doesn't have anywhere near as good interop with native code. Mixing C (or any other LLVM langauge) with rust is easy and feels great. You even get LTO across the language barrier.

The big thing I'm growing to dislike about rust is how many transitive dependencies a lot of projects end up pulling in. Its very easy to end up with projects that take a million years to compile & produce huge binaries. Not because they do a lot but simply because everything depends on everything, and the dependency tree takes a long time to bottom out. I don't know what the right answer is. It feels more like a cultural problem than a language / ecosystem problem. But I wish rust projects felt as lightweight and small as most C projects I've worked with. I'm doing some work with the stalwart email server at the moment (written in rust). Stalwart is a relatively new, well written email server. But it somehow pulls in 893 transitive dependencies! I'm not even joking. Compiling stalwart takes about 20 minutes, and the compilation process generates several gigabytes of intermediate build assets. What a mess.

[nicoburns]

> Compiling stalwart takes about 20 minutes

20 minutes! What hardware is this on? I've worked on Rust projects with similar numbers of dependencies where the compile time (for a clean release build) was 2-4 minutes (on a MacBook M1 Pro)

[nicoburns]

UPDATE: tried compiling stalwart on my machine, and it took 14 minutes, with a really weird timing profile:

- 99% of the ~700 crates were done compiling in about a minute or 2 - RocksDB (a C++ dependency) was 2 minutes by itself - And then it took 10 minutes (ten!) just for the final binary at the end.

That's not normal for Rust code at all. Even large ones like Servo or Rustc or Zed.

UPDATE2: turns out they have LTO enabled by default. Disabling that brings the compile time down to 7 minutes. But that's still really unexpectedly slow.

[josephg]

Disabling codegen units = 1 speeds up the compilation further. But it’s still too many dependencies and too slow. The binary is pretty huge too.

[nicoburns]

> But it’s still too many dependencies and too slow.

I definitely agree that it's too slow. I just don't think the cause is "too many dependencies" because I've compiled Rust codebases with twice as many dependencies in half the time!

It seems to produce a 94MB binary. So it may be partly that there are some very big dependencies. But the amount of compilation time that ends up in the top-level crate (even with LTO disabled) also makes me feel like this must be triggering a compiler bug. Either that or using far too many generics.

[jason_oster]

I agree it's probably monomorphization (speculation without looking at it). Generic function parameters might be the root cause, but number of dependencies is a combinatorial multiplier.

I've hit compiler bugs that behave this way. Here's one from an LLVM upgrade [1]. The test case I discovered apparently took over 20 minutes to compile, up from 26 seconds on stable! Their value tracking algorithm was accidentally quadratic.

[1]: https://github.com/rust-lang/rust/issues/137909

[jason_oster]

> But it’s still too many dependencies and too slow. The binary is pretty huge too.

Ah yes, my never-ending crusade to raise awareness that the cost of free (as in effort) dependencies is bloat.

You can make useful tools that are tiny and compile fast [1], but it takes a lot of effort; exactly what developers don't want to spend.

[1]: Like https://github.com/parasyte/hd -- And I wrote about one of the tricks that it uses: https://blog.kodewerx.org/2023/04/improving-build-times-for-...

[9rx]

> Sum types in general are missing from Go

Not quite. It doesn't have tagged unions, which is what I expect you are thinking of, but it does have sum types.

[josephg]

Only by abusing interface {}. The result is horrible.

Go doesn’t have sum types as a first class primitive.

[9rx]

Using interface as it was designed to be used offers first-class sum types. Although not all interface use equates to sum types.

But they're not tagged unions. I expect that is still where your confusion lies. Tagged unions and sum types are not equivalent. Tagged unions are a subset of sum types.

[josephg]

This may be a bit too pedantic, but I consider interface {} to be a way to do polymorphism via type classes. Interface defines an open class of types which implement some interface.

Sum types are a type definition defining something as A or B. Not “anything that quacks like a duck”. But concretely “one of this or one of that”. This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants. The compiler doesn’t need to heap allocate enums because it knows the maximum size of a single value. The compiler and programmer can take advantage of the knowledge that there’s a closed set of values the type can hold. It’s not an open type class.

Result and Option are quite beautiful as sum types. But they’re horrible as type classes. Try implementing them using interface{} in Go. It’s not the same.

[9rx]

> Interface defines an open class of types

But can also define a closed set of types, perfectly satisfying "sum types".

> This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants.

Go does not provide this out of the box, but that is not prerequisite for sum types. The mathematical theory says nothing about "the compiler must produce an error if the user doesn't match call cases". There is sufficient information provided by the sum types if you wish to add this to your build chain yourself, of course.

[lock1]

I'm curious, if tagged unions are a subset of sum type, what is your definition of "sum type"?

AFAIK, tagged union is sum type, based on sum type mathematical definition.

[9rx]

On second thought, I agree with your definition. So Go does, in fact, have tagged unions.

[anthk]

If C++ died for services under Unix and medium sized indie games (such as I2PD, or Cataclysm DDA and its forks) and these where rewritten in Go the maintenance would be far greater in these projects. A GC, a much better cross compatibility and your code for sure could probably be compiled in 10 years.

Also CDDA:Bn wouldn't damn need a > 40h long build using 1.5 GB of RAM under an n270 netbook. Ditto with Nchat, FFS, which is worse. A Golang counterpart for nchat as a TG client (and tdlib rewritten in Go) would weight far less while compiling and maybe even the binary itself, and performance wise it would be similar.

I still remember tons of C++ projects from 2005-2009 impossible to compile today but with GCC 4.3 or GCC 4.9, can't remember. Not because of the size, but because C++ incompatible changes over the years. At least tons of C code will compile it today as is modulo some POSIX changes from C code pre 1996. C++ it's something that should died long ago, among stuff like locales under Unix. UTF8 everywhere, use your own currency and the like.

Yeah, I know, game engines, and tons of physics engines and libraries even FLOSS ones such as OGRE, gdal and the like are C++ domain. Still, most of these could be ported to C.

[pjmlp]

The reality of such platform is observable in Inferno and Plan 9, that had no C++ compilers, and while Alef failed in Plan 9, Limbo came to be in Inferno.

Likewise, trying to write pure C or C++ services in iOS or Android is more pain than gain.

[GoblinSlayer]

As for Go minimalism can anybody explain why logcli is so big https://github.com/grafana/loki/releases just to download logs from kubernetes?

[throwaway2037]

    > People need to learn how to use tools properly.

Two things: (1) I see that you are using a throwaway/new account. If throwaway, I have little sympathy for any downvotes that you get. If new, welcome to the community. I hope your share you personal experiences. (2) Nothing gets me more angry than telling highly skilled people it is a "problem between keyboard and chair." ("Oh, you just need to use it correctly.") As a top secret C++ fanboi for more than 25 years, I am just so tired of hearing this bullshit. As much as it hurts me to say it, Rust is better at FORCING programmers to do the right thing... instead of C++ where you CAN do the right thing. In my mind, without a very fast iteration for C++ "dialects" (see the Google project) where teams can trivially enable or disable language features (like multiple inheritance), C++ is a dying language compared to Rust.

[riku_iki]

> C++ is a dying language compared to Rust.

there is a good chance Rust will start dying and will actually die by being replaced by some new hyper-overengineered lang much faster than C++ actually die.