A year of Rust in ClickHouse

While I agree with the general sentiment, while it doesn't sort out all safety issues, actually programming in C++ instead of C with C++ compiler, and making use of the pleothora of analysers would already prevent many issues.

Better be 80% safer than none at all.

It's not only avoid UB in one area, it's about hidden footguns which you may not know about. I have been using C++ for a decade now and there are still UB causes I learn about every week or so.

> C++ can be safe enough if you proceed with care.

The problem with this is if you have a team working on a C++ product you will need some people who can catch memory bugs to review every code before merging. Even with this approach it still possible to missed some memory bugs since the reviewer need to fully understand each object lifetime, which is time consuming during code review.

I'm working on a company that run on a server application written in C/C++. The code base is very large and we always have memory bugs that required ASAN on production to fix the bugs. We have started migrating each part to Rust one year ago and we never have a single crash from Rust code. The reason we choose Rust is because it is a server application that computation intensive, latency sensitive and large amount of active connections.

Try keep using Rust until you comfortable with it and you will like it. It fit with your simple mental model. I can say this because I was a C++ users for the whole life and switched to Rust recently.

> if you proceed with care

Yes, but that is _incredibly_ time consuming. You have to set up asan, msan, tsan, and valgrind. If you want linting you need to do shenanigans to wire up clang-tidy.

I also like simple mental models. I like not having to figure out the cmake modifications to pull in a new library. I like having a search engine when I need a new library for x. I like when libraries return Result<Ok, Err> instead of ping ponging between C libraries which indicate errors using retval flags or C++ libraries that throw std::runtime_error(). I like not dealing with void* pointer casting .

I find Zig to be a saner Rust alternative, with the caveat that it is still a immature (but getting there).

Give it a few years and it will be a very strong contender.

The true C successor.

What complexity specifically does Rust add to that model?

Yeah loved the language and the IDE, but only boring Enterprise stuff built with it. Also C# got so complex, since it had to absorb every idea from F# rather than making F# a viable programming language on itself and improving interop...

At a given point after being a C# programmer for years I still encountered patterns that were completely unreadable to me.

I think it speaks to an incredibly pragmatic viewpoint though. When you take a look at your flagship language/ecosystem and you say, "hey, this is great for building entire systems for doctor/patient data... or perhaps even banking software"... but recognize that "it's probably not the best thing for building a compiler/tooling". Google themselves show the same pragmatism when NOT using Go for Android. They prefer Kotlin these days.

.NET isn't famous for producing portable binaries and I don't think it's being any better now other than some experimental modes that break most code.

https://news.ycombinator.com/item?id=43413702 is one example.

A Rustacean implied Go was not memory safe and that Microsoft couldn't understand the power of Rust. Steve Klabnik & others told them off. But other Rustaceans, like Patrick Walton, argued that Go has memory safety issues in theory.

https://github.com/microsoft/typescript-go/discussions/411

Some of the worst comments have been scrubbed but they might be in one of the internet archival sites.

I recall a thread on Twitter where someone called the TypeScript developers "brain dead *tards" for using Go over Rust.

> monomorphization bloat

Especially because the fix is so easy, it could just be fixed by the compiler on the fly.

If you have a function

  fn a(arg: Into<C>) {
    expensive/extensive operations here
  }

  a(&"test");
  a(10);

  fn a_str(arg: &str) {
  /// expensive/extensive operations
  }
  fn a_u16(arg: u16) {
  /// expensive/extensive operations
  }

  fn expensive_ops(arg: C) {
  // ...
  }

  fn a_str(arg: &str) {
    let _arg: C = arg.into();
    expensive_ops(_arg);
  }

> The main issue with Rust is that is has been oversold as a panacea for safety using exaggerated arguments.

I know you know this, but Rust does provide essentially complete memory and lifetime safety if you stay within the bounds of safe. Standard C/C++ tooling has no way to even reliably detect memory safety violations, let alone fix them. It's trivial to write buffer overflows that escape ASAN, and missing a single violation invalidates the semantic meaning of the entire program (particularly in C++), which means virtually all nontrivial programs in C/C++ have UB somewhere (a point we disagree on).

Safe rust doesn't guarantee all the other possible definitions of safety, but neither does any other mainstream language. I don't think it serves any useful purpose to complain that the rust folks have oversold their safety arguments by "only" eliminating the biggest cause of safety issues. Stroustrup harps on this a lot and it comes across as very disingenuous given the state of C++.

Yes. I was thinking of this:

> If you do an experiment and say "C++" anywhere on the Internet, in a minute someone will chime in and educate you about the existence of Rust.

> I know examples when engineers rewrite code from Rust in Rust if they like to rewrite everything in Rust.

> our engineers become too nauseous from Rust poisoning

> So now they [Rust devs] can write something other than new versions of old terminal applications.

> someone shows PRQL, everyone else thinks "What a wonderful idea, and, also, Rust" and gives this project a star on GitHub. This is, by the way, how most of Rust projects get their stars on GitHub. It doesn't look like someone wants to use this language, but what we want is to ride the hype.

> we started to understand that it would be hard to get rid of Rust, and we could tolerate it.

It's a very shitty attitude and not even accurate. You see this attitude from old C/C++ devs quite a lot, it's just very weird that he has that attitude and then also seems to be simultaneously quite keen to use Rust. Very weird!

Anyway those are just the non-technical things. On the technical side:

> Fully offline builds

They solved it by vendoring but this is the obvious solution and also applies to C++.

> Segfault in Rust

They tried to do a null-terminated read of a string that wasn't null-terminated. Nothing to do with Rust. That would be an error in C++ too. In fact this is a strong argument for Rust.

> Panic

C/C++ code aborts. Or more commonly it crashes in a very difficult to debug way. I'll take panics any day.

> Sanitizers require nightly

Ok fair enough but this seems relatively minor.

> Rust's OpenSSL links with the system library by default and you have to set an environment variable to statically link it.

They set the environment variable. Frankly this is a million times easier than doing the same thing in C++.

I'll stop there, but overall it seems like a lot of "this is a problem we had with Rust" where it should really be more like "this is something we had to do when using C++ with Rust".

Weird vibe anyway.

They link to actual issues in their bug tracker, so if it was a joke, it was an impressive long con.

> there could be other issues, like mutex poisoning, which is why nobody uses the stdlib's mutexes.

What does everyone use instead?

Rust can be optionally compiled in a panic=abort mode, but by default panics are recoverable. From implementation perspective Rust panics are almost identical to C++ exceptions.

For servers that must not suddenly die, it's wise to use panic=unwind and catch_unwind at task/request boundaries (https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.h...)

In very early pre-1.0 prototypes Rust was meant to have isolated tasks that are killed on panic. As Rust became more low-level, it turned into terminating a whole OS thread on panic, and since Rust 1.9.0, it's basically just a try/catch with usage guidelines.

But no few would write a process-per-request web server today for example. And if a single process web server handles 100 requests you would then accept that one bad request one tore down the handling of the 99 others. Even if you have a watchdog that restarts the service after the one request choked, you wouldn't save the 99 requests that were in-flight on the same process. Can't you catch_unwind for each request handler, if one chokes then you just ignore that request. If you worry about that messing anything up, then you can tear down and restart your process after that, so the 99 other requests get a chance to complete?

This is factually incorrect. The behavior you describe with Elixir (sic) is precisely what most Rust async runtimes do. (sic because it's Erlang that's to thank)

IMHO that is the sensible thing to do for pretty much any green thread or highly concurrent application. e.g. Golang does the same: panicking will only bring down the goroutine and not the whole process.