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

I love building a startup in Rust but wouldn't pick it again

propelauth.com

Post reply on HN
Print view View original

251–260 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#251

Post by mike_hearn »

bryanlarsen wrote: post #59

I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I…

Have you tried something like Kotlin? It has the same experience IMO of being very easy to refactor, especially because the IDE can do so many refactorings for you very fast, and because the compile turnaround time is so low.

Re: I love building a startup in Rust but wouldn't pick it again

#252

Post by dmillar »

Perhaps not the case here, but there are a couple of things I would add to this sentiment.

First, if you love Rust uniquely, I'd argue it might still make sense to use Rust to build your first product iterations. If your initial team commonly loves Rust, and can't agree on "love" for another common language, perhaps Rust is the best language. Burnout will happen exponentially faster if developers are lamenting the language (n.b. Rust is commonly lamented). I think there are enough language/platform options these days for this to be an unlikely scenario, but this is to say don't discount your passion for a language because it doesn't iterate fast enough.

Second, if the problem your startup is trying to solve is solidly in the performance and security realm, it makes sense to start in Rust. If your pitch is something like "pandas but fast and memory efficient" it also makes sense to start your project in something like Rust.

Re: I love building a startup in Rust but wouldn't pick it again

#253

Post by jay-barronville »

bryanlarsen wrote: post #59

I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I…

> Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that.

You can’t be serious. I’ve seen prototypes get thrown away all the time, especially at startups. In fact, I’d say that’s more common than not.

Re: I love building a startup in Rust but wouldn't pick it again

#254

Post by mike_hearn »

orthoxerox wrote: post #100
Jensson wrote: post #14

Earlier quoted context omitted.

In Java functions declares Exceptions in its type signature, so it does all of that automatically. Then you get a compile error if you don't handle it in the function, or you need to declare the function throws it, so it is type safe. Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that.

Java isn't generic over exceptions. You can't write a method that takes an instance of Foo and says "my method throws whatever Foo.bar() throws" or even "my method throws iff Foo.bar() throws". And this means that your method either always demands to be wrapped in a try-catch, or you migrate to unchecked exceptions. Rust makes errors a part of the regular type system, so they automatically benefit from all its featur…

> You can't write a method that takes an instance of Foo and says "my method throws whatever Foo.bar() throws" or even "my method throws iff Foo.bar() throws".

If you could it'd mean altering the implementation would automatically alter the API, which would be rather unexpected.

That's why the Java approach is to wrap exceptions and propagate causal chains. The underlying errors thrown by the implementation can change but the advertised exceptions don't, but no information is lost.

Re: I love building a startup in Rust but wouldn't pick it again

#255

Post by mike_hearn »

lenkite wrote: post #203
newZWhoDis wrote: post #197

Earlier quoted context omitted.

> Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that. What people? Please tell me where they’re at so I can tell them they are wrong (lol) But seriously, I could not disagree more.

The designers of the Java functional and stream library for one. None of the functional contracts have throws. So you are forced to have un-checked exceptions for everything, unless you want a truly mind-boggling amount of try-catch everywhere which will rapidly exceed your normal code by factor of 2x-3x.

In Java, yes. Note that the JVM doesn't enforce checked exceptions. It's a language level thing. So in Kotlin for example, where all exceptions are unchecked, you can use the streams library without needing try/catch.

Re: I love building a startup in Rust but wouldn't pick it again

#256

Post by PaulHoule »

pythonaut_16 wrote: post #151
adamc wrote: post #130

Earlier quoted context omitted.

While I think this is a good point, a lot of the answers cannot be determined by the generator of the exception. Your SQL library cannot know what the implications of an error are -- is this a minor part of the system for which the error can be logged but mostly ignored, or is it critical? Etc. People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the cri…

This is sort of what HTTP codes get at though. The server doesn't know what you want to do with a 400 but it knows that the problem is with the request for example.

Actually there is somewhat standardized set of SQL error codes and they can be put into a hierarchy like the HTTP codes.

For instance, you can have a SQL error because the syntax of your SQL is wrong. If you're not doing "dynamic SQL" you know this is a programming error (it doesn't matter what input was supplied to the functions.) One common error is "attempted to insert a row with a duplicate key", frequently you want to catch that SQLException and rethrow all the rest.

The ideal SQL library for Java would expose the hierarchy implicit in SQL errors as a class hierarchy.

Re: I love building a startup in Rust but wouldn't pick it again

#257

Post by legerdemain »

ye-olde-sysrq wrote: post #200
brimstedt wrote: post #172

Earlier quoted context omitted.

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code. I really don't see how anyone choses nodejs/deno to anything. Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime. Next on my list is to give rust a go, since I'm intrigued by its featu…

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends.

They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS.

I have looked for non-tinkertoy solutions in Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks).

But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.

Re: I love building a startup in Rust but wouldn't pick it again

#258

Post by CuriouslyC »

ye-olde-sysrq wrote: post #200
brimstedt wrote: post #172

Earlier quoted context omitted.

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code. I really don't see how anyone choses nodejs/deno to anything. Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime. Next on my list is to give rust a go, since I'm intrigued by its featu…

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

While it doesn't have the batteries, typescript's gradual typing is much nicer than python's, so for some use cases it's a better language.

All languages come with tradeoffs in terms of performance, development/maintenance cost and ease of hiring. Most businesses only care superficially about performance, which leaves developer productivity and ease of hiring. Node/typescript isn't terrible in terms of developer productivity, and it's got the best hiring story of any language. Python is good in both those ways too, but since you already need a javascript hiring pipeline for the client it's easier just to use node and hire full stack devs.

Re: I love building a startup in Rust but wouldn't pick it again

#260

Post by zozbot234 »

alfalfasprout wrote: post #205
throw14082020 wrote: post #94

Earlier quoted context omitted.

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your compan…

Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions a…

Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.
Post reply on HN