Live data from Hacker News

A year of Rust in ClickHouse

clickhouse.com

91–100 of 102 posts

Re: A year of Rust in ClickHouse

#91
post #7
post #4

This guy seems to be both very positive about Rust and unfairly cynical about it at the same time... Rust is a really fantastic language but having worked on a mixed C++/Rust codebase I can see why they had so many issues. Rust just wasn't really designed with C++ interop in mind so it's kind of painful to use them together. Impressive that they made it work.

"unfairly"? A lot of issues are obvious deficiencies of Rust, including immaturity of the ecosystem, integration issues, complexity, monomorphization bloat, supply chain issues. Now, all languages have issues, and Rust is certainly a nice language overall. The main issue with Rust is that is has been oversold as a panacea for safety using exaggerated arguments. So a bit of cynicism seems entirely fair.

> 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) {
    expensive/extensive operations here
  }

and call it two times

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

The compiler will generate two functions

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

This can be fixed by just proxying the duplicated call like this

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

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

Re: A year of Rust in ClickHouse

#92
post #75

Earlier quoted context omitted.

You can install a global panic handler to avoid bringing the whole process down. Instead of aborting, take the stack trace, print it, perhaps raise to sentry, and kill the specific "work unit" that caused it. This "work unit" can be a thread of a task, depending on how the application is architected. This is precisely what Tokio does: by default, a panic in async code will only bring down the task that panicked inste…

> there could be other issues, like mutex poisoning, which is why nobody uses the stdlib's mutexes. What does everyone use instead?

parking_lot

Re: A year of Rust in ClickHouse

#93

Earlier quoted context omitted.

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://dictionary.cambridge.org/dictionary/english/abuse Rustacean, Gopher... this is an embarrassing way of looking at it. And, speaking of, Go is not a memory safe language when you reach for its concurrency primitives as it very easily lets you violate memory safety (as opposed to Rust, .NET and JVM, where instead you get logic bugs but not memory safety ones).

[deleted]

Re: A year of Rust in ClickHouse

#94

Earlier quoted context omitted.

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://dictionary.cambridge.org/dictionary/english/abuse Rustacean, Gopher... this is an embarrassing way of looking at it. And, speaking of, Go is not a memory safe language when you reach for its concurrency primitives as it very easily lets you violate memory safety (as opposed to Rust, .NET and JVM, where instead you get logic bugs but not memory safety ones).

[deleted]

Re: A year of Rust in ClickHouse

#95

Earlier quoted context omitted.

Zig is fantastic, however there are a few issues (mostly related to its immature/wip status): - the build system is constantly changing in a breaking way (between releases some of the repos I have on GH no longer build and need their build.zig to be updated). - the comptime section of the docs needs to be heavily expanded, I'd love to see them take common Go interfaces and redo them in Zig (like io.Writer, io.Reader)…

>Also, higher-level concurrency primitives like channels would be fantastic. That can be done trough a library.

Agreed! There is actually a nice C library (libdill: https://libdill.org).

Would still like it as a first-class language construct.

Re: A year of Rust in ClickHouse

#96
post #85

Earlier quoted context omitted.

When I say "Rust alternative" it's precisely because it competes in the same space: very low-level, no GC, extremely high performance constraints, safety guarantees. Re: safety guarantees, much digital ink has been spilled on how Zig can give Rust a run for its money when it comes to safety. When people say: Rust C++, Zig C; they forget that C++ was precisely meant to be an enhanced C, which is what Zig is trying to…

It has the same safety guarantees than Modula-2 and Object Pascal have been offering for decades, but apparently curly brackets and @ everywhere is better than begin/end.

Curly braces have taken over the world (let's ignore Python for now...).

Re: A year of Rust in ClickHouse

#97

Earlier quoted context omitted.

> 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 ru…

> 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. Nah, if you're trying to match every "new" with a "delete" during the code review…

I was pretty hyped on C++ during the (early?) 2010s, hoping that eventually I get to work on project that has really serious number crunching needs, and ... and then ... the big guns. Now reading this feels like the best argument for Rust/Scala. :)

Re: A year of Rust in ClickHouse

#100

One thing I often see pop up in larger projects, which in the article is likely the fault of way to large symbols, is overuse of generics/type state/etc. Or you could formulate this as needless obsession with not using `dyn`. And sure generics are more powerful, dyn has limitations, etc. etc. It's one of this "Misconceptions Programmers believe about Monomorphisation vs. Virtual Calls" things as in: TL;DR: dyn isn't…

My understanding of why Rust does monomorphization by default is that it wanted maximum performance, since it was meant to replace C++. Excellent post!
Post reply on HN