I say this as someone who has had a lot of criticism for Rust: Rust definitely borrows a lot from other languages, but Rust deserves praise precisely because it curates the right features and composes them in the right way. There are way too many languages from the PLT space that add some neat type system innovation, but they fail on syntax or performance or tooling or etc. That's not particularly laudable IMO, but Rust has great tooling (cargo, rust-analyzer, rustfmt, rustup, etc), great performance, great safety, and a bunch of type system innovations (including its approach to memory management) which were probably picked from the PLT world. The individual features are neat, but Rust is much greater than the sum of those borrowed innovations. Choosing what features to use and which to omit is a much more valuable task than any individual innovation.

Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.

I haven't used clangd since the early days, but rust-analyzer hasn't been anything other than reliable for me (which is pretty impressive considering how often Rust changes as a language and how new rust-analyzer is).

I would respectfully submit that time spent pushing your toolchain from more than one direction confers many benefits, of which a realistic appraisal of the strengths and weaknesses of the various tooling options is but one.

Um what?

Maybe it's just that I don't understand what clangd provides that's so great, but rust-analyzer, despite a few hiccups I've had with it, seems completely amazing at what it does.

Well we could start with the fact that it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890 (it’s always LLVM’s fault, I know). Or move right along to the insane configuration hacks that are mandatory if you want anything upmarket of VSCode (who doesn’t need a little practice with their Emacs Lisp), or the N^2 whatever that happens when you point it at bindgen output.

What clangd does is work.

> it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890

So -- this guy used an extension (named Rust) with rust-analyzer, a configuration known to not work, it didn't work(!), and the extension author recommends he tries the extension made for rust-analyzer.

Hardly a case for the ages. Guy uses unsupported config and things don't work?

> What clangd does is work.

Don't doubt it. I'm just saying -- I haven't had any problems with the rust-analyzer extension since it became the Rust default. But, yes, I had a few hiccups and crashes beforehand, no doubt. I just have to imagine it's both younger, and doing more/different things than clangd.

You linked to an issue from over a year ago to support your case? And the solution in that issue was just "switch to the right extension"? That's hardly a compelling argument. By all appearances, that person’s environment was completely broken since they reported the other extension did nothing at all, and a broken environment isn’t really a reflection on the tool. I can set up a broken environment for any tool and then complain about it. The absence of a bunch of other people encountering the same issue in that thread indicates this was not some big issue with rust-analyzer.

If I search for "Rust" in the VS Code Extension Marketplace, it shows the extension you linked to... but it is clearly marked as deprecated, and VS Code won't even let me install it. So, it’s even more of a non-issue today than it was a year ago.

The actual rust-analyzer extension works fine for me. I think Go's tooling is slightly better in my experience, but both are far better than any experience I've had with C++ tooling.

The other comments have pointed out this was a simple misconfiguration that was easily fixed.

What I take exception with is "it’s always LLVM’s fault, I know". If you're going to trash other people's hard work in such a glib manner, it behooves you to know the details of what you're talking about. Tell us, why would a language server that doesn't generate any code use LLVM?

This thread is a bit stale but I try to check once or twice a week to tie off loose ends. I appreciate that probably no one will read this, but, you never know.

One of several issues around engaging with the Rust community at least as personified on HN is that it's very difficult to see any other outcome than being backed into a pretty extreme corner: I started my involvement with this thread saying that I like Rust and want to like it more, but found taking a piece of software that seems interesting on its own merits and headlining the Rust part (whether due to the original post authors or the submitters, makes no difference) contributes to a skepticism-inducing sense that there's an agenda other than "cool software" sitting close to "Rust" in the embedding space.

And, if you care to, you can watch me go from "Rust is cool, great stuff written in it" -> "hey some of these claims are seeming extravagant" -> "ok let's not get carried away, the cited examples are mostly Haskell semantics and clang optimization" -> "alright I'm calling bullshit that all the tooling is superior, that's fucking stupid" give or take. It's a pragmatic cool programming language that people write great software in. That's plenty, that's more than most languages ever achieve, and Rust is far from done achieving things.

`rust-analyzer --version` reports: "rust-analyzer 2022-04-11" on my primary Nix shell. `clangd --version` reports "clangd version 13.0.1" on the same env. I drive both of these things on the command line, in CI, and via `emacs` (on `eglot`) every month at a minimum, every week almost certainly, and usually every day.

I have seven nontrivial elisp `defun` and/or `defadvice` (deep into `rustic-mode`) stanzas for keeping `rust-analyzer` working ok. I have to defeat it's naive `Cargo.toml` search in interesting projects, I have to turn off big blocks of my buffer going RED ALERT RED while a brace remains missing which is statistically most of the time, and most importantly, I have to manually restart it with save excursion trickery so that I can survive a crash without blowing my session. Some of these defects may be as old as earlier this year when I last audited all that.

For `clangd` I have zero such nonsense. Which is completely understandable, it's an older and therefore more mature piece of software. That's not a knock on Rust or `rust-analyzer`.

But I made the fatal mistake of posting the wrong link to the issue tracker, for which my reward was to cause the "Flying Fucking HN Rust Brigade Gangbang Comment/Downvote Battalion" to put the Batman light on.

If you folks are comfortable being the "extremists people are too tired to fuck with", then do you. But I know for absolute certain that I am not the only person doing some level of Rust adoption in spite of this bullshit rather than because of it.

".. but rust-analyzer is a dumpster fire next to clangd.."

Sorry, but this is patently false and is just straight-up misinformation. rust-analyzer is an extraordinary piece of work with careful, well-thought out idiomatic software design, easy usage and relatively low productive defect count.

Rust, the language, itself might be rather over-hyped here on HN - its most loved status will drop significantly with larger real-world adoption. However, the rust-analyzer project isn't overhyped and is a clean and elegant product of software engineering. I wish I was good enough to design and code language software like this.

"Constraints as power" describes the proposition of all statically typed languages. But the compilers of popular languages weren't smart enough to cover many common scenarios, forcing language designers to offer many unsafe escape hatches.

It’s a very valuable thing to be able to separate the mental model one uses from the target machine language.

I worry about the more ardent Rust enthusiasts because it seems popular in those circles to embrace an attitude that we’ve somehow arrived at the right conceptual framework.

Rust is a competent, pragmatic embedding of a few of the big ideas from serious PLT into a well-optimized C++ compiler toolchain, and it’s cool and useful as a result.

But I hope to God it’s not the endgame on fast ML/Haskell/Lisp.

I'd be disappointed if the best language people are writing software in when I retire (perhaps a decade or at most two in the future) is Rust. We can surely do better.

But I'd be even more disappointed if the best language people are writing software in when I retire isn't even Rust.

To be successful a language still has to be approachable to most dev. I just hope you are not conflating PLT with Functional. Look what functionalist did to Scala... It had an interesting balance and they destroyed it.

Interestingly Object Pascal was my introduction to data type modelling for constraints, followed by Caml Light, Modula-3 and Ada.

Naturally one can argue they weren't popular, with exception of Object Pascal.

Yeah, specially when people refer to stuff taken from ML as Rust "features".