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

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

221–230 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#221

Post by RamblingCTO »

bessiesboobies wrote: post #140
brundolf wrote: post #132

Earlier quoted context omitted.

Biggest one is lack of null-safety. The preference for implicit value defaults, sketchy error-handling, and similar choices also rub me the wrong way. The whole thing just feels too fast-and-loose for my tastes I'm the thousandth person to suggest this, but my ideal language for web servers and lots of other things would be Rust with a GC instead of a borrow-checker. But Rust has its unique killer-feature to thank fo…

Kotlin and Scala exist

Kotlin still has the annoying points of any jvm lang. Gradle, weird ORM stuff etc.

Re: Using Rust at a startup: A cautionary tale

#222

Post by zozbot234 »

SevenNation wrote: post #2

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. Those three things are actually just different facets of the same thing: ownership. The bad news is that you must learn Rust's ownership model to use Rust idiomatically. The good news is that you can do a lot without learning Rust ownership model at all. Just clone all your values. Not advisable for…

> Not advisable for production code

If your alternative is Python or Ruby, then cloning your values is perfectly OK for production code. It will still run very fast.

Re: Using Rust at a startup: A cautionary tale

#223

Post by zozbot234 »

kolbe wrote: post #112
dlivingston wrote: post #56

Earlier quoted context omitted.

Just out of curiosity, why is your perf-critical layer running so slowly? Are you any closer to cracking it?

I can only give you some guesses, but I think there's some false sharing type of bug going on. There's also an issue with the fact that LLVM hasn't released a target for my CPU yet (I use a Zen 4), and who knows what bugs are caused by targeting the wrong CPU. In a single threaded version, it beats C#, though not by as much as I would have expected. The essence is that I have to run the same calculation on a large ar…

> I use AVX-512, and it's not even 2x faster, though it is faster--it should be more than 2x faster because AVX-512 has better instructions to work with. But when I combine this with doing the calculation in threaded parallel chunks on the array, it goes far slower than it should.

You might be saturating your memory bandwidth to the point where it just can't go any faster. Since it seems your problem is easy to parallelize, you might want to experiment with the rust-gpu ecosystem.

Re: Using Rust at a startup: A cautionary tale

#224

Post by WiSaGaN »

logicchains wrote: post #165
WiSaGaN wrote: post #92

Earlier quoted context omitted.

This really depends on your problem domain. Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more. This also hasn't counted the reduced debug time later, which would be a significant time spent by devs in C++. In areas that don't value performance and correctness,…

>Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more Are you actually a C++ programmer? I work at a firm that uses C++ and Rust and this isn't the case at all. Setting up dependencies, tests and benchmarks is a one-off cost, most C++ compiler errors are quite und…

I was for several years. We were using git submodules to handle dependencies, but still using third party packages involves copy paste a lot. `std::variant` was the one we use to mimic the rust `enum` but it is much cumbersome to use, and not safe at all, there was no compiler checked `match`. Sure, single threaded code is much better, but this won't help with buffer overrun, or use after free like `String("hello").c_str()`, or iterator invalidation when you loop and delete, you just gradually learn all those gotchas along the way while bearing the learning cost. Trust me, experienced devs appreciate Rust much more if they are actually good at writing memory safe code.

Re: Using Rust at a startup: A cautionary tale

#225

Post by zozbot234 »

logicchains wrote: post #165
WiSaGaN wrote: post #92

Earlier quoted context omitted.

This really depends on your problem domain. Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more. This also hasn't counted the reduced debug time later, which would be a significant time spent by devs in C++. In areas that don't value performance and correctness,…

>Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more Are you actually a C++ programmer? I work at a firm that uses C++ and Rust and this isn't the case at all. Setting up dependencies, tests and benchmarks is a one-off cost, most C++ compiler errors are quite und…

> variadic templates, something Rust doesn't support

Well, Rust uses macros for that which are equivalent to C++ templates. Ever used println!() ?

Re: Using Rust at a startup: A cautionary tale

#226

Post by zozbot234 »

almost_usual wrote: post #150
errantmind wrote: post #122

While I respect the author's anecdote, this doesn't match my experience. I've been programming for 20+ years across a wide array of languages and I'm by far the most productive in Rust. With a competent teacher, experienced devs should be able to pick up on the memory model pretty quickly, and that is really the only initial blocker to productivity. After that a dev can essentially write procedural code if they want,…

I agree mostly with this, however, ownership can be strange in Rust if you’re not familiar with it. Something simple like a linked list can be challenging to implement. https://rust-unofficial.github.io/too-many-lists/

> Something simple like a linked list can be challenging to implement.

Well, that's because linked lists are not simple. The linked blogpost makes that clear enough.

Re: Using Rust at a startup: A cautionary tale

#227

Post by zozbot234 »

optymizer wrote: post #167
pclmulqdq wrote: post #68

Earlier quoted context omitted.

In my experience, Python is one of the least productive programming languages for projects with more than 3 people. If you have a big project, you are going to spend a lot more time reading code than writing it. Python is write-optimized. By contrast, using Rust makes it easy to force a readable coding style on yourself and others.

Python is not readable to you? The beginner friendly, whitespace-enforcing, almost-like-pseudocode-in-English language - that Python? - is not readable enough, but Rust, where you liberally sprinkle ', {}, !, &, :: or #[] everywhere _is_ readable to you? You must be trolling. You know what Rust looks like to me? Perl without the dollar signs. There's your write-only language, you just have it backwards.

Surface syntax is the most subjective aspect of a programming language, but Rust uses just a few symbols in a very consistent way. It's nothing like Perl. The indentation rule is nice for small examples, but it tends to break down in cases that are even slightly complex. Which is why, e.g. Haskell can use semicolons and curly braces as an alternative.

Re: Using Rust at a startup: A cautionary tale

#228

Post by xiphias2 »

,,Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well.''

This sounds just like all other projects that don't keep the code professional.

The author complains a lot about the quality of the Rust libraries and documentation, but I bet that their code base and documentation and especially testing is worse.

Still, I agree that Rust is not ready for a startup where the requirements change often.

Re: Using Rust at a startup: A cautionary tale

#229

Post by neonsunset »

As usual, very sad to see how little C# is mentioned as an alternative, having very robust, easy to use and performant stack of standard and third-party libraries for building the exact scenario outlined in the article.

Especially that is has first-class support for gRPC, runs on every cloud/on-prem host you can think of and doesn't force you to go out of your way to get most performance out of your implementation. People should not be mentioning Java first as a GC/JIT-based language for cloud given how competitive C# stack is and how much more you get straight out of the box.

Re: Using Rust at a startup: A cautionary tale

#230

Post by kjeetgill »

neonsunset wrote: post #229

As usual, very sad to see how little C# is mentioned as an alternative, having very robust, easy to use and performant stack of standard and third-party libraries for building the exact scenario outlined in the article. Especially that is has first-class support for gRPC, runs on every cloud/on-prem host you can think of and doesn't force you to go out of your way to get most performance out of your implementation. P…

Java just has an incredibly long, deep, relationship with the open source/FOSS world that is going to take C# a lot of time to catch up with. Java's also consistently had a much better story with backwards/forwards compatibility and versioning.

I haven't used it in years, but I didn't find the anywhere near as full an ecosystem around C#, it's tooling, it's libraries, etc. It didn't help that there was a lot of confusion around what ran on which runtimes/versions.

Perhaps it's changed since then.

Post reply on HN