Live data from Hacker News

Using Rust at a startup: A cautionary tale

scribe.rip

41–50 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#42

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

Doesn’t Kotlin or Swift offer those things?

I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous.

If one doesn’t exist already, someone should make a rust-like language with garbage collection.

EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of rust without the memory risks.

Re: Using Rust at a startup: A cautionary tale

#43
> [...] most modern, procedural languages (C++, Go, Python, Java, etc.) all very similar in terms of their basic concepts. [...] With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, [...]

Maybe an oversight, C++ is misplaced in that list. C++ without knowing about ownership and lifetimes is a recipe for disaster.

Re: Using Rust at a startup: A cautionary tale

#44
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…

For my money, at least Node and Python have absolutely reached the point where they can provide self-feeding velocity. I quite like the JVM as well--I've written a lot of Java and a lot of Kotlin--but TypeScript and modern, typed Python are very defensible options. I know more about Node than Python, so that's easier for me to talk about, but for my money tools like Fastify have a really excellent ecosystem around getting shit done in ways that don't buy you too much technical debt in the future.

Databases, fully agreed. "Use Postgres unless you have a reason not to." When you need a key-value store for caching or whatever...consider Postgres hstore first, and then spin up a Redis only when you need to.

Hosting...depends. With my product hat on instead of my infra hat, I think there's real value in managed serverless options. The various Heroku descendants--I work at Render, but I'm friends with the Fly folks and they're great too--can, if you are in a low-devops environment, provide some real benefits. Or, for a more stripped-down option, AWS Fargate/GCP Cloud Run, but to bootstrap that you're going to be doing somewhere between the work necessary between a Heroku++ option and "run a server somewhere and keep it patched".

Re: Using Rust at a startup: A cautionary tale

#45

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…

A framework for "pluggable" and optional GC could be very helpful for dealing with the rare case of general graph-like data, where there really is no feasible alternative in terms of more explicit memory management. This will probably be done as a natural outcome of stable support for "local" allocators, which is already planned in Rust itself.

Re: Using Rust at a startup: A cautionary tale

#46
One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse.

As a result, expect some churn in your codebase. Your team will have to discover and iterate upon best practices. Avoid the impulse to spend too much time code golf refactoring because “oh I can use a proc macro to decrease boilerplate while avoiding the orphan rule and having nice traits!” Rust can definitely nerd snipe you by making you worry about some very small edge case like oh no I’m copying a few too many times.

Basically unless you’re pretty damn sure you have product market fit (PMF) and you’re sure that rust offers an appreciable benefit to said PMF, I would not use it.

Re: Using Rust at a startup: A cautionary tale

#47
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?

Elixir offers a lot of the great protections of rust.

If you haven’t tried it, I 100% recommend.

Re: Using Rust at a startup: A cautionary tale

#49

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…

Anecdotally I've been able to move faster with Rust on CRUD apps professionally than I've previously in other languages with GC built-in (e.g., C#, TypeScript/Node.js). The borrow checker isn't a problem after you get used to it. There is still a steep learning curve, although the learning curve has improved significantly over the past couple years. Rust's type system, syntax, and standard library are major strengths…

Rust has healthy friction and you learn how to avoid that friction. It might take you a bit longer to hash something out but chances are it will work first time, and will have better fundamentals in design.

Re: Using Rust at a startup: A cautionary tale

#50

One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse. As a result, expect some churn in your codebase. Your team wil…

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