Elm already was the gold standard when it comes to helpful error messages and it's amazing to see that they're still working to make it even better. I hope other languages follow suit.
> Elm already was the gold standard when it comes to helpful error messages
I read this all the time about Elm, but did you actually try Elm for a real world project?
I did, and Elm error messages were one of the most painful point of the compiler: they're beautiful but very often completely unrelated to what's actually going wrong. They actually drove me away from the actual errors more than once.
Good error messages can make all the difference. I haven't worked with Elm, but Rust and Vulkan (through validation layers) also have specific, informative errors and warnings like this.
Both those technologies have well-earned reputations for having not-so-shallow learning curves, but that's almost not an issue when the tools always make it clear what has gone wrong.
We (Rust) took a lot of inspiration from Elm here.
One similarity to this post that sticks out:
> Maybe you just try the JavaScript way to see if it works:
Given that the final syntax for async/await was a bit controversial (postfix .await), the compile folks implemented parsing for (at least) the JavaScript way of doing it, and so you get a good error message telling you the correct way:
error: incorrect use of `await`
--> src/lib.rs:2:5
|
2 | await bar()
| ^^^^^^^^^^^ help: `await` is a postfix operation: `bar().await`
This kind of thing can really help polyglots, as well as people new to the language.
I have not personally had the usecase for Rust just yet, but it is the only language I have never heard a negative thing about. That's huge, with how opinionated developers are.
The arguments for the language and general consensus are so strongly positive that without having used it myself I frequently recommend it (I passively follow the language's progress online).
A huge part of it is the developer ergonomics, a large amount of which comes from your compiler error messages.
When I talk to people about the gold standards, Rust and Elm are the examples I give.
Try to write a small program (a basic interpreter or something like that) and i bet you will have some gripes with Rust... I found that it was an extremely slow language to ramp up on.
Same. I have mixed feelings about it. The tooling is great, but I'm not totally convinced the borrow checker is the be-all, end-all of memory management it's sometimes made out to be. Also some of the decisions around syntax are questionable to me, like lack of top-level-inference just feels like a step backward compared to languages which have it. Also while the trait system and macros are really powerful, a lot of times how they are used by libraries seems quite magical, and it takes a lot of digging through documentation and sometimes source to really understand how things work.
Still in spite of that, I think it's an awesome project with a lot of enthusiasm behind it, and I'm happy to see languages exploring new ideas getting so much attention.
The lack of top level inference is a key part in getting great compiler errors: top level inference can be convenient, but it also leads to spooky action at a distance errors.
Interesting. I'm sure you know more about it than I do, but in Swift for example, it seems like this mostly results in an error like "unable to infer the type of X in the current context" which is maybe not the simplest error in the world to figure out, but it's really not too difficult to unwind as compared to say, cryptic C++ template errors.
I suppose you can't have everything, but in my experience top level inference makes code a lot easier to read because it removes a lot of noise and redundant information while largely leaving the "intent" of the code in place.
Yeah I mean, it really depends on the exact type system features and implementation, but that sounds like a different error than the kind I'm talking about. For example, consider this code, imagining Rust had type signature inference:
error[E0308]: mismatched types --> src/main.rs:10:21
|
10 | let s: String = bar();
| ^^^^^ expected struct `std::string::String`, found struct `std::vec::Vec`
|
= note: expected type `std::string::String`
found type `std::vec::Vec<i32>`
You changed foo, but the error points to bar, in main. None of this is related to the code you changed. But in Rust today, you'd get
error[E0308]: mismatched types
--> src/main.rs:2:9
|
1 | fn foo() -> String {
| ------ expected `std::string::String` because of return type
2 | Vec::new()
| ^^^^^^^^^^ expected struct `std::string::String`, found struct `std::vec::Vec`
|
= note: expected type `std::string::String`
found type `std::vec::Vec<_>`
This points right to the issue: you're returning a vec, and not a string, in foo.
There are other issues too; global inference and subtyping have problems. While Rust doesn't have subtyping generally, we do in lifetimes...
Beyond all of that though:
> it removes a lot of noise and redundant information while largely leaving the "intent" of the code in place.
Rust's perspective on this is that the type signature is what communicates your intent. It's like a unit test. You write down what you expect, and then the compiler's job is to check that your code does what you said you were going to do. This seems like philosophically at odds with what you expect, which is fine of course, but is probably where a lot of the divergence comes from.
It really stands out with Elm and Rust and is much appreciated.
A human/e interface to compiler errors is critical to me. It means the difference between the compiler being an ally and the compiler being an enemy (or maybe a teacher who thinks you're just a bad student and is going to give you a bad grade no matter what, not that there's any scar tissue there).
Matters the world to me personally in terms of my enjoyment and flow and represents the kind of computing I want to do.
I use shairport-sync on my iMac to stream Overcast from the iPhone. There is a huge latency and the connection drops out every once in a while. This should have been a built in feature.
All guessing of course, but disagree with the insinuation it points to Russians still.
- Rambo is not just a lame attempt at sprinkling in an American cultural reference. It is exactly what an Easter European boy in his 30s would have been looking up to back in the day.
- Other than just Russian security services can find translators. English speaking / translating ability is not a rare, expert-only domain. Could have asked a friend.
I guess at the end of the day, nobody likes to be hacked by a random loner guy. It feels more validating to be targeted by KGB's successor. As it explains away the security failures -- "Well these people torture and kill, should be glad we only got hacked by them, could have been a lot worse ...".
For example:
https://twitter.com/pwnallthethings/status/74852434881898905... No, not every fixed security issue gets a CVE. Not even 1% of them. This is why while auditing a target you'll try to get a copy of the software version they run, and any newer versions to identify patched bugs.
Why is it that .ru intelligence is even pegged as a likely candidate here? Literally nothing pointing towards them, you don't have to be an intelligence agency to pop some DNC boxes.
Crystal: Syntax inspired by Ruby, static types and compiled by LLVM. The standard library is mostly similar to Ruby (I'd say it's better. For example it rack-like functionality and websockets built-in). It's getting a lot of traction in the community.
Sidekiq was recently ported over to crystal and the speedups and memory usage improvements are amazing. There's also an officially supported heroku-buildpack so it can be deployed easily.
But there's a lot of breaking changes in the language (0.18 was released a few days ago with a few breaking changes). I would not use it for a long term project (yet). But for some personal project or prototypes, for example which you'd quickly set using Ruby/Sinatra, I'd choose Crystal/Kemal.
We were shown the TED talk on our first "Professional Communication" class this week. It sounded like placebo from the get-go (like the majority of the most-viewed TED talks).
But hey, who am I to question a Harvard professor?
Thankfully, someone else did.
The thing is, placebo is actually extremely effective... so if you believe power poses are really helping, they probably are! Same with the power of prayer, or voodoo dolls, or whatever...
