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

361–370 of 496 posts

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

#361

Post by cultofmetatron »

Reading this makes me reaffirm my decision to build my startup in elixir. At the time, it came down to 3 compelling choices

1. typescript - I already had 6 years of full stack js experience. The ecosystemis full of issues but its all issues I'm used to. 2. rust - new kid on the block. the type system and speed were compelling but it was still being developed and the learning curve was brutal. Plus I was under the gun to get the mvp up. we needed to get a working piece of software up and test out business assumptions.

In the end I went with elixir. Realtime sync was a huge killer feature we were aiming for and phoenix came with the best out of the box support for it. Overall productivity was on par with javascript while the functional aspects made certain types of bugs non issues in elixir. runtime performance has been more that adequate. after 3 years in production, we have only recently rolled out rate limiting and caching and only as a precaution as we've been expanding quickly.

Echoing the author's sentiments, I can definitely see places where rust could be better and thanks to tools like rustler, we'll be able to bring those in piecemeal as needed.

I'm sure our product would be even faster and more efficient on resources if we did it in rust but I'm pretty sure we would have more likely run out of runway before that happenned.

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

#362

Post by steveklabnik »

pdimitar wrote: post #312
steveklabnik wrote: post #228

Earlier quoted context omitted.

esteban of course gave you an excellent response already, but just another bit of like, context here: while it may not be on rustc, the developers want to go beyond the norm here. rustc understands if you write async/await syntax like JavaScript, and then directly proposes that you switch to the Rust syntax: pub async fn foo() -> i32 { unimplemented(); } pub async fn bar() { let f = await foo(); } gives error: incorr…

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 therefore it’s more valuable than an obscure issue only one person sees.

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

#363

Post by auno »

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…

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

If you bend over far enough backwards, and squint a bit, you can kind of do that...

    interface Runner {
      public void run() throws E;
    }

    class Test {
      public static > void test(T runner) throws E {
        runner.run();
      }
    }
It compiles. I haven't tried running it though.

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

#364

Post by Klonoar »

Animats wrote: post #237
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…

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

>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 over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

The thing here is that most web backends are basic CRUD bullshit, and you fundamentally will not hit the thread/async distinction, nor need to care about whether there's garbage collection or not. Microsoft has used actix-web in production as far as I know, it's not like the Rust web stack isn't battle tested.

>Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time.

These are all the things that sit adjacent to a web framework, and once you step outside that CRUD happy path, Rust fits very well - and in this case just "bolts on".

>It's not that useful for phone apps.

This is more tangential but I know of more than a few companies who have written or are writing their cross-platform logic in Rust instead of C++. This is really akin to how some projects back Python modules with Rust: it's easy to have it backing things and it beats the hell out of dealing with C++.

And look, I'm not even saying don't use Go/Python/JS/. You do you, your startup will live or die by so many other things than choice of programming language.

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

#365

Post by hot_gril »

Animats wrote: post #351
hot_gril wrote: post #337

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.

These aren't high-volume, they're just web interfaces used internally by hundreds of people. Golang wasn't well-received either in our dept. Java would've saved us a lot of headache, a phrase I never thought I'd say; adjacent teams use it for similar things.

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

#366

Post by jiggawatts »

veqq wrote: post #194
saurik wrote: post #164

Earlier quoted context omitted.

That's the problem, though, right? 99.999% of the time you absolutely should not be "handling" an error: you should merely propagate it so it gets closer to code that has actual intent. Languages that force you to try to "handle" errors--which includes Java, due to their botched concept of checked exceptions--both encourage the wrong behavior in the developer and cause the code to be littered with boilerplate to impl…

> you absolutely should not be "handling" an error: you should merely propagate it so it gets closer to code that has actual intent Why?! There are 2 types of errors: - an error in your program logic, which you need to fix - an error from something out of your control (network down, disc errors, faulty input... Which you certainly must handle What's the alternative? Let errors trigger undefined behavior and corrupt y…

Exceptions are not "undefined" behaviour, and they don't "corrupt the database". On the contrary, they're very often used to abort database transactions cleanly, even in complex chains of deeply nested function calls.

What people mean by "not handling errors" is that the Visual Basic style of "On Error Resume Next" is a terrible, terrible thing to do. The equivalent in modern languages is a try-catch block in the middle of a stack of function calls 200 deep. That function likely has no idea what the context before it is. Is it being called from a CLI? A kernel module? A web server? Who knows!

Just yesterday I had to deal with legacy code that made this mistake, and now it's going to cause a multi-day problem for several people.

It's a ASP.NET HTTP authentication module that simply swallows exceptions during authentication (e.g.: "Can't decrypt cookie"), doing essentially nothing. When deployed "wrong" (e.g.: encryption key is invalid) it just gets stuck in a redirect loop. The authentication redirects back with a cookie, it is silently ignored, then it redirects to the authentication page which already has a cookie so it redirects back, and so on.

There is nothing in the logs. No exceptions bubble up to the APM or the log analytics systems. The result is HTTP 200 OK as far as the eye can see, but the entire app is broken and we don't even know where or why exactly.

That's not even mentioning the security risks of silently discarding authentication-related errors!

This is what people mean by don't "handle" errors. Middleware or random libraries should never catch exceptions. It's fine if they wrap a large variety of exception types in a better type, but even then it is important to preserve the inner exception for troubleshooting.

I've had to tell every developer this that I've worked with recently as a cloud engineer. Stop trying to be "nice" by catching exceptions. Exceptions are not nice by definition and ignoring that reality won't help anyone.

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

#367

Post by ReflectedImage »

tcfhgj wrote: post #316
ReflectedImage wrote: post #298

Earlier quoted context omitted.

Well Python code will on average will be more correct than Rust code. I'm not sure why you feel Rust code would be more correct than Python code but it certainly isn't true.

I strongly believe that if I would code anything significant my Rust could would be more correct. The reasons are types and rusts multi threading guarantees, which become even more helpful when doing refactorings

It won't because the number #1 factor in bugs is the number of lines. The Python code will be significantly shorter and thus contain less bugs.

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

#368

Post by Frog0fWar »

Animats wrote: post #351
hot_gril wrote: post #337

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.

Another (maybe even more) important motivation was to have simple, statically-typed language so that new hires can contribute to the codebase faster and the code itself is more standardized and easier to maintain at large scale.

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

#369

Post by steveklabnik »

dcow wrote: post #353
ReflectedImage wrote: post #336

Earlier quoted context omitted.

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.

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.

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

#370

Post by faitswulff »

steveklabnik wrote: post #360
faitswulff wrote: post #359

Earlier quoted context omitted.

Do you mind my asking what frameworks you're using in Rust on the backend, if any?

We ended up building one https://crates.io/crates/dropshot Happy to talk about anything!

Oh this supports OpenAPI! That's exciting. I'll definitely check this out when I have a chance. Thanks!
Post reply on HN