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

121–130 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#121

Post by steveklabnik »

marcosdumay wrote: post #119
zozbot234 wrote: post #111

Earlier quoted context omitted.

> automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago. These claims should really come with sourcing. Rust devs have been raising the potential for abstraction in Rust since the initial 1.0 release, most recently with GAT's. What's always been quite hard is zero overhead abstraction, which GC languages simply have no equivalent for.

Sourcing for my "water is wet" claim? Just try writing a language parser in Rust and Haskell and you'll see the difference. Or, to be more on topic, write some database to HTML on Rust and note how you have to keep track of your templates' lifetimes. The Rust developers are a bunch of very smart people working hard on creating a great language, but they can't do impossible things.

I have written HTML templates and never had to keep track of lifetimes. Do you have an example of how that happens?

Re: Using Rust at a startup: A cautionary tale

#122

Post by steveklabnik »

zozbot234 wrote: post #95
lolinder wrote: post #92

Earlier quoted context omitted.

True, but linearity/affine types applied carefully in the context of a managed runtime would look quite different from Rust's borrow checker. The reason why Rust's borrow checker is so infamous is because Rust has to prove everything at compile time. Bringing affine types to a GC language would most likely involve making them opt-in (or only triggered in concurrent situations), while making linearity optional in Rust…

You can opt into runtime checking in Rust via interior mutability. Cell , RefCell , Rc , Arc , Mutex , Rwlock are constructs that involve varying levels of runtime checking - most of these will be way more efficient than GC. It's even simpler to use .clone() in order to effectively do away with any requirement for linearity.

(Cell doesn’t actually do runtime checking)

Re: Using Rust at a startup: A cautionary tale

#123

Post by Animats »

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…

Also green threads might be a good addition. It seems that modern computing reinvents it all over again. Golang, Java. Async/await is hard, people want to write blocking code and get good scalability at the same time.

This is the basic win of Go. Go's "goroutines" are preemptable. So there's no need for an async/thread distinction.

Re: Using Rust at a startup: A cautionary tale

#124

Post by jpgvm »

Barrin92 wrote: post #80
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…

maybe as a compromise, there's some good languages on top of those stacks. F# exists. You get a lot of the good features that people mention about Rust in this thread without the headaches mentioned in the article. Expressive GC languages within the major ecosystems exist, no need to reach for a systems language for a web app just because you want the modern, high level features.

Yeah Kotlin, F#, etc. These are all acceptable.

Re: Using Rust at a startup: A cautionary tale

#125

Post by jpgvm »

brap wrote: post #66
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.

Because the impact on your code by going with a serverless platform.

Generally speaking if it's the platform you have you will shoehorn the shape of your code into a serverless shape bucket even if it has no business looking like that. These architectural shortcomings will inevitably come back to haunt you.

Also most of these platforms amount to cgi-bin v2, meaning things like memory leaks and requests that hang get swept under the rug. Meaning you already have very difficult to diagnose failures and when you do eventually go to migrate you will find your code is full of these smells making it harder to reform into something reasonable.

That is also putting aside the spaghetti nature of intertwined functions of any serverless codebase of scale, the huge IaC overhead if you go with something like AWS Lambda and the massive amount of incidental complexity that serverless advocates try to make you look the other way for (hello API Gateway).

Re: Using Rust at a startup: A cautionary tale

#126

Post by jpgvm »

satnam14 wrote: post #118
eropple wrote: post #44

Earlier quoted context omitted.

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

Curious to hear more about your experience with Node/TypeScript. Is it really comparable to the maturity of JVM or the .Net ecosystems? I've experienced some problems such as: 1. It's still running JavaScript on server-side 2. Debugging becomes a pain because stacktraces will contain .js files and line numbers 3. Multi threading is still complex.

Main issues (non-exhaustive) with Typescript are:

1. Type checking is slow (this problem scales with the size of your project also which sucks) 2. Lack of proper build system ecosystem (as compared to Maven/Gradle/etc) 3. Ecosystem is poor 4. Packaging and module systems are poor (import side effects, gross)

