Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?
I'm not sure all things are ever equal, but I would choose Rust.
I love building a startup in Rust but wouldn't pick it again
131–140 of 496 posts
Re: I love building a startup in Rust but wouldn't pick it again
#132Re: I love building a startup in Rust but wouldn't pick it again
#133Earlier quoted context omitted.
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 unexpectedl…
Don't get me started on Java and checked exceptions. If you don't have checked exceptions, you should not have a million try/catch blocks. In fact, just the opposite. Since you only care about errors when you can retry (or ignore) you should only have a small number of try/catch blocks. Ideally one or none.
My best example of this is a UI application that I built that had a single try/catch block around the event loop. It just displayed the error message to the user and returned to the event loop. If they tried to save a file to a network and failed, they got the message, and could just hit save again for somewhere else. No other code needed.
Re: I love building a startup in Rust but wouldn't pick it again
#134Question for HN, all things being equal (you are not more familiar with one language/framework) what language would you choose to build a startup in?
Java or .NET
Re: I love building a startup in Rust but wouldn't pick it again
#135Earlier quoted context omitted.
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…
If I am in the business of writing robust code; then "assuming all functions can throw" means at the very least forcing every function call to be surrounded by a try/catch block? It almost always make sense to handle an error locally if you can; for example if I want to retry the operation (let's say I'm writing a distributed database client), it may make sense for me to retry another node rather than unwinding to th…
> If I am in the business of writing robust code; then "assuming all functions can throw" means at the very least forcing every function call to be surrounded by a try/catch block?
No, absolutely not! You only care about errors where you can retry/ignore or log and terminate so you only have try/catch in those areas. So maybe one or two.
Re: I love building a startup in Rust but wouldn't pick it again
#136Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how yo…
Steve, I just want to say I like you a lot. :)
Re: I love building a startup in Rust but wouldn't pick it again
#137Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how yo…
Steve, I just want to say I like you a lot. :)
Thanks, that's very kind.
Re: I love building a startup in Rust but wouldn't pick it again
#138Earlier quoted context omitted.
> 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.
> It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust…
> your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java
Python very likely, Node probably too, not sure. I doubt it's true for the others. My guess is you're going to use less resources (memory etc.) but you're not going to beat their runtimes with hand-rolled GC (ref counting) and allocations all over the place.
Re: I love building a startup in Rust but wouldn't pick it again
#139If 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…
Rust is a high development cost compared to node.js python or julia, but I'd say it is about the same as go or c#. Maybe a little better than all of those if you consider time getting test coverage. But if you are prototyping you probably aren't doing that. I'd say rust is a much lower development cost than c++ or java.
Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.
Re: I love building a startup in Rust but wouldn't pick it again
#140Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how yo…
Tangram Vision [0] is also a startup and we also use Rust. We're using it to develop robotic / autonomous sensor calibration tools that would normally be written in a variety of C / C++ libraries.
For context: most if not all of our team has developed calibration tooling similar to what we're doing now in the past, just at different startups and very specific to certain robotic or sensing configurations.
If anything, once we got CI sorted and started using our own internal registry I would argue that we are significantly faster in terms of iteration time. This is partly because the team is small, but also because most of our tooling is consistent and easy to keep in lockstep. Pulling libraries is done uniformly across platforms and architectures, and our CI runs (through GitLab) stay up-to-date with the latest tooling without issue. Having a stronger type system to detect errors early and a compiler that actually tries to give human-readable messages (looking at you C++ linker errors) using that type system makes everything so much easier.
Compile time seems like it would be an obvious bit that slows one down, but in practice sccache [1] does what it ought to and we barely notice it (at least, I don't and I haven't seen team members complaining about build times). Mostly I'd argue that the real thing holding us back is tooling extant to the rest of the wider Rust ecosystem. Debugging and perf tools are great in Unix land, but if you're making anything cross-platform you need to know more than just perf. That might just be my opinion though, I'll admit I'm still learning how best to apply BPF-based tooling even in Linux alone.
I also realize I'm responding to steveklabnik, so I suspect most of what I'm saying is well-known and that this comment is really more directed at TFA.