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

191–200 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#191

Post by jasonjmcghee »

polio wrote: post #109
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 lack of compilation time in Python is a false economy when you consider the cost of tacking on the type checker and the developer time spent wondering whether the type that's been annotated is accurate. Static typing is good for developer velocity.

Not to mention that cythonization might be part of the pipeline and can have bugs that only show up post-cythonization.

I really dislike python in production and have done it a lot more than I've ever wanted.

Re: Using Rust at a startup: A cautionary tale

#192

Post by artic91 »

I feel that this is a click bait to attract employees. The writer links to his startup on his profile (which Medium shows right next to the article), where you can see that he's looking for founding engineers. Rust has been a trending topic lately, which attracts relatively experienced engineers. He mentions that he made these experiences more than 2 years ago, so it's notable that he waited so long to write about it. The slightly noisy "ex-google" and "ex-apple" mentions sound like advertisement.

And, well, the usual, "learning curve" and some largely hypothetical concerns about hiring. I developed a complex app with Rust with very high time pressure and with developers that didn't have any previous Rust experience (I didn't have much of it myself), it was risky but it worked out well, so I know first hand that it's possible. And we are not "ex-google"!

Re: Using Rust at a startup: A cautionary tale

#193

Post by nine_k »

kazinator wrote: post #187
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 can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

If you think Result is not ergonomic enough, try writing some Go.

In fact, you can often return Result from an underlying function from your own, achieving an effect similar to exceptions.

Re: Using Rust at a startup: A cautionary tale

#194

Post by shepherdjerred »

pipe_connector wrote: post #81
satvikpendem wrote: post #62

Earlier quoted context omitted.

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.

> but it's very easy to incorporate.

As someone who is adding this to a Go project with hundreds of unchecked errors, I disagree.

Re: Using Rust at a startup: A cautionary tale

#195

Post by 3a2d29 »

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 would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible.

Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue?

If you like Result or concurrency, use a GC language with those things. Go may not have them, but your choice isn't just Go.

Re: Using Rust at a startup: A cautionary tale

#196

Post by 3a2d29 »

kazinator wrote: post #187
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 can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

I will die on the hill that Exceptions are absolutely terrible for readability and control flow and should die.

Result or Go returning many values is wayyyy better.

Re: Using Rust at a startup: A cautionary tale

#197

Post by satvikpendem »

3a2d29 wrote: post #195
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 would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible. Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue? If you like Result or concurrency, use a GC language wi…

Can doesn't mean will. I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

Re: Using Rust at a startup: A cautionary tale

#198

Post by satvikpendem »

kazinator wrote: post #187
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 can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

Sorry, I will disagree. It seems like you haven't written any Rust, try it and see how well a Result type works instead of excepting everywhere.

Re: Using Rust at a startup: A cautionary tale

#199

Post by 3a2d29 »

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…

> Easy test: Would you at least seriously consider using C/C++ for it? Only then should you use Rust.

This is a great point. I understand liking a language, but don't bring Rust into a GC space (in industry, personal projects can be what you like!) You can find a GC language with all the features of rust you like.

Re: Using Rust at a startup: A cautionary tale

#200

Post by burnished »

saghm wrote: post #145
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…

> It's as ergonomic as (and sometimes even more so than) any NodeJS or Go API I've made (as even though Rust doesn't have function overloading, actix-web and others have some macro magic they do behind the scenes to make it appear as if it does) Not that this takes away from your point, but does Go have function overloading? I had assumed it hadn't given the discussions I had heard about what it would take to retrofi…

No function overloading. Functions and methods can have the same name, params and return type.
Post reply on HN