Do not use async rust when you are learning. It is ok once you are proficient in rust.
Rust Is Hard, Or: The Misery of Mainstream Programming
61–70 of 811 posts
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#62The syntax is just hard.
I tell new programmers to start with either Python or JavaScript. The pay is the same or better, and it's much easier.
I've been programing for almost a decade, I still can't understand lower level languages like Rust and C++.
Why, if you can design a new language, not make something with the simplicity of Python ?
If your going to compile the binary anyway, have the complier figure out the types and optimize.
This is why JavaScript is eating the world. We don't need legions of hardcore software engineers. We need people who use a bit of Python, JavaScript, etc, to make their jobs easier.
The future of programing is easier higher level languages. Rust has some applications, but it's too hard for most
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#63Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…
Wow, this really speaks to me. I've sunk hundreds of hours in the last few weeks into a tokio-based thing using a bunch of async and ... what a nightmare. It truly is half-baked.
And yet it seems like so many things have tied themselves to this async/tokio mast. It's not a good look for Rust.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#64Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…
>There are almost no active / popular libraries related to network IO that haven't switched over.
To extend this with a slight caveat: for many of those network IO libraries, there's still often a sync alternative. e.g, ureq in place of reqwest works for many use-cases and doesn't bring in an entire tokio runtime for a blocking request. You can find sync DB libraries.
Some other crates have started to catch on and offer them as a feature-enabled adapter (e.g, Sentry does this and can use ureq in the background).
I feel like a real problem, though, is that there's a division of eyeballs across these boundaries. I would chip in to funding work on a "reqwest-non-tokio-adapter" or something that utilizes all the same reqwest types, but avoids Tokio.
(And I like Tokio! I'm basing a new project on it as we speak. I just cringe every time I need to use reqwest::blocking because of something the sync alternatives haven't gotten around to implementing.)
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#65I personally believe that Rust is an exceptional language and it’s ahead of its time. Seriously, can you think of any other language with as incredible type system, incredible tooling, incredible performance, incredible package management and general package quality, incredible compilation target support, and practically no few backwards-compatibility quirks? But Rust is a really bad general-purpose language. Because…
The evolution of JavaScript from "DHTML" to jQuery to "JS: The Good Parts", browser runtime speed improvements and the introduction and development of TypeScript really highlights to me that languages that are complex (e.g. how JS objects work) can be explained, improved on, etc.
I guess what I mean by this is just as C++ got move semantics and auto keywords, it's very possible for a language to choose to evolve in ways that can make code easier to maintain and more expressive. TypeScript or Kotlin are examples of this. Also .NET core and Java since Gradle.
Some things rise in popularity despite their complexity. Objective-C and Swift come to mind... as well as writing truly portable Unix code or Kubernetes.
Personally, I'm waiting for the inevitable "Rust: The Good Parts" that I can feed into my linter and help myself and others on my team understand which parts are minefields of complexity and which parts are incredibly useful once understood.
In JS, there were multiple JS APIs and common practices with global state and more that just fell off the face of the earth. Most IDEs now say what is modern and what isn't, backed with new syntax and conventions that avoid traps in understanding like rebinding this for magic syntax, or using lots of stringly-typed functions.
The only problem I can see is that improvements don't come for free, or quickly. In C++'s case, some of the improvements took multiple decades before they were implemented and half a decade to become widespread and recommended...
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#66Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…
> If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way.…
I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff.
I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less.
Go is the new Java. Rust is the new C++. Let's just stick with that.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#67Async rust isn't pretty.
If you are using async rust, and want to borrow data, use an Arc.
In fact, if you ever use tokio::spawn, you will have to use Arc anyway because it requires 'static lifetime.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#68Unpopular opinion: I find rust code unreadable. And I consider myself a polyglot. I am sure all those symbols have a special meaning but it's like perl to me. Just throw some random special characters and they all mean something.
I find it readable, but I do sympathize. I would have like to have seen it look more like an ML language such as OCaml or F#.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#69I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times.
Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experience with modeling things in an object-oriented fashion; I find tying state & method into structs and using 'self' on methods in OO fashion just makes things far worse when async is involved.
The thing that really bugs me about Rust and I think it's the core of what really confuses many people is that it upends our normal intuitions about scoping. In other languages we're used to thinking of the scope of things in terms of lexical scope at the block/function/module/class level, and inside that scope, anything is game. You can almost visually see it. Usually.
Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?!
I think many of the things in the language -- lifetimes and borrows especially -- should have been modeled with a more explicit syntax instead of hiding inside existing standard language features (type parameterizations and assignment)
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#70Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…
In your experience what languages would you say handle async well? Genuinely curious. I’ve only ever done JS professionally for a decade but started branching out into python, rust, and kotlin due to personal projects.
Server workloads are different from client workloads here, and network/IO heavy workloads are different from CPU heavy workloads. You'll get tend to get misleading advice from people only familiar with one of them. Especially if the client is an asymmetric architecture like ARM has and Intel is moving to.
Swift's design is made to be good for IO workloads on smaller clients, though it hasn't got as many tools for the other end.