Otherwise it's like improving the efficiency of a closet by ripping out the shelves, drawers, dividers, coat hangers, etc... so that it's just one big volume-maximized empty room.
For error handling I tend to write in a style where errors are either asserted out or "folded". If I do several operations in sequence any of them could err, I code in a way where I don't check every single op: instead I make some kind of "error accumulator", or write the code in a style such that if the previous operation failed the next operation will become effectively noop. I then check for errors at the end of the process.
That said, Go is actually right about treating errors as values and not giving special language constructs to throw/catch them.
I guess you can panic/recover in go but it's very very unwieldy and not quite the same.
Errors are still values in Rust - usually as part of the `Result` type - but unlike Go, it actually has tools to let you deal with them in a convenient way, like the `?` propagation operator (https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...), or the functions on the `Result` type like `map`, `and_then`, `map_err`, or crates like `thiserror` for defining error types, and `anyhow` for easily converting them when you don't care about the details.
The try operator and Result type is amazing though.
I don't see a problem with relying on a few super popular basic libraries for almost every project.
if err != nil {
return err
}
But “losing tech” is unproductive when you have to maintain/upgrade your code over many years and onboard new developers into the team.
It is unfortunate that the tech industry’s choice of tools is largely fashion-driven but that is the reality.
- Everything is an expression
- Pattern matching
- Spread in any position
- Dedented strings/templates
However, I wouldn't use it, because the chance of it becoming abandonware that I just have to migrate off of later is way too high. I'll write a few extra TypeScript characters here and there for the stability.
I am certain we're doing the same thing now with Typescript.
The first part was great and deserves credit for pushing the language to evolve. The second part made it a terrible dev experience. My experience was identical to the gp: writing it was fast and intuitive, but reading it was much, much worse. Not just reading other people's code, but even my own: my ability to understand my own code degraded not in weeks or months, but mere days. It was so bad, the overall result was a net negative and I quickly stopped using it. I say this as someone who has enjoyed writing code in over a dozen languages, from assembly all the way to Haskell.
1) Having to learn an entirely new syntax just to save on a few characters (it "decompresses" directly to the original thing)
2) Explicitness vs implicitness/inference
I wholly agree with you about #1 (superficial brevity isn't a very important goal and doesn't justify a whole new language), but #2 is much more of an "it depends"
I also know as a fact that programmers 100x my caliber have nevertheless written great large-scale software without types.
So I don't make generalizations on the human condition and just do what works for me!
But I wonder, if the compiler can get by without it, perhaps we can too? With a different mental model/abstraction, that simply does not need that information - not even by implication. If there is one, probably not easy to come up with.
Like kinematics omitting force (e.g. high school physics, x = x_0 + vt + 1/2at^2). https://wikipedia.org/wiki/Kinematics
I'm thinking of using Civet for an upcoming project, I specially want `do` expressions. Even with how much noise an IIFE (`(() => {doStuff(); return ...;})()`) introduces, it's such a natural idea to me that I end up using them very often.
But what makes me question the idea is having to learn a new syntax that is close enough to the JS I already know that I'm going to get confused constantly.
Why would I care about writing `export a, b from "./cool.js"` instead of `export { a, b } from "./cool.js"`? I don't mind those curly braces, I may actually like them a bit; I do very much mind the overhead of remembering these details when I change languages, and there's no way I can remove JS/TS from my life.
Finally, there's expressions like `value min ceiling max floor`. Is that readable at all? You have to actually read each word to know which are operators, which functions, which vars... It seems to me much worse than `max(min(value, ceiling), floor)` or a Lispy alternative like `(max (min value ceiling) floor).
Redundancy also helps when transmission is imperfect. And you do have imperfect transmission when writing code (typos), and even when reading (skimming text, missing a character).
CoffeScript makes every character count, especially punctuation. It's really, really easy to make a small typo in these. But CoffeeScript eschews redundancy, so the typo becomes another valid grammatical construction, with an entirely different meaning. At best, you get a cryptic translation error elsewhere. At worst, it gets accepted but works differently than you had intended.
APL has this property, too. But an APL program is very terse, you pay attention to every character in a short string of them. It does not feel like Javascript which is traditionally lax in the punctuation and whitespace department, catching you off guard.
CoffeeScript was an interesting experiment, but I'd say its result is negative.
Sadly, with Steve Klabnik's withdrawal from the core Team, the current maintainers are on a path to repeat these mistakes.
Do you recall specific RFCs that are leaning in this direction?
When I actually tried to write a project in coffee script, the results were the opposite of what I expected.
The code was harder to read, harder to modify, harder to understand, harder to reason about.
There's something about removing stuff from syntax that makes programming harder. My hypothesis is this: your brain has to spend extra effort to "decompress" the terse syntax in order to understand it, and this makes reading code unnecessarily difficult.
So I fundamentally disagree with the underlying premise of these projects, which seems to be based on PG's concept of "terse is power".
My experience suggests the opposite: there's power in being explicit. Type declaration is an example of such a feature: it makes explicit something about the code that was implicit.
Type declarations add more to the parse tree, and require you to type more, but they actually give you more power.
The same can be said about being explicit in the language constructs.
There of course has to be a balance. If everything is way too explicit (more so than needed) then your brain will do the opposite of what it needs to do with terse code: it has to spend more effort to remove the extra fluff to get to the essence of what the code is doing.
Being terse is good, up to a point. Same with being explicit.
Languages that try to bias too strongly towards one extreme or the other tend to miss the mark. Instead of aiming for balance, they start to aim for fulfilling some higher telos.