Hacker News Reader

Unfortunately, I'm inclined to agree.

Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases.

It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions and not being OOP-first also mean that codebases are generally readable. Compilation is also extremely straight forward.

With Rust, I've found even very experienced C++ folks have a long ramp-up period, the development toolchain is slow, and the ecosystem is limited.

Sure, for example there are projects to enable Rust usage with CUDA. But few are inclined to actually bother implementing a new BLAS and GPU accelerated tensor library with Rust.

I do think 10 years from now Rust will start getting more adoption as the ecosystem and tooling improve.

But it's hard to argue with Go where you'll typically get results that are faster or at worst comparable to Java without the OOP design pattern gobbledygook, simple concurrency model, and simple build process. It's "good enough" for 99% of use cases.

Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.

> With Rust, I've found even very experienced C++ folks have a long ramp-up period

I've found C++ folks especially have the hardest time with Rust, because they approach it using C++ idioms and habits, then get frustrated when they can't do things the way they're used to.

I've had better success teaching Java people Rust. They find it much easier to learn than C++, and I can get them writing idiomatic Rust code quickly, while C++ devs are still trying to get their coding habits past the borrow checker.

I think everybody has a hard time starting with Rust.

Even when you get confident it is still a longer process writing code than C/C++. It makes you think very hard about what you do carelessly in C.

But having spent the last few years debugging a lot of Swift code, and a bit of Rust code, that time is worth it I say.

Where Rust shines is in the debug cycle. Less of it.

Once you learn to surrender to the compiler, you will find true bliss,....

> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust.

I'm curious to see those few lines of JS!

> - bad error messages (even though that was a focus for the rust team!)

I would love to hear more! (If you have the time.)

Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing.

I recognize this is not entirely on rustc though.

Having examples of these is useful to see what we could get rustc to do. The general case might be impossible to deal with in a generic way, but we can target specific patterns libraries use and emit custom errors for them. The problem with these is we have to be reactive: if we don't see a problematic patter ourselves (or it isn't reported to us), we can't do anything about them.

Unfortunately last I tried these code snippets was months ago, was rushing like mad because it was a startup and I couldn't afford to just stop and write everything down and... yeah, priceless info was lost.

Just recently I am making a comeback to rewriting a tokio 0.1 library to the latest version so I'll likely have a few examples that I can post... where? In GitHub issues?

GitHub works great for it, for diagnostic tickets in particular you can file them at https://github.com/rust-lang/rust/issues/new?assignees=&labe...

Even if it is an "it hurts when I do this" without more context it can be useful to bring the problem to our attention (but the more context you provide the higher the change we'll fix the problem).

esteban of course gave you an excellent response already, but just another bit of like, context here: while it may not be on rustc, the developers want to go beyond the norm here. rustc understands if you write async/await syntax like JavaScript, and then directly proposes that you switch to the Rust syntax:

    pub async fn foo() -> i32 {
       unimplemented(); 
    }
    
    pub async fn bar() {
        let f = await foo();
    }

gives

    error: incorrect use of `await`
     --> src/lib.rs:6:13
      |
    6 |     let f = await foo();
      |             ^^^^^^^^^ help: `await` is a postfix operation: `foo().await`

It isn't on rustc to understand this either, but it helps a bunch of people, so the team does it anyway.

Check sibling reply. Sadly I never wrote those down. :(

I'll definitely do so going forward.

The problem is with that is the impostor syndrome: I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive.

But your messages help. I'll just write those down and send them to GitHub's issue list.

I’m not working on Rust anymore, but the previous stated position on this, which as far as I know is still the case, is that if it’s confusing, you should file. Worst case scenario is “sort we can’t fix that” but it’s not an imposition to file issues. More is better. Because exactly as Esteban said, information is valuable. Even duplicates are valuable: they indicate that more than one person has run into this, and therefore it’s more valuable than an obscure issue only one person sees.

I can confirm all of this is still the case.

> I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive.

It doesn't make a difference. The compiler can't assume any level of proficiency. If a topic requires you to read the docs, it should tell you so. There are some "basic" things it relies on, but for anyone with any level of experience programming should be able to read a diagnostic and either understand it outright or have enough clues about what to search for. So "this error is confusing because I didn't read chapter N of The Book" can be simplified to "this error is confusing."

Excellent. Keep up the good work, I (and others) appreciate it.

> - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust.

Please, more detail (=

JS:

    new HTMLDivElement()

Rust:

    struct WebBrowser {
    ...

Instantiating an object vs defining one? Yeah definition would be longer.

I should've been clearer, sorry.

The verbosity and complexity of `wasm_bindgen`/serialization between JS and Wasm (written in Rust) is primarily the thing I am frustrated at here when I see hundreds and thousands of Rust code. A concrete example: creating a Websocket client in Javascript/Typescript vs in Rust/Wasm.

In general though (outside of Wasm), Rust is less readable.

And with regards to Rust errors, I've found Rust errors related to Tonic and Diesel to be quite annoying/unreadable. The Diesel docs seem to blame Rust for this (can't find the docs for it right now).

Isn't this due to wasm having to access browser things mostly through browser JS interfaces?

eg Browsers provide JS functions that are intended for JS, which are not directly exposed to Wasm. So when your Wasm wants to access DOM things, access DOM functions, (etc) it needs to go through a JS shim layer instead of being able to call them directly.

If the browser dev's (or some W3C type of body?) introduced those same functions, but had them be directly accessible from wasm, then the JS shims wouldn't be needed.

The JS dev's for each of the browsers though would probably try and stop it ("security risk!" excuses, etc) though, as that would potentially cut into "their territory" and allow other languages to compete. :(

Expanding WASM to the DOM is definitely part of the roadmap. The problem at the moment, as I understand it, is that the DOM was designed with Javascript in mind, and figuring out how to translate that into something that works well for lower-level access is difficult, particularly in regards to getting garbage collection to work properly between WASM-land and JS-land. There are some alternative solutions that are being explored, but none of this has anything to do with security risks.

I hope you're right, and it does end up happening. That would very much enable many languages (LLVM based ones anyway) to become practical alternatives to JS for web dev, whereas now they're more like "can be sorta done with significant effort". ;)

Btw, my impression that it would be blocked by JS people involved in the process, was from a conversation some time ago with one of the JS people themselves.

They said (from their point of view) there's no need for WASM to directly access things instead of going through JS, and they'd block it themselves if things went that direction. Security was the lever they mentioned they'd probably be able to use.

I believe the project is called Interface Types.