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

81–90 of 496 posts

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

#81

Post by jeroenhd »

wvenable wrote: post #58
nemothekid wrote: post #5

Earlier quoted context omitted.

I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.

Assume all functions can throw and there is no extra work reading. A function that has no possibility of error is so uninteresting in the context of error handling. Furthermore, handling errors has little to do with where the error is actually caused. In general, you can only do two things with errors: log and kill the operation or retry the operation. Neither of these has anything to do with the leaf function 20 ite…

"Assume all things can throw" is what I've seen people do in Java code that adds a million try catch wrappers around everything just in case something may go wrong at some point.

The end result is either completely unreadable or impossible to figure out. "How do I return fallback data for FooBarService.wiggle()" often ends up in digging through (incomplete, outdated) documentation or with code that breaks unexpectedly, sometimes even in production.

Note that Rust has the same issue, any method can panic and allocation may just fail at some point. There are very few ways good ways to handle those problems correctly, which is why this "everything may kill your program" approach is often criticised.

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

#82

Post by ntonozzi »

richardwhiuk wrote: post #72
zeroxfe wrote: post #37

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…

Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.

Go belongs in the exact same bucket as Java and C#.

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

#83

Post by synergy20 »

pjmlp wrote: post #62
synergy20 wrote: post #51

Maybe nowadays we should all use glue-script + compiled-ffi to iterate fast while keep performance under control? e.g python+cffi, or python+pyo3(for rust), or even lua+capi? do we really need code everything in compiled language these days? the cold path can be dealt with by scripting languages, and let the c/c++/rust/etc to handle the performance critical path instead.

Nowadays? That is how AOLServer used to be, and all the other scripting languages developed as Apache plugins, back in the 2000's .com wave, like mod_perl and PHP.

Maybe scripting language was overused down the road? i.e. to use it for everything, and use them like a compiled language(ruby in rails, php framework, django,etc) that made things slow?

point here is that to restrict script languages to glue logic for the most part, and always remember to use ffi for heavy lifting, not sure how to balance both yet.

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

#85

Post by CharlieDigital »

packetlost wrote: post #78
CharlieDigital wrote: post #66

Earlier quoted context omitted.

> I believe that Rust is a fabulous language for early prototypes. The problem is that TypeScript is an even better language for early prototypes. zeroxfe has the right answer: > If your answer is something like Go or Node.js, then Rust is probably not the right choice. > If your answer is C or C++ or something similar, then Rust is very likely the right choice. The only reason one would choose Rust over TypeScript i…

I think it depends on what you're doing. I'd argue statically typed Python (ie. with type hints) is also good for an early-prototype language and has the benefit of being able to swap out parts at a time via C FFI with Rust or something like PyO3. Pypy with asyncio (so FastAPI?) is what I'd choose for a web framework these days, personally.

I agree; Python is a great choice especially if whatever you're building is heavy in math and/or ML. The ecosystem is just better so it makes sense then to build your backend stack with Python.

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

#86

Post by jakswa »

I remember reading about PropelAuth somewhere and thinking that Rust might slow down development -- something I wanted to be proven wrong about since I've been learning rust off and on, and like some things about it. It seems it's ending up up a mixed bag, and the negatives in the bag are still light enough that you're carrying it forward. Thank you for this blog post!

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

#87

Post by dgb23 »

unshavedyak wrote: post #29

So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what you and your team is most comfortable in. Avoiding allocations in Rust, on purpose, and being uncomfortable with how to solve design challenges caused by hyper optimizing your code .. is not a Rust problem. Or an any language problem. Rust gave you rope and yo…

> Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages.

I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.

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

#88

Post by galangalalgol »

ntonozzi wrote: post #82
richardwhiuk wrote: post #72

Earlier quoted context omitted.

Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.

Go belongs in the exact same bucket as Java and C#.

C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose

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

#89

Post by dhbradshaw »

We have a fairly complex app with a front end in Typescript and a back end in Rust backed by Postgres on AWS.

My favorite part of the job is coding in Rust and we do a lot of cool things in that backend code. Unfortunately, most often the Rust code is the fastest and easiest part of a change, which means that I spend most of my time solving problems either on the front end with Typescript or on CI and infra type things rather than the Rust part.

It's a bit sad: if something just works, you spend less time on it than on the hairier things.

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

#90

Post by hinkley »

rom-antics wrote: post #28
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.

The mistake was not "explicit errors". It was having a mix of error types, some explicit and some implicit, with no convenient way to combine them, plus the interface complications. Note that most newer languages are choosing explicit errors. This includes at least Go, Rust, Swift, Zig, and Odin.

The second mistake was only flirting with Bertrand Meyer’s work until the Gang of Four showed up and wrecked Java forever.

Meyer + functional core nets you a great deal of code with no exception declarations and an easy path for unit tests. If it hurts to do stuff it might not be the language that sucks, it might be you. Pain is information. Adapt.

Post reply on HN