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

111–120 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#111

Post by satvikpendem »

p4ul wrote: post #107
satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

Agreed! And personally, I've found that "Zero To Production Rust" is absolutely phenomenal! I feel like it's the equivalent of "The Book" for using Rust on back-end apps!

I was surprised at just how detailed it was. I thought it would be like those NodeJS tutorials like "build a full-fledged backend API in 5 hours" but no, it covers everything you might think of for production, so its title is very accurate. It also teaches you system design along the way, which is quite a notable benefit over many other types of tutorials.

Re: Using Rust at a startup: A cautionary tale

#112

Post by kolbe »

dlivingston wrote: post #56
kolbe wrote: post #35

I'm in the middle of a rewrite of my finance analytics library in Rust. I chose it for all the compelling reasons: speed, safety and a great package manager. About 2 weeks in, I hit a blocker, where the most performance critical layer was running 30x slower than C#. It's two weeks since then, and I'm still blocked. Experienced programmers on the language Discord and Reddit have been stumped as well, and I get the imp…

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 array of doubles that spits out another array of doubles, so I parallelize it with SIMD and threads. In C# I max out at AVX-2 for instruction level parallelism, but for Rust, 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.

Re: Using Rust at a startup: A cautionary tale

#113

Post by willgleich »

bacon_waffle wrote: post #98
TylerE wrote: post #23

Earlier quoted context omitted.

“Software doesn’t exist yet” is a huge user cost

Could you expand on this? It doesn't really make sense to me, but I'm also a Rust fan. The premise that Rust prioritizes safety (or performance) over developer productivity also doesn't resonate. As a consumer, I tend to prefer the thing that is available a bit later (or more expensive) and works well, versus the one that is available sooner (or cheaper) and is less reliable. Maybe that preference is a result of year…

I believe the point TylerE is trying to make is that features that take longer to deliver are a cost to the user. If a user is waiting on a feature, or perhaps a bug fix and that is taking 4x the time to deliver - the cost is right there on the user's clock waiting.

Many people would argue you with you that the "easier" programming languages are no less reliable, context depending. Framing this in the context of the article a CRUD app, there are plenty of reliable frameworks in many languages.

Re: Using Rust at a startup: A cautionary tale

#114

Post by jcmontx »

andrewmutz wrote: post #31

> This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.

The big three of productivity: Django, Laravel & Rails.

Second tier, a bit higher performance, yet somewhat less productive: ASP.NET Core; Spring Boot; Node/Express/Nest; maybe Go

Re: Using Rust at a startup: A cautionary tale

#115

Post by jcmontx »

williamcotton wrote: post #34

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

I don't get the downvotes. What you say makes sense to me. A web-first programming language. Wasn't that the origin of PHP?

Re: Using Rust at a startup: A cautionary tale

#116

Post by ekidd »

nequo wrote: post #110
ekidd wrote: post #55

I use Rust at a startup, and it's been great. But I've used Rust mostly for performance-critical CLI tools, or highly specialized servers. Typically, these have a narrowly defined job that must be done reliably and efficiently. Rust shines at this. These tools run reliably with almost no changes, often for years at a time. But I have learned that it's often less useful putting policy and frequently-changed business l…

> That kind of code is often accessible to more developers in a strongly-typed scripting language. I assume that you’re thinking of TypeScript or Python with type hints. Do you mean that these languages are more accessible because they are more widely known by developers or because codebases in these languages are easier for some reason to change frequently than codebases in Rust?

Mostly because TypeScript and typed Python are often more accessible to more developers.

One of the tradeoffs of programming in Rust is that you need to distinguish between value vs. reference, stack vs. heap, and a number of other choices like that. This helps performance tremendously. But unless most of your team is comfortable making these decisions, they add a modest tax to all Rust code written. At least compared to TypeScript.

Rust is a fantastically productive language now that I know it well. There's definitely a point on the learning curve where Rust can be competitive with several popular scripting languages. But getting an entire team of programmers to that point takes a concerted effort.

So for many teams, Rust is the biggest win for problems like:

- "I need a server that handles a few kinds of specialized requests at high speed."

- "I need a CLI tool that can process 60 GB of input data on a regular basis."

- "I need to parse this file format that involves 197 special cases that I must keep carefully straight."

Re: Using Rust at a startup: A cautionary tale

#117

Post by jcmontx »

brundolf wrote: post #22
bsder wrote: post #8

I really, really, really, don't understand why people want to use Rust for CRUD/web stuff. Every GC language is better than Rust for CRUD/web when you are in the less than 10,000 users phase. I understand why Rust is trying to shove its way into the CRUD/web space--that's where all the programming is. I just don't understand the converse.

I cast glances at it every time my company's Python services break because of a runtime error that could have been caught with a better type system, or because they ran out of memory and need bigger boxes, or another developer has to spend a week debugging their environment to get the complex web of dependencies aligned for five minutes, or my laptop strains under the weight of a dozen docker containers attempting to…

Go, C#, Java, any of those have the benefits you mention (some, at least) without sacrificing that much early productivity

Re: Using Rust at a startup: A cautionary tale

#118

Post by Throwaway23459 »

> What really bites is when you need to change the type signature of a load-bearing > interface and find yourself spending hours changing every place where the type is > used only to see if your initial stab at something is feasible

Editor/IDE should be able to do this in a few seconds.

Re: Using Rust at a startup: A cautionary tale

#119

Post by ajross »

kelnos wrote: post #27

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. This is really the main reason not to use Rust when you need to move fast: if you don't know the language yet, it will take you time to learn it. But that's true of any language. You probably shouldn't do your startup in Java, either, if your team isn't familiar with it. Yes, Rust's learning curve is…

> You probably shouldn't do your startup in Java, either, if your team isn't familiar with it.

Java is wildly easier to pick up than Rust, though. Hordes of productive enterprise java programmers are employed today who frankly don't even understand what memory safety even means, much less the tradeoffs their language runtime (or software) needs to make to ensure it.

It's certainly a truism that you should tailor your development environment to the talents of your staff, but that doesn't mean that all tools are equally applicable. Would you do a startup today using APL or COBOL?

Post reply on HN