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

101–110 of 134 posts

Re: Using Rust at a startup: A cautionary tale

#101

Post by xeonmc »

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…

> If you CAN use a language with automatic garbage collection for your project, do that. Always.

Instruction unclear. App is now made in Haskell.

Re: Using Rust at a startup: A cautionary tale

#102

Post by davidw »

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?

I'd probably go with Rails, but Elixir would work out ok for a lot of use cases. Either one seems a significantly better fit than Rust.

Re: Using Rust at a startup: A cautionary tale

#103

Post by 0x457 »

ferdowsi wrote: post #74
voxl wrote: post #32

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

Not very convincing when "git gud" is the common response to Rust's exuberance towards needless complexity in use cases that it doesn't fit well in (like CRUD applications)

I don't think it's a "git gut" kind of response. There are some engineers who keep repeating "oh X is so hard, I've never tried myself or even looked at it, but I've heard that it's hard". X could be anything.

If you are a software engineer and not a code monkey in a web shop, you should have no problem at least trying to expand your knowledge. I worked with people who're afraid of changing a line in k8s manifest file even after you tell them what and where.

There are some languages that look alien to the typical engineer and hard to understand without at least a minor prior knowledge, but Rust isn't one of them.

Re: Using Rust at a startup: A cautionary tale

#104

Post by davidw »

aswanson wrote: post #5
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…

I mean, Rust is the cool new language though.

I'd love to have an excuse to write something with it, but it'd need to be the right excuse - something low level requiring some speed.

Re: Using Rust at a startup: A cautionary tale

#105

Post by ear7h »

My devil's advocate take on this article is that they're using Rust as scapegoat to their scaling (team not performance) problems. I use Go at $DAYJOB and we're having similar problems for lead times. OTOH, the novelty of Rust in webdev, means there isn't someone to make a decision like, "we don't need performance, so use threads instead of async and pass everything around in a box". I've sunk plenty of personal time trying to wrangle async on a CRUD app for learning, and I recommend it as an exercise, but I'd avoid async if I was trying to ship something.

Re: Using Rust at a startup: A cautionary tale

#106

Post by revskill »

Jensson wrote: post #99
dinosaurdynasty wrote: post #83

Earlier quoted context omitted.

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

Haskell programmers says that Haskell is just fine as well, but in the end there aren't many big programs with complex architecture in these languages. Compilers, interpreters, crud servers etc, those things are very simple architecturally so for them these languages are fine, but for more complex cases these pure languages seems to be too cumbersome.

What i love about Haskell, is it made things simple, not simpler.

If you have a program with complex architecture, you're doing wrong somehow.

If you can't decomposing the complexity, you will have complexity. I think it's not about programming language, it's about human (and technology).

Re: Using Rust at a startup: A cautionary tale

#107

Post by aswanson »

davidw wrote: post #104
aswanson wrote: post #5

Earlier quoted context omitted.

I mean, Rust is the cool new language though.

I'd love to have an excuse to write something with it, but it'd need to be the right excuse - something low level requiring some speed.

Same. Im looking for an excuse also.

Re: Using Rust at a startup: A cautionary tale

#108

Post by vips7L »

mjr00 wrote: post #61
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…

I worked with the same guy who made a CLI tool in Java + RxJava. Running everything reactively on hundreds of thread schedulers for something that needed basic collection of arguments and to post to an api.

I can't wait for reactive programming to die.

Re: Using Rust at a startup: A cautionary tale

#109

Post by alpaca128 »

bitL wrote: post #76
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 am struggling to find any benefit of Rust for startups to be honest. It makes no economical sense to be bogged down by a language that is 3-10x slower to develop. The issues Rust is preventing will pop up earliest in production, likely rarely and at that point in time the company could be profitable, its product somewhat stabilized and actually have a case of using Rust for an internal rewrite.

> 3-10x slower to develop

Where do those numbers come from? Rust is not very beginner friendly and takes a while to learn, but nowadays I'm just as fast in it as in other languages, except maybe for Python.

That said I also don't think it makes sense for startups.

Re: Using Rust at a startup: A cautionary tale

#110

Post by Jensson »

revskill wrote: post #106
Jensson wrote: post #99

Earlier quoted context omitted.

Haskell programmers says that Haskell is just fine as well, but in the end there aren't many big programs with complex architecture in these languages. Compilers, interpreters, crud servers etc, those things are very simple architecturally so for them these languages are fine, but for more complex cases these pure languages seems to be too cumbersome.

What i love about Haskell, is it made things simple, not simpler. If you have a program with complex architecture, you're doing wrong somehow. If you can't decomposing the complexity, you will have complexity. I think it's not about programming language, it's about human (and technology).

When you try to adapt your program to fit the needs of humans and technology it will become complex no matter what you do. The world is full of problems that can't be decomposed nicely because they are created by millions of people over decades each doing things slightly differently and you need to make a program that fills their needs, if you think those kind of problems don't exist you are just naïve. Those are the programs with the most complex architecture.
Post reply on HN