If you tackle 2. you can also work around 1. Best way to do this at this time is to use the new Bazel rules_js/rules_ts ecosystem. This will result in lowering the amount of time you spend type checking and transpiling things making it tolerable.

3. and 4. however are just things you have to live with if you go with Node.js.

Re: Using Rust at a startup: A cautionary tale

#127

Post by lumost »

pitaj wrote: post #55
lumost wrote: post #30

If you are writing CPP, rust is a godsend. Many pitfalls/code review debates/wtf moments simply don’t happen in the language. There are huge cpp code bases in the wild which need help. However rust string handling is barely a step above c’s, there are a variety of datastructures c engineers dislike simply because of the memory management constraints. Getting 2x better performance than Java is a marginal gain for many…

I've found Rust is also far better than weakly typed and dynamically typed languages as well. > However rust string handling is barely a step above c’s How so? Personally I've found it very good.

Having 3 separate string types commonly used across the standard library is a huge friction.

For beginners, it’s impossible to write a common program for doing some basic string manipulation without reading 3/4 of the Rust book and waiting through dozens of compilation failures.

Re: Using Rust at a startup: A cautionary tale

#128

Post by brap »

jpgvm wrote: post #125
brap wrote: post #66

Earlier quoted context omitted.

> 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.

Because the impact on your code by going with a serverless platform. Generally speaking if it's the platform you have you will shoehorn the shape of your code into a serverless shape bucket even if it has no business looking like that. These architectural shortcomings will inevitably come back to haunt you. Also most of these platforms amount to cgi-bin v2, meaning things like memory leaks and requests that hang get…

I'm not a fan of serverless/lambdas for this exact reason, I was referring specifically to PaaS solutions, where you can build your services without vendor lock-in, in a way that makes it easy to containerize later on. Things like memory leaks and requests that hang are usually reported by these platforms.

Re: Using Rust at a startup: A cautionary tale

#129

Post by kzrdude »

filleokus wrote: post #63
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#.

Arc is not a convenience, since the type matters, the type is visible most places, almost no trait impls transparently work the same on T and Arc T and so on. For all its strengths, it must be said that it's not a language of transparent convenience, not when it comes to this central issue of ownership and sharing.

Re: Using Rust at a startup: A cautionary tale

#130

Post by jpgvm »

brap wrote: post #128
jpgvm wrote: post #125

Earlier quoted context omitted.

Because the impact on your code by going with a serverless platform. Generally speaking if it's the platform you have you will shoehorn the shape of your code into a serverless shape bucket even if it has no business looking like that. These architectural shortcomings will inevitably come back to haunt you. Also most of these platforms amount to cgi-bin v2, meaning things like memory leaks and requests that hang get…

I'm not a fan of serverless/lambdas for this exact reason, I was referring specifically to PaaS solutions, where you can build your services without vendor lock-in, in a way that makes it easy to containerize later on. Things like memory leaks and requests that hang are usually reported by these platforms.

Fair, the ones that let you run containers directly like Cloud Run etc are fairly reasonable and approximate the k8s experience.

I think by going non-k8s you miss out on some of the key benefits though like standardized API and more portability of the surrounding infrastructure like networking and storage that is otherwise proprietary or not available on "simplifed" PaaS platforms.

I guess my argument boils down to cost of using managed k8s is low, low enough it's not worth using non-standard services instead.

Though I would like to address a point in your earlier comment though that is that it implied "k8s is about scale".

K8s has absolutely nothing to do with scale, the fact it can scale horizontally is a side effect of enforcing good separation of concerns and API design in the orchestration layer. You use k8s because the APIs make your applications better, even with they are small. This is the true innovation behind k8s. There were other platforms that made containers accessible (I worked on one called Flynn, Deis, Heroku to an extent, etc) but none of them pushed a better paradigm around orchestration which is why they didn't lead to the same level of success k8s has.

Post reply on HN