Die hard rust fans often minimize the very real developer difficulty incurred by their language of choice. Even major library maintainers in rust have criticisms of various language features because of their difficulty to use. These are real and substantiative concerns that would affect any development team not made of expert rustaceans. Just look at basic dynamic programming implementations in a normal language versus rust for say popular leap code questions and you'll see the difference in basic developer productivity.
I love building a startup in Rust but wouldn't pick it again
61–70 of 496 posts
Re: I love building a startup in Rust but wouldn't pick it again
#62Maybe nowadays we should all use glue-script + compiled-ffi to iterate fast while keep performance under control? e.g python+cffi, or python+pyo3(for rust), or even lua+capi? do we really need code everything in compiled language these days? the cold path can be dealt with by scripting languages, and let the c/c++/rust/etc to handle the performance critical path instead.
Nowadays?
That is how AOLServer used to be, and all the other scripting languages developed as Apache plugins, back in the 2000's .com wave, like mod_perl and PHP.
Re: I love building a startup in Rust but wouldn't pick it again
#63Earlier quoted context omitted.
I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
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.
We are in the distributed systems age. If systems are composable, operations can fail for reasons that are completely unfathomable to the client. It's not reasonable to have a SharkBitTheOpticFiberCableException and 100,000 other ones that handle every reason why an operation failed.
What the client should know is how an error affects what it is doing, it wants answers to questions like
* Is it likely this error will recur if I retry immediately? in 1 minute? in 1 day?
* What is the scope of this error? Does it affect the entire system? Does it affect a particular database record?
* What do I tell the user?
* What do I tell the system administrator?
Re: I love building a startup in Rust but wouldn't pick it again
#64I'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…
You can still return the str reference; callers can easily do the copy if they need while allowing for zero-copy for simpler usages.
Re: I love building a startup in Rust but wouldn't pick it again
#65Oxide 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 you develop evidence, of course…
Re: I love building a startup in Rust but wouldn't pick it again
#66I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I…
> I believe that Rust is a fabulous language for early prototypes.
The problem is that TypeScript is an even better language for early prototypes.
zeroxfe has the right answer:
> 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.
The only reason one would choose Rust over TypeScript is if one would have chosen C/C++ instead.
Then if you need higher perf/throughput: Go, Java, and C# in particular are all options that I'd consider before C/C++ or Rust. C# in particular is highly congruous to TypeScript [0].
JavaScript, TypeScript, and C# have been converging, IMO (and that's a good thing). Seems really natural that if you're a startup finding PMF, start with TypeScript for iteration speed. If you need higher throughput, C# is a stone's throw away from TypeScript syntactically and it's pretty easy to hire for (compared to Rust). [1]
Pick Rust if you're building something highly performance and memory sensitive. Pick TypeScript and C#/Go/Java for almost all other cases.
[0] https://github.com/CharlieDigital/js-ts-csharp
[1] https://raw.githubusercontent.com/CharlieDigital/js-ts-cshar...
Re: I love building a startup in Rust but wouldn't pick it again
#67If you are writing high performance code use Rust. (Slow development times, high performance) If you are writing a typical business application use Python. (Fast development times, low performance) Or if you want to be clever do a hybrid of both. Create Rust modules for your Python code. This is just about selecting the right tool for the right job.
I would rephrase it as follows,
If you are writing high performance code where a tracing GC isn't an option, and there are SDKs available use Rust.
Otherwise an AOT compiled language is a better option, and if not, and there are only C and C++ SDKs available, also factor in the development cost of creating wrappers in Rust, before doing the actual development activities.
If there is too much money being burned in wrapper libraries, maybe that isn't the best option as well.
Re: I love building a startup in Rust but wouldn't pick it again
#68This is something I hear a lot from other founders. Spinup time of new engineers is like 6mo+, some devs who can churn out normal CRUD product work just fine in Rails or React ~never become productive with Rust, and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply).
> and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply). Sidenote, we hire Rust at a small shop (~30 devs?). Ironically i've found it _easier_ to hire for Rust. You're totally not wrong, BUT, the quality of the candidates that apply is quite high in our experience. I suspect it's because we get a lot of passionate people. We don't have…
> With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience.
Being young and cheap is a good quality, I suppose. Experience is overrated.
Re: I love building a startup in Rust but wouldn't pick it again
#69Question 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 platforms, hardly anything else comes close in languages, tooling and libraries.
Re: I love building a startup in Rust but wouldn't pick it again
#70Earlier quoted context omitted.
I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
I get where you are coming from, but imagine if every other "to the human" process description we had was done this way. I actually think this would be a fun one. How to make scrambled eggs, but where all failure cases are covered. Would be the "Hal fixes a lightbulb" in prose.
That gets to the original promise of computers, doesn't it? That they'd perform repetitive tasks quickly and reliably.
Meanwhile, every time I make scrambled eggs, there is a small but very real chance that my house burns down. And we accept this because to err is human.