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

81–90 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#81

Post by pipe_connector »

satvikpendem wrote: post #62
candiddevmike wrote: post #50

Earlier quoted context omitted.

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.

https://github.com/kisielk/errcheck

Every Go project I've worked on has used this linter. I think it should be builtin, but it's very easy to incorporate.

Re: Using Rust at a startup: A cautionary tale

#82

Post by deagle50 »

candiddevmike wrote: post #50
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…

God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.

It's super annoying, I switched from Go to Rust for my personal projects because of it. It's like a seat belt beep that won't stop.

Re: Using Rust at a startup: A cautionary tale

#83

Post by satvikpendem »

necubi wrote: post #75
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

I don't really agree with that framing. Most of the languages people use to write web apps are safe! The actual tradeoff rust is making is that performance is more important than developer productivity. It's not willing to sacrifice safety for productivity, but fundamentally the reason to use rust is that it's fast. If you don't need performance, you might be better off using any number of safe, GC languages. (That s…

Have you tried ReasonML?

Re: Using Rust at a startup: A cautionary tale

#84

Post by dap »

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 doesn't match my experience. It took some time to get up to speed, but at this point it's much faster for me to write something in Rust than in other languages that I'm proficient in that are ostensibly faster to develop in (e.g., JavaScript).

Part of this depends on one's bar for quality. In Node.js I could write `JSON.parse(input).foo.bar` really quickly. In Rust, I'd probably write two struct definitions with `#[serde(Deserialize)]` first, then a similar line. It'd take 45 seconds longer, but when I'm done, the Rust program validates the input and prints decent error messages.

Re: Using Rust at a startup: A cautionary tale

#85

Post by pornel »

WirelessGigabit wrote: post #46
63 wrote: post #15

There's a reason why we see so many articles like "we rewrote x in rust." Rust makes sense when you've scaled to the point that you're seriously considering performance. Sure, starting with rust can potentially save you time, money, and refactoring down the line but only after you've reached a point that few startups ever hit. Otherwise you're limiting yourself with slow development times (compared to, say, Python) a…

The thing with Rust is that you are enforcing so many things from the start. I feel that it is actually harder to write bad code in Rust than it is in say, Python.

Trying too hard to write good code can be a deadly mistake for an early-stage startup regardless of the language you use.

If you're really a startup, looking for a product-market fit, then you don't know exactly what you're building yet. There's a high change you're going to throw away a lot of code.

e.g. you spend effort caring about scalability, flexibility, proper architecture, full test coverage — only to hand it to users who will say they won't buy it, it's not actually the feature they wanted. You can learn such lessons with crappy copy-pasted code, and then worry about code quality once you've figured out what to actually build.

Re: Using Rust at a startup: A cautionary tale

#86

Post by mamcx »

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

> but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial

This could be true for C++, Java or maybe C#. Against them, python/ruby run circles.

But Rust change the equation.

Is super-productive... BUT what is important to note is that you need developers that have done the initial climb and go fully rust with it.

After this, things start to click neatly:

- Modeling code is easy & fast

- Composing code, flow!

- Testing (all of it, including benchmarking and integration) flow.

- Refactoring (big!) is super-easy. This one is where the "velocity" is actually need.

But you CAN'T "code fast". You CAN'T skip in good practiques "let's ignore the use of clippy, Result, proper use of traits (like Into/From), etc". (and even write documentation with including doc-test!)

This is where the "I write code FAASSST bro!, not time for pesky good practiques!" get hurt with Rust.

You need to buy the whole package, because Rust is MADE to be used fully in harmony.

And when you finally do it. IS FAST TO CODE.

And even FASTER to refactor.

And probably so minimal post-fixes.

---

P.D: Major blow against Rust? Slow compiling. This is the one factor that blow the dream and where you truly need a decent machine and flow to make it nice. However, if you take the above advice, you are already with Test/DocTest/Clippy/Check flow and that part can be done to be efficient.

Re: Using Rust at a startup: A cautionary tale

#87

Post by Cyph0n »

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…

If it’s 30x slower than C#, there must be something very wrong. Have you done some CPU profiling to see where the bottleneck is?

As for Rust’s performance, it has been proven time and again to approach that of C and C++. One counterexample does not disprove that.

Re: Using Rust at a startup: A cautionary tale

#88

Post by pipe_connector »

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…

In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.

Re: Using Rust at a startup: A cautionary tale

#89

Post by dap »

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

The idea that a clever memory leak is the root cause of most stolen data instead of a phishing attack is ridiculous

I think most of the things that people feel slow them down about using Rust are cases where the language is forcing you to be kind of pedantic about types (and other invariants encoded in the type system). I totally get that. But the idea that compile-time checks don't eliminate important classes of runtime bugs that impact end users is also ridiculous.

Re: Using Rust at a startup: A cautionary tale

#90

Post by robotastronaut »

dylan604 wrote: post #38
lolinder wrote: post #28

Earlier quoted context omitted.

> while the benefits of trading safety vs. velocity go to the company, the costs go to the user This is a problem in general, but it's not a good reason to use Rust in a startup, it's a good reason to use Java or C# or TypeScript or another well-worn high-level language with static typing. Rust's niche is solving a set of security problems that most high-level languages don't have. Choosing it for a startup only real…

>This is a problem in general, but it's not a good reason to use Rust in a startup, It's a good reason to not collect/store information in the first place. If your startup depends on the collection of your user's PII, then I'd seriously question if there's a real purpose to your startup. IF your startup 100% does require the use of PII, then yes, slow the fuck down, and do it right.

I think that’s a bit reductive. The health tech industry as a whole fits this bill — do you question if startups in that sector have a real purpose? There are loads of green engineering teams that have to figure out how to comply with really tricky data handling regulations.
Post reply on HN