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

81–90 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#81

Post by polio »

sgeisenh wrote: post #38
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 lib…

Batch jobs seem like a good candidate for C++ because of how much faster a single instance will be. Multiplied across the size of the total job, that can represent enormous savings. On the other hand, using Rust for a web server with low QPS and atop a relatively novel web stack seems unnecessarily risky. The article does comment on Actix being a pain point.

My current job doesn't use Rust at all, but we're experimenting with converting some CLI tools. There should be relatively little library dependence for the things we're targeting.

Re: Using Rust at a startup: A cautionary tale

#82

Post by rootusrootus »

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…

I generally agree, but with the ecosystems they have today I think Python and Node are both completely acceptable for a general purpose low-risk tech stack. In fact I would choose either of those before I'd go with a monovendor solution like .NET & SQL Server.

Re: Using Rust at a startup: A cautionary tale

#83

Post by dinosaurdynasty »

darthrupert wrote: post #27
revskill wrote: post #10

One question though: What does Garbage collection do besides what Rust provide? Ownership and borrow checker.

Frees cognitive resources because you can usually forget that menory management is a thing. When on GC.

I usually don't think about memory management in Rust, to be fair.

Also GC doesn't remove all resource management... ironically I find most GC-based languages to be more mentally taxing when managing manual resources (file handles, mutex locks, etc).

Re: Using Rust at a startup: A cautionary tale

#84

Post by [deleted] »

wyldfire wrote: post #69

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

[deleted]

Re: Using Rust at a startup: A cautionary tale

#85

Post by marcosdumay »

sgeisenh wrote: post #38
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 lib…

Yes, it's a completely clear cut.

If you want high level abstractions, well, automatic memory management enables a bunch of abstractions that the Rust developers gave up on long ago. There are languages with many more capabilities than the ones Rust gives you.

If you have a high level problem, you don't want to spend your focus on low level issues.

Re: Using Rust at a startup: A cautionary tale

#86

Post by polio »

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…

I feel like writing code that satisfies the borrow checker isn't that hard if you intuitively understand the lifetimes of the things you're dealing with. In C++ you have to do this anyway, so having the compiler help actually decreases the cognitive burden. I feel like desiring garbage collection is mostly a code smell, because it indicates that lifetimes and ownership are not obvious. Sometimes that'll legitimately be the case due to shared ownership, but there are facilities in both Rust and C++ for that.

Re: Using Rust at a startup: A cautionary tale

#87

Post by loeg »

zozbot234 wrote: post #68
loeg wrote: post #60

Earlier quoted context omitted.

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 "clea…

Wasting time on things that don't matter is a trap. It's (IMO) easy to run into this when you're new with Rust and aren't sure of best practice patterns/conventions.

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

You can definitely spend too much time refactoring in other languages, but I found I was more tempted to do so in Rust than in C (perhaps due to familiarity with C).

Re: Using Rust at a startup: A cautionary tale

#88

Post by francasso »

NuSkooler wrote: post #36
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 officia…

I think it comes down to how big/experienced the team is, how old the product is, and how many unfortunate decisions where made in the history of the project that are there to stay. To me the point of the article is that rust would not be a robust choice considering all these factors.

That said, the article is a sample of 1. I'm not aware of other similar experiences

Re: Using Rust at a startup: A cautionary tale

#89

Post by marcosdumay »

NuSkooler wrote: post #36
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 officia…

> Have any of you actually written a CRUD app in Rust?

I have, and Python from 10 years ago was a better platform.

Sure, it beats the Javascript ecosystem, but that's too low a bar.

Post reply on HN