First steps with Rust | Hacker News Reader

First steps with Rust

docs.microsoft.com

244 pointsyannikyeo89 comments

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.

Microsoft is promoting / providing courses on all sort of languages and technologies and so are other cloud providers. It is good to know but it sure is not like "Rust on Microsoft site? This changes everything!!" E.g. here are course for Go [1], for Java[2]

1. https://docs.microsoft.com/en-us/learn/paths/go-first-steps/ 2. https://docs.microsoft.com/en-us/learn/paths/java-on-azure/

If you are interested in rust and want a very simple project to try it on:

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.

You cannot access "bot" inside bot.on_speak(|| { ... }) because Rust does not know that the "bot" variable stays alive for whenever the callback is called. In this situation I would expect "bot" to be stored in an Arc, and then you would move a clone of the Arc into the callback:

    let bot = Arc::new(bot);
    bot.on_speak({ let bot = bot.clone(); move |evt: SpeakEvt| { ... }});

Edit to add: Alternatively, the bot could pass a mutable reference to itself to the callback when it is invoked.

    bot.on_speak(|bot, evt: SpeakEvt| { ... })

easier said than done though. I tried the second option (calling callback with a mut reference to self) but I couldn't make it all work. I think I also had issues with "async" in a closure that could not be done.

Anyway, if you can make it work, I'll study your code religiously !

> I think I also had issues with "async" in a closure that could not be done.

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.

Here you go: https://github.com/alaingilbert/rust-ttapi/pull/1

Yeah, callbacks don't really play well with async Rust at the moment, due to those borrow issues. One way to work around it is to define your Bot struct as a Stream of Events (an enum for all of your current callbacks).

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?;
        }
        _ => {}
      }
    }

This is not a borrow checker issue, if I understood correctly. You are using Rust callbacks, the same you are using JavaScript ones. The problem is that you are not accepting a generic callback in "on_speak" but a particular type that you define: fn(SpeakEvt). If you try to capture variables inside your callback, you should use define an FnOnce type.

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.

Unfortunately, it is impossible to have secure websocket (wss) without using "async". (as far as I know)

I did advent of code in it this past year as a learning exercise and had a great time. It’s not exactly “real world”, but it’s great for soaking up syntax, algorithms, many basic crates, etc, without locking a project into a bunch of bad design decisions.

Microsoft don't sell software in this context. They're selling a service, primarily Azure. Azure is the mainframe that you'll be running your Rust applications on and paying Microsoft the monthly rental for that.

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.

Looking at the contents, it doesn’t seem like they are pitching Azure specifically. The Java one shown in a sibling comment does talk about Azure API. At least the work done by MS on VsCode, Language Server, TypeScript etc is truly helping whole community. May be there is something in Rust world as well.

I have a file system distribution application I am working on. It is written entirely in TypeScript but I envision using Rust to perform certain media execution tasks or things heavily focused upon arithmetic like financial data analysis. My application is fully isomorphic so the only value in TypeScript on the terminal is for portability of systems automation with Node. Tasks that do not require cross-OS systems portability can be done with something like Rust as a child process.

