Hacker News Reader

Comment by afandian | Hacker News Reader

I recognise this, and its cousins, from the JS world. It seems to say "how can we possibly innovate without churn!".

But I have been absolutely bowled over, and inspired, by the Rust tooling. Not only helpful error messages, but hints about misunderstandings you might have had, along with concrete suggestions on how to fix it.

I feel like it corresponds to the highly rigorous thought that has gone into the language, which also results in a great language irrespective of the tooling.

Thank you Rust team.

View on HN

> I feel like it corresponds to the highly rigorous thought that has gone into the language

I'd say it's less about rigorous thought, and more about being willing to spend time on purely user-centric things.

You can have both of course, but surely things like proof assistants have a lot of rigorous thought put into them, yet the error reporting is usually horrendous.

Improvements to Rust's error reporting is the result of a specific and dedicated effort in that direction: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com... (and https://internals.rust-lang.org/t/new-error-format/3438 and https://web.archive.org/web/20160807033841/http://www.jonath...).

And note that the new errors didn't really provide more information (at least initially), instead they formatted the information better, removed redundancies and noise, and called out the relevant bits more clearly. This runs very much opposite of "rigorously" dumping all the stuff you have and letting the user sort it out.

You clearly have more experience with Rust than I do, and maybe you set the bar for 'rigour' higher!

In languages like Python, where you might run into an issue caused by not have implemented an arbitrary method on a callback, or Obj-C where you might have forgotten to implement a delegate, you're on your own as far as the compiler is concerned.

Yesterday my Rust code didn't compile because I was missing a bound on a type parameter on my function that I passed though into the key type of a hashmap. Rust said "hey maybe you want to add this constraint to your declarations".

Some of this you can put down to dynamc vs static. But beyond that, it's clear that the designers and contributors haven't just said "we want to make a language with great safety" but then went on to ask "what specific ergonomic challenges will this bring to users, and how do we help them" .

I don't think you could get those ergonomics from many other languages, even if you wanted, without extra static analysis.

(edit: lazy typing on a phone; in the last para I was referring to the mainstream languages like Python rather than the whole universe of languages.)

> I don't think you could get those ergonomics from many other languages, even if you wanted, without extra static analysis.

You absolutely could. Hell, languages which are much simpler to analyse have worse error reporting, and the language which started the movement of having less shite error message is a fairly simple one: https://elm-lang.org/news/compiler-errors-for-humans

That was a typo on my part -- I meant languages like Python, not the whole universe of languages. Of course anything is possible, I'm sure there are very good languages out there, and that Elm is one of them.

Android is at the other, far end of the spectrum.

So much so that we have separate technologies to write in Javascript and then build it for Android (PWAs).

The server-client equivalent would be writing one codebase, in one language and building for browser, and server separately. Despite server-client predating Android by decades, that still does not happen.

It's a bit of a rant - but I hate anything that comes with IDE - I face greater cognitive load in undertsanding the IDE than writing logic.

People used to use GWT to write Java and ship JS to the browser. Now with WASM this stuff might be coming back.

+1 on Golang on this front for rarely creating any confusion on any front, really.

I shudder to think about the next time I have to do npm decency upgrades. Even worse when you have synchronize typescript types. Which requires reading through random GitHub issues to realize that you need to pin a random @types package to 1.20.30 because that’s the one that magically worked for a commenter with 20 thumbs-up reactions.

Hehe I tried to freshen up my frontend coding after 5 years break. Man was I up for a surprise. Reasonml project throwing typescript errors at build time bluh

From the article:

Gradle does not do any user research. It never sits down with independent developers, newbies, or seasoned pros. It never tests its error messages. It doesn’t do developer relations. It doesn’t spot bad implementations in the wild and offer helpful suggestion. It doesn’t relentlessly focus on making things easier for users.

Many times I wanted to just ask some library/framework authors that very question, like ‘hey, do you know what real apps using these paradigms look like? Do you think it’s okay for even the most basic apps to look this mutant?’.

The ergonomics of developer tools/libraries is an underrepresented topic. Some would even call it taboo since so many of us don’t want to appear as if we don’t know how to use a technology. It stops us from giving valid feedback in many cases where something is truly unintuitive, or painful to use.

Maybe this needs to be taught more in universities.

JavasScript (and PHP for example) is an ecosystem with low barrier to entry and large popularity, combined with rudimentary and bad platform (historic reasons) - it's a recipe for piles of shite.

The amount of signal to noise is low because of low barrier/high user base community spamming NPM packages/and spamming ratings/stars/dependencies - it's hard to determine what's "safe" to use, and because the environment is so barebones you need to depend on a lot of third party code or reimplement everything yourself.

C++/C have a similar legacy burden and barebones platform (although C++ std lib now-days is much better, historically it was unusable which lead to a lot of code duplication) but because the barrier to entry is much higher I'd say an average C++ dev is much more competent than average JS/PHP dev and the libraries commonly used in C++ world are obviously higher quality than JS/PHP (tooling fragmentation is a different story because of the unique problems C/C++ face, but still C++ build tools are probably the most sophisticated out there - out of necessity).

Rust falls in to the category of languages designed by competent people without legacy burden and tackles a complex domain (again higher barrier to entry), most languages I've seen in this category have decent tooling and design (eg. C#, F#, Go, Dart)

Rust has definitely set a new bar for systems programming languages.

Regardless of rust's design in particular, static safety and lifetime management is now non-negotiable, and rust's error messages definitely lead the way although everyone else's are pretty good now.

If D and Rust had a baby I wouldn't anything else.

Rust is great. However, because of the ease of creating crates (packages), it seems to be beginning to suffer the same fate as Node and node_modules, with authors bringing in crates (just a `crate install` away) and ending up with ludicrous compile times for the end users.

I definitely agree - this is a problem that is not evenly spread across all programming languages and IDEs. Javascript is easily the worst offender. Java/Android are right up there with it.

Reply on news.ycombinator.com