I find the fact that MS is promoting Rust in itself much more interesting than the content.
Also, I would still really like to learn Rust properly, but I don't have any use for it currently either at my day job nor for my side projects.
Also, I would still really like to learn Rust properly, but I don't have any use for it currently either at my day job nor for my side projects.
1. https://docs.microsoft.com/en-us/learn/paths/go-first-steps/ 2. https://docs.microsoft.com/en-us/learn/paths/java-on-azure/
I made a bot library for https://turntable.fm/ in javascript -> https://github.com/alaingilbert/Turntable-API
Then I rebuilt it in go -> https://github.com/alaingilbert/ttapi
Then I tried to write it in rust, but the pattern isn't really good with the borrow checker, I cannot make this work -> https://github.com/alaingilbert/rust-ttapi/blob/47282b7a334d...
So if someone can find a good pattern to use for this type of library, I would gladly want to learn.
Pull requests are welcome, I'm also always on discord if you want to chat.
let bot = Arc::new(bot);
bot.on_speak({ let bot = bot.clone(); move |evt: SpeakEvt| { ... }});
bot.on_speak(|bot, evt: SpeakEvt| { ... })Anyway, if you can make it work, I'll study your code religiously !
Yes, async closures are not currently stable, which is a huge pain in the ass: you have to use a regular closure with an `async` block inside, but said async block will usually need to be an `async move` block, which requires more contorsions because you can't just use stuff the closure owns as that'd make said closure FnOnce (the closure's item is moved into the `async move` block meaning the closure is destroyed). This is usually solved by putting the item behind an `Arc` (if it's too costly to be directly copied, or if you want / need to mutate it), this way you can `clone()` the arc so the async move block has its own "copy".
Alternatively, have the closure immediately and only call into an async function or method.
I can't wait for async closures, though, I'm sure others have their own bugbears but that's by far my biggest pain in the ass when using async rust.
It's a bit of boilerplate to define, but then your client code can look something like this:
while Some(event) = bot.try_next().await? {
match event {
Event::Speak { text, .. } => {
bot.speak(&text).await?;
}
_ => {}
}
}But this is just the start of your problems. To use Async, your Fn type should now also return a Future since these async tags will infect all your functions and their returns.
tl;dr: I'll start over and use Channels.
Microsoft don't care if that is a Rust, Java, Python, Visual Basic or PowerShell application. They only care that you choose to do it in Azure (so lets learn the Microsoft centric ways early) though.
- Conway's Game of Life
- Graphics stuff (raytracing, procedural generation, etc)
- Parsers/interpreters/compilers
- Command-line tools
None of these were things I needed exactly, but that's the fun of side projects :)
VS: Code doesn't put you down a particular "Microsoft developer path" at all.
True, but the directions to VSC in this case don't seem to relate to that, as these tutorials do the same for Go and Python. It's part of the strategy of this site. They want you to learn Python with VSC, and Go with VSC, not because they want you to learn Python or Go, but because they want you to use a Microsoft property in the process. Just as they aren't teaching you Git through this site, they are teaching you Git in the context of Github. All arrows are pointing toward Microsoft properties. I'm not saying this is a bad thing or wrong, but people here are asking "What's the catch" and it's all just marketing.
> VS: Code doesn't put you down a particular "Microsoft developer path" at all.
I disagree. Like I said, students emerging from high school are fully steeped in the Java ecosystem. A lot of them think that programming == Java. Many don't even have a concept that there is more than one programming language out there, and don't see a purpose of anything other than Java. The best thing MS can do to get people into .Net land is to get them out of JVM land. VSC is that vehicle. It doesn't matter what language they're using as long as they're using it in a Microsoft branded context. Not to mention half the people (I'm exaggerating of course) who set out to install VSC end up installing Visual Studio Community. I don't think that's intentional on Microsoft's part, but I'm sure they aren't mad at it.