Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

51–60 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#51

Post by saurik »

bmitc wrote: post #30
saurik wrote: post #19

Earlier quoted context omitted.

The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…

There certainly exist languages like F# and OCaml (functional first domain modeling) and also Elixir and Erlang (100% immutable data and failure control) that provide safety but do not get in the way of developer productivity like Rust.

A programming language can not guarantee a program written in it works correctly, even if you are writing in something like Coq or Idris. People who care much more about velocity than about correctness and security--as they are incentivized to do by the shared competitive game they are all playing--can and do routinely code these errors in any number of programming languages.

Re: Using Rust at a startup: A cautionary tale

#52

Post by jdub »

pclmulqdq wrote: post #43
satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

I agree with you about Rust and the web - it's a great fit for a performance-oriented web backend. Personally, I actually think it's a worse fit for things like kernel/embedded development than for web backends. The ergonomics of Rust are so Javascript-y that the web is natural, and other environments where C is used are a lot messier and trickier.

The productiveness, safety, and beauty (seriously!) of the surprisingly numerous Rust kernel and embedded projects suggests otherwise. That use case took off very quickly in Rust world.

Re: Using Rust at a startup: A cautionary tale

#53

Post by candiddevmike »

saurik wrote: post #19
yupis wrote: post #11

"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point

The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…

Rust still won't save you from logic errors, so I guess I don't see your point.

Re: Using Rust at a startup: A cautionary tale

#55

Post by ekidd »

I use Rust at a startup, and it's been great.

But I've used Rust mostly for performance-critical CLI tools, or highly specialized servers. Typically, these have a narrowly defined job that must be done reliably and efficiently. Rust shines at this. These tools run reliably with almost no changes, often for years at a time.

But I have learned that it's often less useful putting policy and frequently-changed business logic in Rust. That kind of code is often accessible to more developers in a strongly-typed scripting language.

Re: Using Rust at a startup: A cautionary tale

#56

Post by dlivingston »

kolbe wrote: post #35

I'm in the middle of a rewrite of my finance analytics library in Rust. I chose it for all the compelling reasons: speed, safety and a great package manager. About 2 weeks in, I hit a blocker, where the most performance critical layer was running 30x slower than C#. It's two weeks since then, and I'm still blocked. Experienced programmers on the language Discord and Reddit have been stumped as well, and I get the imp…

Just out of curiosity, why is your perf-critical layer running so slowly? Are you any closer to cracking it?

Re: Using Rust at a startup: A cautionary tale

#57

Post by satvikpendem »

pclmulqdq wrote: post #43
satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

I agree with you about Rust and the web - it's a great fit for a performance-oriented web backend. Personally, I actually think it's a worse fit for things like kernel/embedded development than for web backends. The ergonomics of Rust are so Javascript-y that the web is natural, and other environments where C is used are a lot messier and trickier.

I wish ReasonML took off more. It's an OCaml dialect which reminds me of Rust with a garbage collector, which is unsurprising given the Rust compiler's history being initially written in OCaml and where a lot of its ideas stem from, such as exhaustive pattern matching, the Result type, functional programming being as performant as imperative programming ("zero cost abstractions") and so on. ReasonML was developed at Facebook by the creator of React and it was supposed to be used as an alternative language than JS for writing React.

However, it didn't have much support after TypeScript took the JS world by storm. If it had, we might have seen the same great Rust-like benefits on the frontend as well, and perhaps the backend too instead of NodeJS.

Re: Using Rust at a startup: A cautionary tale

#58

Post by candiddevmike »

williamcotton wrote: post #34

Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…

You just described any modern language paired with Sqlite.

Re: Using Rust at a startup: A cautionary tale

#59

Post by cryo28 »

andrewmutz wrote: post #31

> This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.

In terms of productivity getting into the first release nothing beats Ruby

Re: Using Rust at a startup: A cautionary tale

#60

Post by KingLancelot »

arcticbull wrote: post #6
paulddraper wrote: post #5

> Rust is awesome, for certain things. > This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices Of course. Use Java/Kotlin or Node.js/Typescript or Go or Python for your basic web services. Easy test: Would you at least seriously consider usin…

The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…

No post body was provided.
Post reply on HN