18 ms·
I asked the same question and imagined a snarky response like "Well whenever you want a fast, memory-safe api." But seriously, I don't know. It seems like it t
by nonethewiser 3y ago
I asked the same question and imagined a snarky response like "Well whenever you want a fast, memory-safe api."
But seriously, I don't know. It seems like it trades development speed for things that just aren't problems. I think the database would be where most performance issues would surface, not the api server. I'm curious how others will answer your question though because I'm not really sure.
- hu3 3y agoEven when performance is important, C# and Java are top performers: https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21 Heck people use some incantations of Java for High Frequency Trading even. Besides, web application bottleneck is usually the database.
- riquito 3y agoWhat you write and what's in the results you linked tells quite a different story (composite scores)
- hu3 3y agoAre we looking at the same thing? https://i.imgur.com/blA0Oi4.png https://i.imgur.com/blA0Oi4.png
- riquito 3y agoPerhaps I misinterpreted what you said as "Even when performance is important, C# and Java are top performers". I read it as "they are the top performers", and there are faster rust frameworks in that benchmark, but perhaps you meant "Among the top performers there are non-rust language which are good options without having to use rust"
- hu3 3y agoInterestingly, the fastest in that benchmark, above Rust, C++, Java and C# is... JavaScript. Goes to show how benchmark minigames are broken and also that most languages are good enough.
- shpongled 3y agoThere is some trade-off in development speed, but I think it's outweighed by the productivity gains from a great static type system and language that is relatively free of footguns. I have built several APIs with Rust + Axum + Sqlx. I get statically typed SQL queries, rock-solid performance, easy to deploy. Most of these APIs also interface with AWS stuff at some point, and the Rust SDK is just phenomenal to use. But I also love Rust. I've been writing it for 6 years now, and I am more productive in Rust than any other language (for non-trivial projects). I can write up an API faster in Rust than in Django, because I don't have to spend time digging through configuration files or installing plugins and reading arcane documentation to do what I want. The above stack in Rust is incredibly simple.
- Dowwie 3y agoWhat are you doing for partially updated resources? Also, have you written your own dynamic query building logic yet? That's the path one eventually winds up taking with parameterized sql libraries.
- shpongled 3y agoEither do a patch with a new struct, or do full updates (what I typically do). I have a few dynamic queries, but for the most what I'm doing is relatively straightforward. I still prefer this over using an ORM, personally.
- Dowwie 3y agoWhen you partially update a table record, you need to determine which columns you want to update and prepare them as parameters, only including those that need to be changed. This is straightforward work for an ORM and/or query builder but not parameterized SQL. What does your implementation look like, as I can't follow your explanation. I found that both the parameterized SQL and ORM/QB have an important role to play due to the partial updates and occasionally query building exercise. None is ideal for every situation.
- 3y ago
- rapsey 3y agoHonestly it does not really trade development speed IMO. The constraints it imposes pay dividends. Do you write code once and forget it? Or do you often change what your code is doing or how it is structured? Because those changes tend to bring out the most bugs. The type system will really help you with any refactorings. I've done some huge changes to the entire structure of my apps and once it compiles had zero issues. It just worked from first run. Do you find performance problems in production? How much time is spent on those? If you're in Python/Ruby/Erlang land that can be a huge chunk of your time. A Rust solution is going to be memory and cpu efficient by default. Unless you are really in extreme performance land you are likely not going to need to bother with this at all. How about problems with deployment or dependency management. The output of rust is an executable more or less self contained. The package management is superb.
- dlisboa 3y agoThere should be a lot more focus on "total cost of ownership" of Ruby/Python/JavaScript. Yes, it is faster to develop initially, but after N years and an established product that development speed gets outweighed by other requirements: how easy is it to refactor confidently? How much does it cost to run? How complicated is the deployment? Does it scale? Not to mention many of the reasons why it's faster to write is because you're punting on handling important issues: can I pass this to that function? Is this a valid state for this variable? Is this data validated? A language like Rust might bog you down at first because it'll require you to do all of that before you get off the ground. But I'd be willing to bet that, if you factor in the whole cost for N years, it'll eventually turn out cheaper. And if you have experience in it it might not even really slow you down. Many would say "yeah but you have to survive N years", and maybe I've just been lucky but most of the products I've worked on have been profitable and successful. In all of them we reached the point where it just wasn't as fast to develop anymore, and now the application was very expensive to run, slow to change and filled with nagging bugs.