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

31–40 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#31

Post by echelon »

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 don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects).

We're having a great time with Actix + sqlx. It feels like Go, but with less typing (physical).

With an IDE like Clion + Rust Plugin, the code writes itself. It feels like writing Java or Golang.

Every time someone says "oh no, borrow checker" for *single thread scoped CRUD apps*, I know they're not even writing Rust in this way and that their concerns are hypothetical imaginings. You can't possibly hit the borrow checker in HTTP handlers unless you're very new to the language or doing something incredibly advanced.

I never see the borrow checker for web apps unless I write threaded code that runs on singletons or other shared state - which is an awesome option to have, as it makes async jobs a part of your deployable artifact rather than some 3rd party job system like Sidekiq.

Bonus of using Rust: the person I hired to join me was also able to write a desktop application.

Re: Using Rust at a startup: A cautionary tale

#32

Post by voxl »

> Because we had chosen an “esoteric” programming language for this service, the other engineers in the company who might have otherwise been helpful in building features, debugging production issues, and so forth were largely unable to help because they couldn’t make heads or tails of the Rust codebase.

Then they are bad engineers and should be fired. Maybe it's just my general rage at so-called developers being incapable of understanding undergraduate level recursive functions, but the quality of developer is on the floor in my opinion.

Re: Using Rust at a startup: A cautionary tale

#35

Post by lolinder »

vbezhenar wrote: post #14
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…

IMO if you would forget about borrow checker, Rust is awesome language by itself. I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps. Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other…

This is the kind of attitude that will send Rust the way of C++.

Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-education about which subsets are acceptable in the given organization.

Rust's niche is safely managing memory without a GC. If Rust adds a GC, even an optional one, it will have lost its soul.

Re: Using Rust at a startup: A cautionary tale

#36

Post by NuSkooler »

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…

Have any of you actually written a CRUD app in Rust? I've written a couple that I also wrote in Node and Go. Using Tokio+Actix. It was a breeze, the LoC were actually similar to Node, and the built in observability was great.

Suggesting that Rust isn't a good choice for a backend CRUD is... odd. With that said, one of the particular CRUDs described above: We ultimately went with Go. Only because Rust isn't an officially approved language at our shop yet though.

Re: Using Rust at a startup: A cautionary tale

#37

Post by drewbug01 »

dabeeeenster wrote: post #11
davidw wrote: post #4

> the service we were building was a fairly straightforward CRUD app. The expected load on this service was going to be on the order no more than a few queries per second, max, through the lifetime of this particular system. The service was a frontend to a fairly elaborate data-processing pipeline that could take many hours to run, so the service itself was not expected to be a performance bottleneck. There was no pa…

Elixir for a crud app? Really?

If given the choice between Rails (Ruby) and Phoenix (Elixir) for a low-traffic CRUD app I might have the same sort of question as you - really?

But if the choice is between Elixir and Rust for that same CRUD app, it doesn’t seem strange; Elixir would be a far better choice.

I would presume the commenter is more familiar with ecosystems like Elixir, even though it wouldn’t be the most optimal choice. But certainly more optimal than Rust in that case.

Re: Using Rust at a startup: A cautionary tale

#38

Post by sgeisenh »

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 not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application.

I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility libraries, C++ can be very expressive. And then you have the option to drop down to whichever level of abstraction is necessary to address performance or concurrency issues.

Beyond platform requirements (e.g. HTML, CSS and JS on the web or python for ML) I think language choice has more to do with business needs than high level problem domain. When you're building an MVP or have an urgent business need where you need to prioritize short term progress over long term flexibility, high level languages with GC are great. If you have an experienced team and you want to build something that will offer flexibility in the long term, Rust is a fine choice.

Re: Using Rust at a startup: A cautionary tale

#40

Post by masklinn »

lolinder wrote: post #35
vbezhenar wrote: post #14

Earlier quoted context omitted.

IMO if you would forget about borrow checker, Rust is awesome language by itself. I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps. Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other…

This is the kind of attitude that will send Rust the way of C++. Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-educa…

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.
Post reply on HN