Live data from Hacker News

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

propelauth.com

331–340 of 496 posts

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

#331

Earlier quoted context omitted.

Arguing about icache utilization is a little silly here - the code will be laid out for you as though the branches are not taken (or you should force it to do so). In that case, the only "waste" of icache is the CMP and JMP, an additional 4-8 bytes per return, and literally 0 cycles. When you do take an error, each RET takes you 1 cycle, plus the 10-15 cycle mispredict for the CMP+JMP because there's a stack engine i…

The checks you're talking about are duplicated more or less per statement in some types of code. Every single call site ends up with an `if err != nil` or moral equivalent. It can add up, also consider the extra register pressure. The return values aren't valuable anymore, they're just error signalling. The compiler doesn't necessarily know what your error types are, it can try to use heuristics to move those blocks…

There's no register pressure - TEST EAX, EAX (or CMP, EAX, $0) // JNZ $ERROR_HANDLER is the instruction sequence we're talking about. Most error types are enums where 0 = "good" and any nonzero value is not good. This is the inverse of the "null pointer check" in C. It consumes no registers and a negligible number of code bytes.

There is obviously a sparsity of exceptional cases where error-handling code like this is worse than using exceptions. I would claim that it's a lot more sparse than you think. Many people use exceptions for things like "file not found" or "function failed for whatever reason," (my favorite) "timeout," or "bad input from the user." These cases are often not that exceptional!

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

#332

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…

Heh heh, well maybe in some cases but since TS/JS is kinda the lowest common denominator in web development, it's just the most convenient choice. We humans are limited in our capacity to learn and take time to get good at things. So it makes a lot of sense to pick a tool that can be used to build the whole app with.

And for all of its faults, NodeJS can be fun compared to something like Java which feels more like doing taxes. Maybe it's the danger. Maybe it's the fact there are so many packages and libraries out there - everyone can contribute! Who knows, but I won't waste my time learning say Rails just to use a "better" backend framework. It's good enough even though I know better. There are way more important things.

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

#333
post #77

It's great when wanting to play with cool new technology combines with implementing a viable product to sell to customers. But those two things don't necessarily go together. Quite often they are at odds with each other, and then you have to pick one or the other: either we spend resources playing with cool technology, or deliver a product customers will buy. Neither is wrong if it's your own resources, it's just imp…

Exactly. "Rust wasn't the right choice because we spent too much time and resources playing with it." is not an argument against Rust. It's an argument against learning a new technology while looking for PMF. There's nothing inherent about Rust that makes it a poor choice to build a first iteration of a product with.

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

#334

My biggest pain point with Rust (in a startup context) is that Rust works really well, until you get to anything related to threading or async. Yes, the claim is "fearless concurrency" but you'll still deadlocking mutexes and once you're heavily into async you need to start using language constructs that feel REALLY awkward, like pinning, runtime checks like RefCell, and so on. IMO if Rust could make that whole aspec…

I honestly think Swift nailed it. Swift's async/await is a pleasure to work with and has the required language/runtime/stdlib support to feel natural and empowering instead of ridiculous and suffocating.

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

#335

Earlier quoted context omitted.

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…

> With Rust, I've found even very experienced C++ folks have a long ramp-up period I've found C++ folks especially have the hardest time with Rust, because they approach it using C++ idioms and habits, then get frustrated when they can't do things the way they're used to. I've had better success teaching Java people Rust. They find it much easier to learn than C++, and I can get them writing idiomatic Rust code quick…

I think everybody has a hard time starting with Rust.

Even when you get confident it is still a longer process writing code than C/C++. It makes you think very hard about what you do carelessly in C.

But having spent the last few years debugging a lot of Swift code, and a bit of Rust code, that time is worth it I say.

Where Rust shines is in the debug cycle. Less of it.

Once you learn to surrender to the compiler, you will find true bliss,....

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

#336
post #330

Earlier quoted context omitted.

Rust does a bit more on the safety front than typical programming languages.

Really? I guess if your typical programming languages are C and C++. Otherwise Rust just has semantics that allow more control over memory, as is often needed in lower level programs, while preventing pointer aliasing. The majority of languages in existence are memory safe--some even more so than Rust. They're just not as flexible.

It's much better than Java, Kotlin and C#.

The borrow checker detects the majority (~95%) of concurrency problems. We don't have that many single core CPUs lying around anymore.

It's got a story on high performance, high concurrency programs which is significantly better than anything else I've seen so far.

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

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

> 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. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess o…

> 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++."

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

#338

Earlier quoted context omitted.

In theory, I like exceptions. In practice, I hate them. Few languages statically check exception handling - e.g. Java, and even then only partially - leading to stability-ruining edge cases leaking into production in the most unexpected of places caught only by QA if you're lucky. Exception handling codegen can also be rather atrocious, leading to unavoidable performance degredation when third party middleware throws…

See https://gen5.info/q/2008/07/31/stop-catching-exceptions/ and https://gen5.info/q/2008/08/27/what-do-you-do-when-youve-cau... It's very important to minimize the burden of handling errors in code with simple control flow. Frequently I see people try very hard to handle errors with monads in languages like Scala at the micro level and they are so burned out by this that they don't put any effort into handling error…

Micro and macro are both important.

I've built crash collection and deduplication systems, I've heard of triage that helps discount crashes generated by hardware failures or overeager overclocking. I've collected telemetry and setup symbol servers and source indexing to streamline bug squishing, and helped build systems which verify game content up-front to discover even non-code bugs before they're shipped to users, and to properly attribute said errors to the content that generated said errors in an easily navigatable and fixable way. I've helped engineer error-tollerant systems that won't require handholding by engineering to recover from bugs. Plenty of focus on the macro.

But all it takes is a single uncaught exception slipping past QA to cause one to consider a recall of physical product, even in this era of ubiquitous internet, for a handheld console game for something as trivial as a missing or corrupt sound effect. If things at the micro level are neglected too much, and nothing you do at the macro level can really mitigate that in a sane manner... except use tools that check you're doing things right at the micro level. And I have yet to see exceptions handle that micro level particularly well.

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

#339
post #319

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…

Pick a problem, not a tool first. Unless you're more interested in the tool than the problem, then it's fine. I don't love Rust, but I can get by. TS+NodeJS is okay. But I'm more interested in the problems that I'm solving so I just use whatever is the most suited.

Yes. I cringe a little getting emails from startup recruiters saying "join a Rust startup." As if the success of their business hinges on using Rust for something that probably doesn't need it.

I've found that the basic NodeJS or Python works for most problems I've chosen. Not even with strong typing.

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

#340
post #234

Crazy to think that cloud credits, in addition to distorting the hosting competition, might also distort the language choice competition…

The first hit of cloud is free but once they have you hooked they charge an arm and a leg afterwards.
Post reply on HN