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

Using Rust at a startup: A cautionary tale

scribe.rip

Post reply on HN
Print view View original

61–70 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#61

Post by mjr00 »

cardanome wrote: post #8

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

I worked at a company where a principal developer got tasked with building a CRUD app. He worked in a silo on it, coming back in 3 months with a CRUD app... written in Scala with heavy use of scalaz. It was a CRUD app that was scalaz features to defer the entire execution until runtime. Nobody could understand the code at all. The team ended up replacing the entire functionality in less than a week using Python+Flask.

My conclusion from stories like this and the one in TFA - engineering management is important and hard, especially when you're dealing with smart engineers. You need someone who is technical enough to understand Rust/Scala vs Python, but also has the business sense to know that as cool as it might be, writing a CRUD app in Rust is not moving your business forward.

Re: Using Rust at a startup: A cautionary tale

#62

Post by masklinn »

lolinder wrote: post #54
masklinn wrote: post #40

Earlier quoted context omitted.

Not only that, but the borrow checker also handles safety concerns. Rust's concurrency safety story ("fearless concurrency") is literally built on the back of ownership and borrowing.

Oh, wow, yes. I confess I skimmed the part about green threads. I think OP doesn't understand that runtime features like GC and green threads have a cost, and Rust is designed around a making it safe to avoid that cost. Most of Rust's features don't make sense in the context of a managed runtime—what you would be left with is basically a subset of OCaml with C-style syntax and optional mutability.

> Most of Rust's features don't make sense in the context of a managed runtime

I don’t think that’s entirely true actually (which is why linearity is explored in languages like haskell).

For instance Go makes it easier to trigger data races, which undermine memory safety. This is a managed langage “built for concurrency” where using concurrency means memory safety is at risk.

And that’s not recent news, Russ Cox himself wrote about it back in 2010: https://research.swtch.com/gorace

Re: Using Rust at a startup: A cautionary tale

#63

Post by filleokus »

cardanome wrote: post #8

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

I'm only a Rust noob, and have importantly only used it for my own hobby projects. But can't you get a lot of the ergonomics from memory managed languages by using "managed" container structures like ARC and being slightly sloppy with your allocations?

For my hobby projects it hasen't felt more cumbersome than e.g C#.

Re: Using Rust at a startup: A cautionary tale

#64

Post by avinassh »

Using Rust for CRUD stuff is not a good idea. I would pick Go or Elixir may be.

If you are starting a new project, ask yourself:

1. Would I be writing this in C++? Then Rust is a great alternative.

2. Would I be using C? Then may be Rust or Zig would make a good alternatives

3. Would I be writing it in Ruby or Python? Then Go or Elixir can be considered

Re: Using Rust at a startup: A cautionary tale

#65

Post by masklinn »

zozbot234 wrote: post #58
lolinder wrote: post #54

Earlier quoted context omitted.

Oh, wow, yes. I confess I skimmed the part about green threads. I think OP doesn't understand that runtime features like GC and green threads have a cost, and Rust is designed around a making it safe to avoid that cost. Most of Rust's features don't make sense in the context of a managed runtime—what you would be left with is basically a subset of OCaml with C-style syntax and optional mutability.

Green threads have been totally superseded by current async support in Rust. That's why they're no longer part of the language itself.

Technically green threads were removed when rust was moved “down the stack” back before 1.0: green threads would mean requiring a runtime (scheduler & al) which is problematic when targeting foundational libraries and embedded programming, it makes integrating with other systems a lot harder.

Async being opt-in means the people who don’t need it can avoid it, though it’s not always great when e.g. the premier HTTP client of the ecosystem provides a “blocking” interface which iirc just starts a runtime and delegates to the async interface.

Re: Using Rust at a startup: A cautionary tale

#66

Post by brap »

jpgvm wrote: post #29

Startups spend innovation tokens very poorly. Progamming languages, hosting platforms and non-standard databases aren't ideal places to spend such tokens. For most apps what you want is JVM or .NET, PostgreSQL or MySQL or SQL Server, k8s or vanilla VMs/containers. You almost never want different programming languages to these mature stacks, you might think you do, but you don't. Node.js/Python/Ruby etc all promise a…

> k8s or vanilla VMs/containers.

Why would you even bother as an early stage startup? Ship your code on a PaaS like fly.io/Render/Vercel/Heroku/etc until cost/scale is an actual issue. Same for using managed DB solutions. Your time (=money) would be much better spent elsewhere.

As for language, I would optimize for what's easy to hire for.

Re: Using Rust at a startup: A cautionary tale

#68

Post by zozbot234 »

loeg wrote: post #60
zozbot234 wrote: post #50

Earlier quoted context omitted.

Any senior developer with C/C++ experience will probably be pretty comfortable with Rust and its ecosystem. It's not an overly complicated language.

I was very familiar with C before starting to do professional work in Rust, and ran into a similar trap as the grandparent comment describes. Since then I've gained professional experience in C++ as well. Without specific Rust experience, I wholly disagree that "any senior developer with C/C++ experience" will have a good sense of optimal Rust project architecture out of the gate. A reasonably good starting point, su…

> ran into a similar trap as the grandparent comment describes.

The only "trap" I've seen referenced wrt. Rust is the concern that coding for agility and flexibility introduces boilerplate. Such as GP's concern about calling .clone() too much instead of worrying about lifetimes. But every language has its unidiomatic parts; it's a benefit of Rust that they chose to make the most thoroughly refactored style look "clean and natural", and the most open to refactoring "hackish and unidiomatic" rather than the reverse (cough, cough Java cough, cough). Describing that as a pitfall is just not very helpful!

Re: Using Rust at a startup: A cautionary tale

#69

Post by wyldfire »

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages ... Some of those “new” ideas are, of course, present in other languages — especially functional ones.

With C++, lifetime and ownership are just about as important but unfortunately no one's got your back. You can ignore lifetimes and ownership but you do so at your own peril. And the compiler won't tell you you're doing it wrong because the language wasn't designed for it to do so.

If you want a taste of rust's "mindset" (with respect to limitations imposed by some types) without jumping ship to a new language, try C++'s Guidelines Support Library [1]. It introduces some of the same benefits/friction as switching to rust but without a new language. Opting-in to some of these guidelines might be a gentler way to get some of the benefits of Rust. But it comes with a similarly higher bar.

[1] https://github.com/microsoft/GSL

Re: Using Rust at a startup: A cautionary tale

#70

Post by boredumb »

cardanome wrote: post #8

Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…

Rust is perfectly fine to write CRUD apps and the productivity between it and golang is identical. The only issue I would have with growing a rust app in 2022 is the pool of talent to hire from for it. I find the comments about using rust for different projects generally align with what people were saying 10 years ago about golang and with the rise of people being comfortable in golang it's now used in a massive array of projects beyond what outsiders were trying to peg the language to.

tl;dr rust is great for writing all kinds of apps and as the labor pool with rust grows so will it's usage in all aspects of computing.

Post reply on HN