Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rust keeps getting hyped so I thought I should give it a go. I’ve been writing JS/TS, Ruby, PHP, Python for 10+ years.

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.



Rust is a good replacement for C/C++. It's not a good replacement for the languages you listed.


Disagree, I have a web server in Actix that I would have written in TypeScript and Node, or Python and Django, or Ruby and Rails, and the Rust version is similarly high level but far faster and more efficient. I recommend people read Zero To Rust In Production if they want to build a web API in Rust.

https://zero2prod.com


That's a good book. Project focused and practical.

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.


I had the opposite experience. I wanted a quick http server that would proxy some requests where I couldn't control the client and the real servers. I hadn't written either language at the time, but I had it in seconds in Golang and fully functional and I used actix and halfway through the dependencies disappeared and then afterwards it was still a hassle even with help from people on the subreddit and discord.

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...


Not sure what you mean by dependencies disappearing.

> 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.


I'd just started on things and they randomly disappeared the repo. There was some Rust community kerfuffle that was going on. I don't know the details. It was really annoying at that time, but it's really not a big deal now.

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.


Oh you must have used it in the Actix Web drama time period in 2020. Yeah it's much better now. You might want to try it again, it's as straightforward as Go now I believe.


Thanks, I'll give it another whack!


> the Rust version is similarly high level

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.


I've been going through this book, not once did I have to think about memory management (beyond adding a few &), it's simply not needed at this high level and crates manage most of the low level details for you. I especially haven't had to think about Arc, Rc, etc either.


Unfortunately I haven't had the same experience as you. Even for a simple program I've had to think about passing by value/reference, lifetime annotations, static lifetimes, etc.

That's not to say I don't like Rust; I hope it takes over the world that C/C++ have a grip on.


Rust is a decent replacement for any static compiled language too. It's honestly a breath of fresh air if you actually need to use parallelism and had to experience that with other static languages.

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.


Disagree, I've used it to replace Ruby at work. I haven't had any criticisms of the language itself, only the library ecosystem and community knowledge make it difficult. I spent a lot of time working out what the right library is or working without examples for some libraries. In the end the finished product is as easy to work on as our Ruby code once the patterns are established and libraries imported.


Rust shines in two domains: high performance, and systems programming. Ruby is most commonly used for web applications (e.g. Ruby on Rails).

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.


The latest service I built kept a list of urls to poll in a database and it polls/processes/sends off the result. Using a http and ORM library I found this task to be pretty much the same difficulty as doing it in Ruby only it was far more reliable than Ruby.

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.


> because all the people I know who like Rust also happen to be the smartest engineers.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: