The same can be said about Rust: its popularity exceeds its scope, because 99% of applications I see that are written in Rust are better off written in a GCed language.
Except when you actually enjoy things being fast. For example, HTTPie easily adds 0.5-1s delay to every request because it's written in Python, especially on the first invocation. xh (https://github.com/ducaale/xh), on the other hand, starts immediately because it's written in Rust. I very much like this trend.
Yeah, I agree on that. In the nineties, basically the only general purpose language was C, with C++ growing in pains (and then extending uncontrollably) and Java promising to get better but having its own issues at that time. So people who needed to get their job done (efficiently) just used C, like Torvalds.
At that time, this new Python language was a curiosity. It was nice that you could easily replace dozens of C code with one line of Python but everybody was aware it's too slow. However, this window shifted with time. The perceptions of "fast" and "slow" changed for various reasons such as network delays so Python became acceptable in many areas it would be dismissed otherwise. To the point it became the no. 1 language now.
But we are not in the 2000s anymore. We do have powerful, batteries-included languages that are faster than Python. So I expect with time, large parts will be rewritten. However, the area related to scientific computing will stay with Python, just like Fortran programs continue to be used today.
I don’t know when you last tested the start-up time, but we significantly improved it in HTTPie CLI 3.0 [0]. Now it’s still slower by ~0.1s.
$ time http --version
3.2.2
real 0m0.113s
user 0m0.087s
sys 0m0.020s
$ time xh --version
xh 0.18.0
-native-tls +rustls
real 0m0.007s
user 0m0.002s
sys 0m0.002s
Not for me. Printing HTTPie's version takes longer than to finish a real http request with xh. I suspect it's because I'm testing it on a relatively old server where the differences are even more pronounced.
[link redacted]
I'm using HTTPie 3.2.1 because Arch doesn't have the latest version available but based on the release notes that shouldn't make a difference.
Except when you suddenly do need performance and predictable latency but all your software is written in python. Its always funny how these performance requirements just creep up on you like that.
Yup, and (monomorphized) struct generics, first-class SIMD vectors and ability to transparently work with memory ranges because Span<T> can also wrap T* + Length from unmanaged code, which lets you directly plug whatever data you got from C/C++ dependency into most CoreLib APIs.
In this regard, Go is far inferior as a systems programming language.
Yeah what we really need is a GCed language that allows you to implement parts in no-GC mode. And ideally where you can iteratively migrate GCed parts to no-GC parts when required.
Anyway, Python is not a good comparison, as performance is not one of its main qualities.
I went from Erlang to Rust and frankly I would not say Erlang is more productive, despite being a very high level language. When building a non-trivial system one should think about total cost of ownership.
A Rust program is by default going to be CPU and memory efficient. It is not likely to negatively surprise you in production with weird bottlenecks and unexpected behavior.
The time invested in producing a solution which is statically typed, pays of in spades when it is time to refactor or change something (which is pretty damn often if it is your product). Refactoring a Python/Erlang/Elixir/C/PHP solution is a major PITA and fraught with new bugs.
The time spent optimizing solutions in high level languages when they are falling on their face in production is generally ignored and extremely common. You do not have to be github to face performance problems in Ruby.
True. But it's a pretty small space to be in. And there are good reasons for that:
a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.
b) Rust can only give these guarantees because it is ALOT more complex than C. That means harder to read, harder to write, harder to learn. And developer time matters. Alot. If I can already ship features, while my competition is still stuck in onboarding, it won't matter if my code has the odd memory bugs...those can be fixed...I will already have the market to myself.
> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.
A powerful type system helps quite a lot with logic bugs actually.
Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that?
> and it has null pointers
Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the complexity of languages who pretend that null pointers don't exist.