Fwiw Rust has fantastic cross-OS systems portability in just about every way except the fact that you have to compile separately for each platform (which you obviously don't for Node). But if you aren't needing to ship a single precompiled binary, you should have no problems.

Fun Rust projects I've done that it was well-suited to:

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

Step 4 of this tutorial is "Install Visual Studio Code", so Microsoft is definitely using this as a vehicle to promote VSC.

I don't think vscode needs any additional promotion.

Sure it does. I teach intro programming and I have 100+ freshmen students every semester who have no idea what visual studio code is. Students in US high school are learning Java these days due to it being the language of the AP exam, and they're not using Visual Studio or VSC. They're using IntelliJ, Netbeans, and Eclipse. Microsoft needs these kids to use VSC to get them on the Microsoft developer path early.

VS: Code has already been in first or very close to it inside the Rust community for years now.

VS: Code doesn't put you down a particular "Microsoft developer path" at all.

> VS: Code has already been in first or very close to it inside the Rust community for years now.

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.

For Rust or indeed C/C++ related development I use CLion from jetbrains. I've found it a fantastic IDE for testing and debugging.

The most interesting thing here is that this tutorial has been translated to around 50 languages! Rust tutorials and documentation are abundant in English, but the resource is much scarcer in most people's native language.

This looks like a nice addition to the Rust cookbook. It seems a bit more structured, and I actually like that it gives XP for completing the chapters.

I'm greatly encouraged to try out Rust with Linux. I do wonder if I can do an out of tree kernel module to make my life easier developing. I know I could do this with ordinary kernel modules.

To add to this, I did some browsing and found this:

https://GitHub.com/tsgates/rust.ko

What's the strategy behind this move? Is MS adding some Rust APIs to some of their products?

They are starting to rewrite Windows components in Rust [1] and are also founding members of the foundation.

[1] https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

I wouldn’t be surprised to learn that MS see Rust as a strategic “safer C” going forward. They have tons of legacy, dangerous C/C++ code across their traditional products (and Windows in particular), which could be slowly replaced with more robust Rust implementations.

Microsoft's c codebase is heavily annotated with custom annotations they check at compile time. It's not as powerful as Rust, but very cool.

https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...

Rust also fits perfectly into their general desire for robust drivers, for example with the Static Driver Verifier [1]. If a device driver misbehaves people usually blame Windows, so they spend energy on reducing the classes of bugs that can happen.

1: https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

Until Rust is replaced with something else (perhaps steel-lang or carbon-nanotube-lang). :)

They released a while back Rust crate for Windows API: https://github.com/microsoft/windows-rs

https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...

They are one of the founding member of Rust Foundation, and from the article it seems that they do use Rust in some of their products.

Partly they probably just want people to be able to use different languages on their OS. They have similar guides for Go and Java for example.

Amazon, Google, MS and Huawei are Rust foundation members.

Do they ever debug the application inside VSCode in this tutorial?

When will there be another implementation of Rust? If there's ever a GNU implementation, I might be willing to try it.

Some links on the most promising effort so far, gccrs

https://opensrcsec.com/open_source_security_announces_rust_g...

https://www.embecosm.com/2021/01/12/gcc-rust-how-it-can-be-a...

https://rust-gcc.github.io/

This is an entirely new frontend written in C++, that shares no code with rustc (the official rust compiler). It might be merged some day in GCC proper.

But honestly, I'm more excited for rustc_codegen_gcc:

https://github.com/antoyo/rustc_codegen_gcc

It adds gcc as an alternative backend of the official Rust compiler. That way it is much more feasible to stay up to date as the language evolves.

Anyway the former two don't actually work right now. The one that does work today is mrustc, or at least it works for bootstrapping rustc; it doesn't have a borrow checker though (and instead assumes the program is correct). Also, mrustc isn't based on gcc.

https://github.com/thepowersgang/mrustc

