Live data from Hacker News

A year of Rust in ClickHouse

clickhouse.com

61–70 of 102 posts

Re: A year of Rust in ClickHouse

#61

Earlier quoted context omitted.

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.

I like Zig, too. Not sure if it's a Rust alternative as in you still have to manage the memory yourself. But is much simpler, easier to read, easier to understand, easier to follow and easier to reason about. It's less verbose and more productive. It feels like what C would look like had it been invented today.

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 accomplish. They simply eschewed chasing complexity as the holiest of holy grails, which in turn leads to the cognitive load of writing/reading Zig code to be MUCH smaller than C++ or other langs in that space.

All that said, I'd never recommend a company build their product on Zig just yet, at least not with some kind of red telephone to the Zig team or a dedicated Zig developer, given it's still not fully mature.

Re: managing memory yourself, Zig's defer makes this much, much more straightforward than you would think, and feeding in your own allocators can simplify this in many cases (and make testing for leaks much easier).

Re: A year of Rust in ClickHouse

#62
> As a downside, Rust libraries typically have a large fan-out of dependencies, much like Node.js. This requires taking care to avoid the blow-up of dependencies, and to deal with annoyances of dependabot.

In the linked situation, the were using the library of a binary. This get into the tension between "make it easy for `cargo install` (and have a `cli` feature be default) and "make it easy for `cargo add` (and make `cli` opt-in).

This is not a great experience and we should improve it. There was an RFC to auto-enable features when a build-target is built (allowing `cli` to be opt-in but `cargo install` to auto-opt-in), rather than skip it, but the dev experience needed work, The maintainer can split the package which helps with semver for the two sides but needs to break one side to do so and if its the bin, people need to discover the suffix (`-bin`, `-cli`, etc).

Current workarounds:

- `cargo add skim` will show the `cli` feature is enabled and you can re-run with `--no-default-features`

- if `cli` wasn't a default, `cargo install skim` would suggest adding `--features cli`

Re: A year of Rust in ClickHouse

#63
post #32

Earlier quoted context omitted.

C++ can be safe enough if you proceed with care. What I dislike of C++ is that it grew to become a monster of a language, containing all programming paradigms and ideas, good or bad, known to mankind. It's so monstrously huge no human can hold its entire complexity in his head. C++ allows you to do things in 10000 different ways and developer would do just that. Often in the same code base. That being said, I would u…

What complexity specifically does Rust add to that model?

I can think of three things off the top of my head:

- Rust doesn’t let you pretend that memory is a flat array of bytes - Single ownership of data can be annoying in some cases - The borrow checker pointing out that you’re trying to do something stupid with pointers (again) can be annoying

Of course, I’m of the opinion that the hassles are worth it, especially the borrow checker. Almost every time I have to fight the borrow checker, it’s because I haven’t thought properly about the pointers involved and tried to do something stupid.

Re: A year of Rust in ClickHouse

#65
post #55

Earlier quoted context omitted.

> .....and you got triggered. Sure, you got me. If someone says the earth is actually a cube, I have to go defend the spherical chads. In this case, it's the sheer disconnect between RIIR askers, and the sheer number of people painting Rust devs with a continent wide brush. It's very in-group vs out-group reasoning. Let's demonstrate it. For example: I'm a Java dev, and I see a Java dev, being a moron, so I'll say "W…

>In this case, it's the sheer disconnect between RIIR askers, and the sheer number of people painting Rust devs with a continent wide brush. I have no idea how you can accuse me of this when I made a big disclaimer in my original comment: >Before anyone gets triggered and starts typing up a reply: "SUBSET" is the word I used.

> "SUBSET" is the word I used.

So? There is a subset of X lang (both bigger and smaller than Rust), complaining why not rewrite in X.

But only Rust devs ever get the flak. Because it's a played out meme, or something. Or it triggers the Rust dev, whatever.

Re: A year of Rust in ClickHouse

#66
post #28

Earlier quoted context omitted.

Which claims do you think are exaggerated?

The rust language is not well-specified, and if you take rust as the language specified by the compiler, then it has many soundness bugs. So even if you stay within "safe rust", you can segfault. The "memory safety" of rust is oversold since "safety" is not formally proven for the rust language. While anecdotally memory-related bugs seem less likely, rust without unsafe is not absolutely safe.

iirc the formal correctness of Rusts memory model was proven by Ralf Jung https://research.ralfj.de/thesis.html

Re: A year of Rust in ClickHouse

#67
post #45

Earlier quoted context omitted.

So is any big enough community. Look at that "Why Go?" discussions, and you'll see a lot more loud, obnoxious C# devs, but somehow Rust is the worst. There was also a Rewrite it in LISP post[1] fan. Where is the "The Lisp community is unfortunately plagued by this subset of devs who are zealous (and downright toxic) in their shilling for their favorite language." [1] https://github.com/microsoft/typescript-go/discuss…

.....and you got triggered. Somehow in the past 3-4 years it's only been that subset of Rust devs that have been wailing about: "WHY NOT REWRITE IT IN RUST?". Often they're mostly the same type: anime pfp, walls of text of pompous technobabble as if they were some elite caste of arcane cyberpriests preaching the gospel of Rust, etc. There's a reason "just rewrite it in Rust" has become such a meme.

> caste of arcane cyberpriests preaching the gospel of

Hey, that's a productive attitude when attempting to fix CI!

(or figuring out why smaller compiler output performs worse)

Re: A year of Rust in ClickHouse

#68

Earlier quoted context omitted.

> no one should be abused for choosing a language Can you link to the abuse?

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).

Re: A year of Rust in ClickHouse

#69
Re: panics: If you have a single long lived process that must do multiple short-lived things (web requests, say) and a panic in one of them MUST NOT take down the whole process, is that extremely difficult to pull off in Rust? I thought you could set up panic boundaries much like you would use catch-all exception handlers around e.g. each web request or similar, in other languages?

Re: A year of Rust in ClickHouse

#70
post #54

Earlier quoted context omitted.

Yeah, I’m leaning towards zig but I’m a bit on the fence still. For Rust, I kind of got tired of writing unsafe rust for embedded, but that’s addressable afaik. The real dealbreaker was that after 10k+ lines of code I still will pop open the source of a library that solves a simple problem and the code looks indecipherable. I also don’t really agree with the dependency explosion that cargo encourages. Zig is very nic…

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.

Post reply on HN