I read this 3-4 times and realized why people stick to python though
https://news.ycombinator.com/newsguidelines.html
We detached this subthread from https://news.ycombinator.com/item?id=34429403.
I assume you’re going to reply that you don’t need to think about all this when writing most Python. And that’s true of most Rust too. Don’t get me wrong, Rust does have some unique complexity that Rust programmers need to learn in exchange for its unique safety guarantees—but method lookup isn’t where the complexity is.
I actually find that simpler than some of the spaghettis you can create with Python’s multiple inheritance :P
In Python, a list of lists has the same behavior.
l = [ [ 1, 2, 3 ] ]
l2 = l.copy()
l[0][0] = 99
print(l) // [[99,2,3]]
print(l2) // [[99,2,3]]It's not just lifetimes, a basic Rust function can expose the ideas of exclusive and non-exclusive ownership, traits, generics with and without trait bounds, algebraic data types, closures, closures that move, async, async blocks, smart pointers, macros, trait objects, etc etc.
There is absolutely a learning curve and it makes me understand why Golang is the way it is. The language authors of Golang saw the business needs of Google, realized that they need to get domain experts that are not programming savants to write code and created a language that would allow the largest number of non programmer domain experts be productive coders.
That being said, the Golang developers went too far and let too many of their biased ideas for what is "simple" infect the language. In what way is it simple for a language to not be null safe. I have a bunch of other complaints too.
But anyway, I don't think Rust is going to be a revolution in writing software unfortunately. I don't think enough people will be able to learn it for companies to be able to hire for Rust positions.
It was a real struggle, and I wasn’t enjoying it at all. “Programming Savant” is a great way to put it because all the people I know who like Rust also happen to be the smartest engineers. In the end I gave up because I wasn’t getting any value. I was also trying to find a Rails equivalent, tried Actix and I didn’t like that either.
Reduced to its barebones, the problem is:
1. Expose a HTTP server
2. Make n HTTP requests
3. Combine their output
4. Return the result
But I was definitely expecting to have an outcome in a few hours. This might be a language that it takes more than that time for me to be proficient enough to use async code in.
Here's an example from my friend, almost exactly my problem and what was suggested: https://old.reddit.com/r/rust/comments/kvnq36/does_anyone_kn...
> This might be a language that it takes more than that time for me to be proficient enough to use async code in.
Yes, it does take more time to learn the language, but once you do, it's pretty straightforward. Rust is a different way of thinking (a Meta Language dialect in C clothing, as I like to call it; it looks like C but it's definitely not the same semantically) while Go is similar enough to C-based languages and web based languages like Javascript that it's relatively easy to get started with.
It's much the same as learning Haskell or APL, the entire paradigm will be different and can't be picked up in a few hours. However, if you already have functional or array programming experience, Haskell and APL will seem straightforward. It is because you have a lot of C-language or JS based experience that Go was easy for you.
Yeah, it's probably just the programming paradigm that was different, but if you look at that post I posted there, it's not that straightforward (all the code is there so you can try it out).
For what it's worth, I found burntsushi's code wicked easy. I don't write Rust but I have my own forks for `xsv` and `ripgrep` and I could just pop in and add a new command and some functionality. But that actix-web experience was intense. I spent like 4 hours on it and couldn't make it work and then the repo disappeared and I just used go.
In typical TypeScript/Python, you don't need to worry about memory allocation. At all.
If you're writing any non-trivial Rust application, you're quickly going to have to learn a lot of concepts regarding memory, and your code will reflect that.
Now, if your application must be high-performance then Rust is a no-brainer. Rust is much better than the alternative (probably C++). But, most web applications don't need to be high-performance, and it would be better to use a language that is easier to learn and write.
That's not to say I don't like Rust; I hope it takes over the world that C/C++ have a grip on.
From my limited experience I think it is possible to write simple, dumb Rust, still get a N times performance benefit using N times less resources compared the languages you listed at the cost of being more verbose.
There's a learning curve to understanding concepts like lifetimes and so on. But diving deeper there arise many problems. There are just a ton of hyper specific and nuanced types and traits in Rust, and that's just the std lib. Reading Rust is also quite difficult because it takes time to navigate the types and abstractions. Also dependency trees seem to be deep in OS projects.
It's a powerful, great language, but I would say the learning curve and the subtleties can _easily_ be underestimated, because there is an initial AHA moment when lifetimes, traits, closures, async etc. start to click. But the devil is in the details.
But I think the need/want for safe, fast languages with good security defaults is on a steady rise, especially in web development. Clients (laymen) start to notice and praise good performance and robustness more than they did 10y in my experience, so it's definitely worth it to take a look at languages at Rust.
Rust is much lower-level than Ruby, so in general you're going to be a lot more concerned about memory -- in this case, satisfying the borrow checker, dealing with stack vs heap allocation, etc.
> the finished product is as easy to work on as our Ruby code
I... highly doubt this. It's harder to hire Rust programmers than it is Ruby programmers. It's harder to teach Rust than it is Ruby. And, again, your Rust code is going to be much more in the weeds than Ruby would be. Rust also is a pretty complex language -- there are a lot of concepts to learn if you want to use it well. Ruby is fairly easy to learn.
I'm not saying that Rust isn't the right language for you, or that Rust is bad (I love Rust!), I'm just saying that it's much lower level than Ruby, and that comes with tradeoffs.
Making HTTP requests and using an ORM in rust wasn't harder than in Ruby. I didn't have to think much about the borrow checker or memory as it was all single threaded simple stuff.
Even my peers that transitioned from ruby to rust had a pretty smooth time since ruby's functional-ish, enumerable dependence, and blocks style coding lends itself well to rust's idioms.
But if you've only ever stayed in iterative dynamic language land and don't remember university coursework on programming languages, compilers, or operating systems, yes, you'll probably be in for a world of pain and frustration.
I wish people didnt say or think things like this. a lot of the times people get into these complex things and talk over people to make them selves look smart. or make things look more complicated then they really are to improve their image. i ran into this a lot when dealing with rust. if you can't do complex things in a clear and simple way, your just regular.
Go is probably the most widely used 'simple' language, and it's primarily used for applications. You can find some examples of using Go for systems-like programming, but that's not where it shines.
But if you're working on one who does, you're typically glad to use Rust :)
For example, if I need to use simulated annealing to solve an optimization problem, there already exist libraries that implement that algorithm well.[1] Unfortunately, the Haskell library for this seems to be unmaintained[2] and so does the OCaml library that I can find.[3] Similarly, Agda, Idris, and Lean 4 all seem like great languages. But not having libraries for one's tasks is a big obstacle to adoption.
Nim looks very promising. (Surprisingly so to me.) Hopefully they will succeed at gaining wider recognition and growing a healthy ecosystem.
[1] E.g., https://github.com/argmin-rs/argmin
[2] https://hackage.haskell.org/package/hmatrix-gsl-0.19.0.1 was released in 2018. (Although there are newer commits in the GitHub repo, https://github.com/haskell-numerics/hmatrix. Not too sure what is going on.)
My main domain is scientific computing and I get nervous about the prospect of not being able to run my code 5 or 10 years down the road (somewhat above the typical lifespan of a project that ends up published in my discipline). GHC gets updates that sometimes require library maintainers to update their libraries. Here is a list of a few:
https://github.com/fumieval/Haskell-breaking-changes
Rust promises no breaking changes in the stable part of the language. Hopefully this promise will hold up.
I use C++ professionally and the small subset of it that I've learnt is already way more complicated than rust.