(There's a fourth project, https://github.com/sapir/gcc-rust, but it seems abandoned)

Meh. Part of what makes rust appealing over C++ for my current project is that the latter has at least three major target compilers with subtle differences in how they implement things that mean that even staying within the bounds of the standard might result in different outcomes in the code (not to mention the whole mess around dependencies in C++ code). Multiple implementations of a language feels more like a bug than a feature to me.

As best I can tell, C and C++ are the only languages where people are actually happy that there are multiple implementations.

Multiple implementations are great when there's a standard to compare them to, ideally where that standard is backed by a set of tests.

The problem is when you have multiple implementations of languages that are effectively defined by their reference implementation, then the alternatives are usually an exercise in frustration.

I think Javascript has many user who think they benefit from competing implementations. I’m not sure the sentiment there seems as strong as in the C++ community, but it definitely exists.

I'm more annoyed by the inconsistent implementations than anything else (Mostly browsers as server side still sees node being the winner).

Not to mention the terrible tooling to make multiple deployment targets possible (webpack, polyfills and whatnot)

Count Ada, D, Java and .NET as well.

What about Java? As far as I know, everyone was very happy OpenJDK existed and Oracle eventually relented too. Now we have even more interesting stuff like Graal.

Disclaimer : I'm still new and learning Java.

OpenJDK is the original version of Java with a few features stripped out, not a reimplementation.

See the History section of https://en.wikipedia.org/wiki/OpenJDK?wprov=sfla1

Thank you for the link. I stand corrected and better learned.

Glad it was interesting. I was surprised to learn the same thing a few months ago

Java also has multiple implementations. Great to have a documented language standard!

Hmmm what about CPython and PyPy?

As a single data point, I’ve been using Python since 2005 and have never played with PyPy any beyond a quick peek after seeing a conference talk.

On the other hand, I use gcc, clang, and MSVC++ on a regular basis. But... I think the reason I care about multiple C++ compilers is mostly because there’s no “one compiler that is ergonomic to use everywhere” and I end up writing better code because of it (eg gcc warning about something clang doesn’t care about).

For Python, I mostly just care that it Just Works everywhere (modulo compiler setup for building C modules)

Almost all Python code is written for CPython, and if you run into performance issues you tweak it until it runs on pypy.

I'm glad that pypy exists because it forces cpython to do something about performance, but for python overall it's a pretty niche tool.

> even staying within the bounds of the standard might result in different outcomes in the code

If that's important, why not pretend that your project is in "Clang C++" rather than C++? Clang compiles to at least all the platforms that Rust does.

> not to mention the whole mess around dependencies in C++ code

Agreed. I feel like the proliferation of header-only libraries is a sign that something's seriously wrong here.

Multiple implementations is a fact of life for popular and useful languages. (Not Rust yet.)

Standards exist to make multiple implementations palatable.

See Python for a stunning example where they botched the standardization effort and ruined the language for good.

Can you elaborate on why you think they “botched” the standardization? I don’t know much about the topic, and I’m genuinely curious about what went right and wrong.

I'm not very familiar with the details, but I can comment on the results that I see: there's a multitude of python implementations (Jython, ironpython, pypy, stackless python), but only CPython has widespread adoption and there's little overlap between the ecosystems: rarely will python code be written to run on multiple implementations. I think the largest reason for this is that the CPython ecosystem is basically built on a foundation native C code (not just in the standard library but in many of the commonly used packages), and that interface is only starting to get some standardisation, as well as being very tied to CPython implementation details which made it very difficult to implement on other platforms.

In that sense Democracy is also a bug then. In some ways it's a feature. It's a feature because it makes harder for reverse engineers to know which compiler generated the code. When they figure out the compiler, they can reverse the compiler logic.

This seems like a really odd reason to care about multiple implementations: firstly because it's a steam hammer to crack a walnut (there are much more effective and cheap ways to obfuscate code than just using a different compiler), and secondly because it's not very effective: compiler identification is fairly straightforward, both for experienced reverse engineers and the tools that they use.

Compiler identification is not fairly straightforward when you remove all metadata that gives you hints. It gets worse when you fake the metadata.

My opinion echoed by many top people in reverse engineering industry.

Modern C++ is obfuscated by default due to templates, inlined functions and of course OOP.

For example, Marcus Hutchins famously echoed Boost is a cluster fuck of sadness.

My point is not about obfuscation anyway but it does helps obfuscation to some extent. It's about reverse engineering the optimized code and recover the original non-optimized code which can have a lot of use-cases.

https://www.msreverseengineering.com had a course on this subject. Experienced ones can reverse everything but my point is that it increase the barrier.

Making the job of those engineers harder doesn't sound like a feature.

I don't want people even competitors to steal my intellectual property so making job of those reverse engineers harder is a feature not a bug.

https://github.com/Rust-GCC/gccrs is in progress, but I believe it works enough to be worth playing with. Note that it doesn't implement the borrow checker - the plan is to reuse rustc's borrow checker as a compiler plugin. For now, as I understand it, gccrs itself assumes that the code is valid (i.e., would be accepted by rustc).

https://thephilbert.io/ is the primary developer's blog and has status updates.

See also the discussion here https://news.ycombinator.com/item?id=21734529 (about https://github.com/sapir/gcc-rust but also about a GNU Rust compiler in general)

For my own enlightenment, why a GNU implementation? What does it bring to the table?

I suggest you try a functional language before driving into Rust.

First off, your account is just C++ spam. So, off the bat, I've dismissed the notion of taking you seriously.

I've implemented a basic ML variant before, and maybe half a dozen different lisps. Rust is only BARELY functional. A C++ guy ought to know better!

Believe me, I'm not interested in Rust for Rust's sake. If there were a GNU implementation, I could see writing code generators for Rust a little less cumbersome than trying to target C or LLVM IR or Wasm.

Realistically, I see Zig winning the fight that Rust is trying to fight, and C++'s headaches being replaced with Rust's headaches.

I don't spam C++ and I comment on C++.

There is no fight. There is made-up flame-war. Every war happen at HN and Reddit's Echochamber not at Real World.

Every languages has headaches. You won't find a perfect language ever.

You can't do serious Rust if you don't understand functional aspects.

I know C++, Haskell and Rust. Like many says Rust is a functional language disguised as imperative. There were case studies on Rust where a one with Haskell background more like to learn it faster than a one with C++ background.

The Rust book don't show you the functional parts at beginning to build your intuition but once you drive deeper you will realize what I meant.

https://ceronman.com/2020/09/17/is-rust-a-functional-languag...

In my (limited) experience with people who tried to learn Rust with a predominantly C++ background mostly struggle with trying to shoehorn some OOP design, when the language has other idioms better auite to it.

Rust does have a lot of nice ideas borrowed (hehe) from functional programming, but it's far from being FP!

On a tangent: you're comment about learning a FP before learning Rust is great advice, but not for the reasons you initially intended perhaps. Learning FP in general is great, since it teaches you a different way of thinking from the "classical" way programmers think. So, it's great to learn FP for anyone, regardless of whether it's for Rust's sake (it will help a bit with reasoning about some Rust concepts and idioms, though), or not.

Graydon Hoare is a OCaml developer.

Graydon Hoare mentions Rust as linear ML in C++ clothing.

https://twitter.com/graydon_pub/status/1154476823557754880

I empathized the can't deny relationship between Rust and FP. It doesn't means Rust is a pure FP language. I always said same thing about C++ templates too.

Needs some proofreading:

"Until then, you can think of String data as string data that can change as your program runs, while &str are immutable views into string data that do not CHANGES as your program runs."

// Instantiate a tuple struct by passing the values in the same order as defined. let origin = Point2D(0, 0) // Missing ;

Microsoft promoting rust, never thought I’d live to see the day.

Not clear why one would choose this over the official rust documentation and tutorials.

Oh and also - it’s a trap. Microsoft are not friends of free software.

How is it a trap?

Please don't make vague accusations. If you have something substantive to add - describe it.

Oh vague? You mean like calling open-source software a "cancer" and "an intellectual-property destroyer” ? https://www.cnet.com/news/microsoft-red-hat-argue-open-sourc...

Can you show some evidence that's less than two decades old though? ;)

Open source has "won" in the meantime. Why would Microsoft be interested in turning back the clock now that the money is in services, no longer in software.

Open source has gone horribly right, but Free Software isn't anywhere close. The year of the linux desktop is literally a punchline, and Replicant shows that it's not possible to have a fully libre smartphone.

> Can you show some evidence that's less than two decades old though? ;)

I don't agree with the GP comment, but, i doubt they'd make this mistake again even if they believe it.

I guess the general attitude of FAANG and microsoft towards open source is that if they could make money with it, it's good. Once, companies saw you could make money with opensource, other concerns evaporated. This reminds me of all those ads that IBM spent promoting linux, but, ultimately didn't end up as winner with opensource.

I think what they meant by "vague" is that you did not tell us why you think it was a trap. :)

Microsoft are going big on rust and wasm. They have had their fingers burned to much in the past from being late adopters (linux, containers etc) and don't want to be at the back again.

On the WASM side, Blazor and Flight Simulator plugins.

> Oh and also - it’s a trap. Microsoft are not friends of free software.

How does a freely available tutorial on a programming language have anything to do with someone's position on free software?

Check out how well their windows-rs project supports cross compilation. It also requires proprietary components to be present. Meanwhile winapi, the project windows-rs is a competitor for requires neither.

Would I call it a trap? No, but MS hasn't shown well enough that they are friends to free software.

I still don’t see the link between what you say and this rust tutorial.

From the linked docs

> For example, if your distribution uses the GNOME desktop, locate the Show Applications icon (a grid of dots) docked on the left side of the screen, usually near the bottom. This icon opens a full-screen list of all applications installed on your system.

Why would they be teaching Linux beginners how to use GNOME if that was their opinion?

You do know that they open sourced ton of stuff, right? Including .net core for example (under MIT license).

Reply on news.ycombinator.com