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

491–496 of 496 posts

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

#491

Post by satvikpendem »

jossclimb wrote: post #344
weavie wrote: post #32

I've been writing Rust professionally for a few years now and if there's one thing I've learned it's that if you ever write a function that takes a parameter of `impl Fn(&Vec ) -> &'a str` you are going to be in for some pain. Just make it `impl Fn(&Vec ) -> String`. It is highly unlikely that the extra allocation is ever going to be noticed in the performance. Just because Rust pretty much forces you to be explicit…

A lot of programmers will look at '`impl Fn(&Vec ) -> &'a str`' and think what the hell is that, alien hieroglyphics?

Same for APL, Perl, Lisp, Haskell and many others, or even C with multiple (double or triple) pointers and C++ with many pointer types.

At the end of the day, you can't understand a language without, well, learning it.

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

#492

Post by Patrickmi »

jmmv wrote: post #428
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…

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the…

[dead]

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

#493

Post by kazinator »

nequo wrote: post #424
jossclimb wrote: post #344

Earlier quoted context omitted.

A lot of programmers will look at '`impl Fn(&Vec ) -> &'a str`' and think what the hell is that, alien hieroglyphics?

Loosely speaking, it’s a type signature for a function that 1. takes an immutable reference to a vector of strings and 2. returns an immutable reference to a string, 3. with the constraint that the strings in the input vector must not be freed before the result is freed. It’s a reasonably concise way of saying all that.

I'm pretty sure I never want to have anything to do with any of these concepts, no matter the syntax.

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

#494

Post by drogus »

jmaker wrote: post #435
jmmv wrote: post #428

Earlier quoted context omitted.

On the contrary. I’ve been recently writing a web service in Go… and omg what a terrible experience. Sure, I could prototype something very quickly, but now it’s almost impossible to refactor any of it without introducing subtle breakage. And it’s sooooo verbose and redundant and fragile. I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the…

Quite the opposite here. Go is very easy to refactor if need be. What kind “breakages” are you talking about? Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go. In Go you have a garbage collector, no need for the borrow checker or reference counting on your side. What unexpected nil pointers or zeros? It’s all easy and straightforward in Go. If you’re referring to the handling of materialized…

> Go being “verbose”? Or “fragile”? I doubt we’re talking about the same Go.

Maybe compared to C, Go is quite concise, but Go is nowhere near Rust's level of expressiveness, especially with poor generics support, much more verbose error handling etc.

> no need for the borrow checker or reference counting on your side.

I think that people that mention borrow checker in context of backend dev haven't done much backend dev in Rust. The nature of a web backend is to (most of the time) get data from the client, process, return a response. In this context you very rarely have to think about borrow checker and almost never use explicit lifetimes.

> What unexpected nil pointers or zeros? It’s all easy and straightforward in Go

If you forget to initialize a struct, you may end up with a nil pointer and you might not catch it until runtime.

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

#495

Post by drogus »

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…

Most of the posts mentioning Rust not being the best choicce for a startup talk about iteration speed and prototyping. In that light I don't think this is the best heuristic. If you need to prototype quickly and search for a market fit, then by all means, choose whatever will make you go fastest (and I'd argue for a lot of use cases it would be Elixir with Phoenix's LiveView if you don't absolutely need an SPA or a mobile app), but if you're building sth that already has a market, Rust might be still a good choice even if it's not a C/C++ fit.

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

#496

Post by [deleted] »

kazinator wrote: post #493
nequo wrote: post #424

Earlier quoted context omitted.

Loosely speaking, it’s a type signature for a function that 1. takes an immutable reference to a vector of strings and 2. returns an immutable reference to a string, 3. with the constraint that the strings in the input vector must not be freed before the result is freed. It’s a reasonably concise way of saying all that.

I'm pretty sure I never want to have anything to do with any of these concepts, no matter the syntax.

[deleted]
Post reply on HN