Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "async rust"
-
Books and command lines.
I don't like teachers.
I think it's because my learning process is very async and chaotic. When I see a snippet in Golang, I relate it to PHP, Rust and Haskell. I jump to resolving the problem in other languages, trying to find out which approaches work in Go.
Then I read about some computer science concept on Wikipedia and get lost in that while my hunger for knowledge and food increases. After a while I look up a recipe for a pasta salad, and while cutting bell peppers, I see the recipe in terms of typed morphisms, I sprinkle and intersperse ingredients through mapping functions, then decide to write an interpreter for the esoteric "Chef" language in Go so I can interpret my salad recipe while eating it.
Voila, I'm learning Go.
I have no patience for linear mentoring, and others have no patience for mentoring me.
But that's OK.1 -
Fucking hell! Why is it so hard to just create a simple websocket!
C#: Yeah, you should use ASP.Net with SignalR! But heres a totally undocumented mess of a lib to get it to work. J.k. Deadlock!
Rust: async while let OK((some)) = ws.create.unwrap_or_else().suckadick()
Why the fuck is Rust so fucking dense! I want one line that means one thing! If I would compress my code with gzip it would be less information dense than this!
Zig: Yeah, Its in Beta and shits semi stable. Atleast i got it to work? Nope!
I've ben fussing aound with these three Languages for more than a week now and can say: Just use an established way to webdev. Its not worth it to try and make it as simple as possible!4 -
Honestly after fucking around with rust async, I do have a lot more respect for high level languages where you don't have to worry about locking memory and stuff haha. Learning promises in nodejs was a breeze, learning them in rust requires a lot more thinking :p17
-
It's a shame that people don't want to use F# but prise C# for how cool it became and continue becoming. At the same time, little do they know that many of the features were simply drawn from F#.
It's just rediculous how far this OO and C-Style syntax crap has progressed. They keep copying things from functional langugages, making the initial language to be a monstrocity like C++ is now, insted of just using languages like C#. I mean, it was right there before C#: async/task, immutablility, records, indexes, lambdas, non-null by default, who the hell knows what else.
Besides, many people (in my company at least) are just blindly overengineering with patterns and shit, where a simple function would be just enogh.
Watch some some NDC talks about F#, in particular those of Scott Wlaschin. It's just better in so many ways: less noice (I'm looking at you, brackets, commas and semicolons), the whole LOT of type inference and less duplication (just look at the C# signatures of linq methods - it's difficult to read them), immutability by default, non-nullable by default, ADTs and pattern matching, some neat features like type providers (how many times have used "paste special" or an online tool to create C# classes from a JSON/XML file, and how many times have your regenrated it because of schema changes?) and units of measure.
Of course, in some cases it's not optimal, in some cases mutable datastructures of C# are better for performance. But dude, how many performance critical systems have you wrote in C#? I mean, if it comes to performance you should use Rust or C++ or C after all.
*sighs*14 -
I came up with a really intuitive way to create a coroutine in Rust by passing the sender of an mpsc queue to a callback, then merging the receiver of the same mpsc with the future returned by that callback, but I must've cocked up somewhere because I'm pretty sure it leaks memory.
MPSC ports don't own each other in either direction, that was my first guess too.5 -
It's nice that more and more languages are introducing async/await syntax, but by the example of Rust in particular I'm starting to wonder why we don't instead introduce this syntax for monads in general?
We could have a keyword (say, `bind`) which unwraps a value from any monad provided that the return value of the function is wrapped in the same monad. The ? operator does something a little similar, and I'll be intrigued whether it can actually be implemented for monads other than Result and Option once GATs are stabilized. In particular in the case of Rust, it would be possible to create a reference counting monad for heap-bound management of objects derived from references.9 -
Async Rust doesn't have a great story for Iterator::map just yet. I wrote a mini-article about it:
https://lbfalvy.com/blog/...2 -
I wrote a small crate that does unsafe operations, please help me verify its soundness: https://github.com/lbfalvy/bound
(Also I think you'll like it, I'm solving a fairly abstract problem that's not possible in safe Rust)
It's essentially a struct that ties together a heap reference and a struct that's constructed from it. The main use case is to return lock guards derived from Arc<Mutex> but it's defined in a very abstract way intentionally because I'm using Marc from mappable-rc and async-std's RwLock and I didn't want this to depend on either crate.
It actually has no dependencies apart from STD (I think this one may be unavoidable)

