Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of Rust in ClickHouse

clickhouse.com

Post reply on HN
Print view View original

81–90 of 102 posts

Re: A year of Rust in ClickHouse

#81

Post by dep_b »

neonsunset wrote: post #46
dep_b wrote: post #26

Earlier quoted context omitted.

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.

Do you have a specific snippet in mind which demonstrates the issue? It is likely more of a team or a community issue when it comes to writing unreadable code than a language one since it tends to happen in every sufficiently powerful language. C# did not “have to absorb every idea from F#”. This is not how programming language development works. You can read LDM notes at https://github.com/dotnet/csharplang/discussi…

I've quit working on .net solutions a few years ago, but I've built a feature in F# about 7 year ago. While the language was wonderful, the IDE support was very minimal. Documentation and examples were really hard to find. So I don't feel it's really pushed as an alternative.

C#: A lot of LINQ style code was really hard to grok for me. Like a language in a language. The language got really huge in general. While it was fine as a "better Java" for most purposes.

Re: A year of Rust in ClickHouse

#82

Post by arnsholt »

eptcyka wrote: post #71
arnsholt wrote: post #63

Earlier quoted context omitted.

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…

How does single ownership conflict with the idea that memory is a flat array of bytes? Further, the borrow checker does not care about pointers, only references. With pointers, you are on your own. It is true that using pointers in Rust is more cumbersome than it could be. But it is much easier to compartmentalise the pointer parts into separate functions and expose references instead. I agree that some paradigms and…

Single ownership and memory not being flat are separate points.

And I guess I'm imprecise saying pointers where I mean borrowed values, but my point is that a borrow is just a pointer with additional type checking. More formally: C pointers are a complete but unsound formal system, whereas Rust borrows are sound but incomplete. And every time I get in a fight with the borrow checker, it's because I'm doing something unsound, not because the system is incomplete.

Re: A year of Rust in ClickHouse

#83

Post by [deleted] »

neonsunset wrote: post #68
hitekker wrote: post #56

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

#84

Post by kobebrookskC3 »

arnsholt wrote: post #63
eptcyka wrote: post #32

Earlier quoted context omitted.

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…

even in c, you can't assume memory is a flat array of bytes. pointers have provenance, and compilers exploit this: https://godbolt.org/z/ondGh4Ynn

Re: A year of Rust in ClickHouse

#85

Post by pjmlp »

angra_mainyu wrote: post #61
DeathArrow wrote: post #58

Earlier quoted context omitted.

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…

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.

Re: A year of Rust in ClickHouse

#86

Post by pjmlp »

nobleach wrote: post #57
pjmlp wrote: post #8

Earlier quoted context omitted.

The actual issue wasn't Go over Rust, rather having key people responsible for C# design, on a Microsoft project, going for a Google language. While at the same time, the .NET team routinely talks about .NET image problem outside traditional Microsoft shops, which naturally decisions like this aren't helping a tiny bit.

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

Complete different reasoning, choosing Go instead of Kotlin would mean rewrite from scratch 100% of Android userspace, minus the C++ libraries for Treble drivers, graphics and ART toolchain.

And Google did do exactly that with Fucshia, which doesn't seem to be going to power anything beyond Nest screens.

Re: A year of Rust in ClickHouse

#87

Post by AlotOfReading »

blub wrote: post #30
AlotOfReading wrote: post #24

Earlier quoted context omitted.

We have very different priorities. Because I work on safety critical systems, language semantics are very important in order to enable things like formal executable semantics and certified compilers. When I sign my name to an inspection, the inspection is relative to the language semantics. Things like exploitability and even performance are pretty far down the list of concerns, unless they happen to impact functiona…

So you’re using formal methods, sanitizers, the whole gamut of verification and yet you can “quickly” find new issues just by fuzzing. Sounds like there’s some significant problem there that you’re not mentioning. Microsoft and Google have a ton of legacy code, they need to have high performance because they’re pushing everything to the web in order to spy better on people, they always churn their software and they a…

The "significant problem" is the same that every other organization faces: the testing and validation isn't quite as good as it could be and I know where to poke.

Re: A year of Rust in ClickHouse

#88

Post by selfmodruntime »

simonask wrote: post #29
pjmlp wrote: post #6

I love that it goes both ways, about plus and minus of both languages, including rewriting back into C++ when it made sense, and the side joke about rewriting existing CLI tools in Rust. While C++ isn't perfect, has the warts of a 50 year's old language, and probably will never match Rust's safety, we would already be in a much better place if at least everyone used the tools at their disposal from the last 30 years.…

Coming from C++, my favorite take on Rust is that it is fundamentally about productivity. Avoiding UB is a serious drain on productivity in C++, and every new language or library feature comes with additional pitfalls, increasing the mental load. This is to say: The benefit of Rust is not actually about "security critical scenarios", but much more generally about delivering the same quality of code in a fraction of t…

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.

Re: A year of Rust in ClickHouse

#89

Post by selfmodruntime »

ultimaweapon wrote: post #38
DeathArrow wrote: post #31

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…

> 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 code base is very large and we always have memory bugs that required ASAN on production to fix the bugs

This is a big part of why Rust works. We also never have errors that we can't reproduce in development.

Re: A year of Rust in ClickHouse

#90

Post by noitpmeder »

pjmlp wrote: post #43
simonask wrote: post #27

Earlier quoted context omitted.

You seem to consider convenient dependency management a security hazard, which I have always found to be a pretty weird take. It logically follows that the severe difficulty of managing dependencies in C and C++ projects is actually a security feature , or how else are we supposed to understand this opinion? Let's not pretend that anything is better on the traditional C/C++ side, where the approach is usually one or…

Regardless of the programming language it is a security hazard, that is why we have now SBOM in the industry, and many corporations have procedures in place before adding that cool dependency into the project. Regardless it is cargo, vcpkg/conan, nuget, maven, npm,.... It isn't validated by legal and IT for upload into internal repos, doesn't get used.

Those same practices can be applied here where it matters.
Post reply on HN