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.

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!

promises in JavaScript have really spoiled me

it's the most optimal way to do async without leaving much on the table

there's a promises library in rust and the guy who wrote it says it sucks because it spawns new thread every time you execute a bunch of promises

and I finally, through my fogged brain, managed to get the bright idea to write what I want to make in rust in JavaScript and holy hell it's sexy to work with promises. there's no performance left on the table. you do things as fast as possible

but if I take this JavaScript usability code I made and make it possible syntax-wise in rust I don't see how I would be able to do it without starting new operating system threads every time I execute any promises (or set)

I can take the overhead hit but this sounds retarded

and this isn't even touching upon how in rust everything needs to have a predetermined data type. so you can do lambdas and capture variables and send in variables into a thread that way, but to return the return object must be a consistent type (synchronizing the order data was sent in to the data sent out aside, haven't written that yet should be fine though)

which is fine if you are making a threadpool and it'll all be returning one data type
but this means you can't reuse a threadpool you made elsewhere in the program

the only thing that could fix async is to literally be compiler-enabled. it would have to work like generics and automatically make an enum of every type that can return, and only then could you re-use the threadpool

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 :p

what I want is for AI to spot logical inconsistencies in my code and debug it

specifically a complex multi threaded form...

raaghhh

stupid tokio having no damned mutex debug tools

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*

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.

Rust, I demand you give me dyn trait support for async traits now.

lol async is so foreign to rust the println!() thing interrupts itself midsentence