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

91–100 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#91

Post by Zagill »

satvikpendem wrote: post #78
Zagill wrote: post #73

Earlier quoted context omitted.

This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in t…

Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.

Re: Using Rust at a startup: A cautionary tale

#92

Post by WiSaGaN »

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

This really depends on your problem domain. Rust productivity is vastly higher than C++ due to its helpful compiler error message, package manager, integrated tests and bench facility, and language features like algebraic datatypes and a whole lot more. This also hasn't counted the reduced debug time later, which would be a significant time spent by devs in C++. In areas that don't value performance and correctness, or requirements vary a lot faster like a web app, you will spend time trying to get something correct which you may throw away pretty fast later, which will not be very productive. Thus I think it has less to do with startup picking Rust, but more of whether teams have picked right tool for their domain.

Re: Using Rust at a startup: A cautionary tale

#93

Post by bmitc »

saurik wrote: post #51
bmitc wrote: post #30

Earlier quoted context omitted.

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.

I see what you are getting at. I think I may have misinterpreted what you originally wrote. Although my comment still stands alone, I can agree that getting people and organizations to move slower, as a whole, would be beneficial. The venture capitalism going on is basically just people trying to make a buck as quick and as much as possible. There's very little art or craft involved or concern for actual customers today.

Re: Using Rust at a startup: A cautionary tale

#94

Post by saurik »

ninepoints wrote: post #71
saurik wrote: post #48

Earlier quoted context omitted.

I'm sorry, do you somehow think that is a theoretical concern? I seriously won a $2M bug bounty earlier this year because the CEO of a company wanted to "move fast and break things" their way to a financial product offering :/.

It's alarmist because not all software is a financial product and your original statement lacks necessary qualifiers.

No, some products--like this guy's startup--are providing machine learning services for such devices as cars and drones, an area where safety clearly doesn't matter ;P. I think the issue, FWIW, is that we are actually going to disagree on what those "qualifiers" should be, not merely that they might exist.

Re: Using Rust at a startup: A cautionary tale

#95

Post by mindcrime »

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.

Grails

Re: Using Rust at a startup: A cautionary tale

#96

Post by satvikpendem »

Zagill wrote: post #91
satvikpendem wrote: post #78

Earlier quoted context omitted.

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in t…

Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.

Sure, I did not mean Go specifically when I said that, just stating how when I used linters in other such languages, it was not comprehensive enough to replace a language with types and other niceties built-in.

I also don't use much Go because it lacks good algebraic data type support, honestly can't imagine going back to a language that doesn't have them as I like to define all my business logic in types and then build the actual application from there. Go simply doesn't have that capability.

Re: Using Rust at a startup: A cautionary tale

#97

Post by saurik »

sarchertech wrote: post #67
saurik wrote: post #48

Earlier quoted context omitted.

I'm sorry, do you somehow think that is a theoretical concern? I seriously won a $2M bug bounty earlier this year because the CEO of a company wanted to "move fast and break things" their way to a financial product offering :/.

The CEO wanted to move fast and break things with respect to security but offered a $2 million bug bounty?

I am not sure how those aren't incompatible thoughts... I was explicitly told, by the CEO, that she was channeling that mindset, and the security engineer there I ended up speaking to was clearly not bothering to actually figure out how to filter change sets made by their engineer as he "felt bad" about it... and I kind of don't blame them, as to the winners go the spoils in some sense? They were super lucky I was the one that found the issue and not a black hat, as $2M was nowhere near how much damage I could have caused. And that's in a financial system, where you might expect someone to know better, and yet they have the same incentives to play fast and loose as everyone else :(.

Re: Using Rust at a startup: A cautionary tale

#98

Post by bacon_waffle »

TylerE wrote: post #23
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…

“Software doesn’t exist yet” is a huge user cost

Could you expand on this? It doesn't really make sense to me, but I'm also a Rust fan. The premise that Rust prioritizes safety (or performance) over developer productivity also doesn't resonate.

As a consumer, I tend to prefer the thing that is available a bit later (or more expensive) and works well, versus the one that is available sooner (or cheaper) and is less reliable. Maybe that preference is a result of years spent fixing things that could've been designed better?

Re: Using Rust at a startup: A cautionary tale

#99

Post by williamcotton »

candiddevmike wrote: post #58
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.

I mean, I’ve written C that listens on port 80 and parses HTTP requests directly into SQLite op code but that is definitely not how it is working when you glue together a bunch of npm modules.

Just like how SQL gives you a faster way to not only store and search through binary trees but also to write the instructions to do so means that we should be able to do the same for web applications.

I’m not sure that most parts of a web application need to be Turing complete. User permissions? Data validation? Can’t we have GUI tools with a 1:1 mapping to more declarative code, ala SwiftUI? Why are we using a garbage collector for an HTTP request when we could just be freeing up memory after the response is sent?

Re: Using Rust at a startup: A cautionary tale

#100

Post by roxgib »

kelnos wrote: post #27

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. This is really the main reason not to use Rust when you need to move fast: if you don't know the language yet, it will take you time to learn it. But that's true of any language. You probably shouldn't do your startup in Java, either, if your team isn't familiar with it. Yes, Rust's learning curve is…

In fairness, apparently the founders were all Rust people
Post reply on HN