Live data from Hacker News

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

propelauth.com

391–400 of 496 posts

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

#391

Earlier quoted context omitted.

I'd prefer something with a more sound type system, and something that makes cleaning up resources easier and more ergonomic. This might help with cleanup: https://github.com/tc39/proposal-explicit-resource-managemen... But I'm not sure anything will help with the type system. For example, this drives me absolutely insane: https://www.typescriptlang.org/play#code/MYewdgziA2CmB00QHMA...

> makes cleaning up resources easier I've never really had a problem with it, but I isolate such resources behind a wrapper, which makes cleanup easy. I just create a little higher-order function: function doSomethingThatNeedsCleanup(fn) { const thing = createTheThing(); try { return fn(thing); } finally { cleanUpTheThing(thing); } } > this drives me absolutely insane (console.log(["10", "10", "10"].map(parseInt) out…

> So parseInt coincidentally matches the signature Array.map() is looking for.

If that were true I'd not mind quite as much... but actually, parseInt takes two parameters and map passes three.

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

#392

Earlier quoted context omitted.

Check sibling reply. Sadly I never wrote those down. :( I'll definitely do so going forward. The problem is with that is the impostor syndrome: I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive. But your messages help. I'll just write those down and send them to GitHub's issue list.

I’m not working on Rust anymore, but the previous stated position on this, which as far as I know is still the case, is that if it’s confusing, you should file. Worst case scenario is “sort we can’t fix that” but it’s not an imposition to file issues. More is better. Because exactly as Esteban said, information is valuable. Even duplicates are valuable: they indicate that more than one person has run into this, and t…

I can confirm all of this is still the case.

> I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive.

It doesn't make a difference. The compiler can't assume any level of proficiency. If a topic requires you to read the docs, it should tell you so. There are some "basic" things it relies on, but for anyone with any level of experience programming should be able to read a diagnostic and either understand it outright or have enough clues about what to search for. So "this error is confusing because I didn't read chapter N of The Book" can be simplified to "this error is confusing."

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

#393

Earlier quoted context omitted.

> If you're building web backends, Rust is not a good choice This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."

Google developed Go specifically so they didn't have to use C++ in high-volume web backends, which is what they did previously.

Google absolutely uses lots of C++ in high-volume web backends today. Go didn't replace it.

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

#394

Earlier quoted context omitted.

I’m not working on Rust anymore, but the previous stated position on this, which as far as I know is still the case, is that if it’s confusing, you should file. Worst case scenario is “sort we can’t fix that” but it’s not an imposition to file issues. More is better. Because exactly as Esteban said, information is valuable. Even duplicates are valuable: they indicate that more than one person has run into this, and t…

I can confirm all of this is still the case. > I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive. It doesn't make a difference. The compiler can't assume any level of proficiency. If a topic requires you to read the docs, it should tell you so. There are some "basic" things it relies on, but for anyone with any level of experien…

Excellent. Keep up the good work, I (and others) appreciate it.

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

#395
> We have extractors for different user requirements to make adding APIs very straightforward. We have middleware for scoping requests per customer. In most languages, this is pretty standard, but in Rust, for our use case, they both require at least a rough understanding of pinning.

This is more about "async Rust" and the way that the most common web frameworks for Rust are utilizing it. It should be totally possible to write much easier to understand frameworks and code - potentially with the limitation of using a classical thread per request architecture which avoids most of the async/lifetime/pinning pitfalls. The main drawback seems that such frameworks seem out of favor in Rust and thereby not available or not very well maintained.

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

#396
post #353

Earlier quoted context omitted.

I'll give you that. The reason I questioned is because in my experience with those languages the 95% problem is not the actual data consistency rather it's locking and synchronization hell that results from needing to make your program threadsafe to ensure data consistency. Rust says, don't get yourself in a situations where you need to do that in the first place, it's not safe. Just clone the data or leak it read on…

It has been a very long time since I’ve used Java. Rust will tell you where you need the locks, at compile time. Does Java? Serious question.

Not since I’ve use it either. I may be missing something since I’ve only used async Rust, in what way does Rust say “you need a lock here”? If it does that then I stand corrected and I may just have to drop async Rust altogether and checkout crossbeam + rayon that everyone raves about.

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

#397

Earlier quoted context omitted.

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe a…

If you don't need bare metal something like Scala or koitlin will fit. Scala is extremely expressful and does CRUD very well

Scala is on my list of languages to try. I'm usually not a fan of large runtimes or too many abstractions from the OS, but I do want to give it a fair shake. F# too.

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

#398
post #297

Earlier quoted context omitted.

It does matter if you're using cloud autoscaling FaaS (previously known as CGI) and paying for those HTTP responses by the microsecond (and by RAM usage as well, which is also typically quite low in Rust).

Not really, the connection won't close until you are done sending it all and have received the relevant TCP ACK messages from the other sides. Being on autoscaling FAAS or not does not matter for that. In any case, if you are trying to optimize microsecond usage in AWS lambda I hope you have a truly gargantuan amount of traffic and/or have incredibly cheap engineers or the money saved will barely match up to the cost…

So here's a real-world case of where this actually does matter:

https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w...

two minor follow-ups on that as well:

* https://andre.arko.net/2019/01/11/parsing-logs-faster-with-r...

* https://andre.arko.net/2022/03/13/parsing-logs-faster-with-r...

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

#399
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…

I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe a…

OCaml with tooling and an ecosystem from the size of Go would be an ideal. Java and C# can more and more be written like MLs too.

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

#400

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…

Node runs circles around Django/Rails, and batteries included in Javascript tend to be pushed to either the frontend or the database. Node backend tends to be thinner, compared to Java/Django/Rails. Some people don't know any better, some have good reasons of doing this.
Post reply on HN