Hacker News Reader

Comment by boramalper | Hacker News Reader

> Space shuttle style is meant to ensure that every branch and condition is considered and accounted for…

FTFY: …hopefully!

Only if they’ve used a language with Algebraic Data Types support, the compiler would enforce that “every branch and condition is considered and accounted for.” The only PL with ADT that I’ve used was Haskell, but I’ve heard that Rust has them too “enums”.

People are arguing that “code is what computer executes, comments don’t ensure anything!” and so on, but besides being executed, (this Go) code does not ensure anything either. It’s human eyes that skim through all the cases, and look for a matching branch for every one of them that “ensures.”

In my humble opinion, this so-called “space shuttle style” is just one of the many workarounds to deal with Go’s by-design limitations (the most famous one being lack of generics), a language that’s designed only 9 years ago.

View on HN

> It’s human eyes that skim through all the cases, and look for a matching branch for every one of them that “ensures.”

This a thousand times. The praise in this thread is disturbing.

The absurdity of this code is the logical conclusion of ignoring decades of PL advances in favor of Go's "simplicity."

When you insist on "space shuttle" era language design, is it any surprise when you're reduced to "space shuttle" era programming? I can't imagine anything more fitting.

You are forgetting the tremendous advantages that Go offers for many projects over alternative languages.

There are no perfect languages, that is certain.

I agree with this, but snarky comments like these neglect that ADTs (or generics) are not the only nor remotely the most important factor in choosing a programming language. Go certainly bests Haskell and Rust in many important areas even if it loses in safety.

I wasn’t trying to trash Go!

Two years ago I’ve moved one of my biggest projects from Python 3 to Go because my program was inherently concurrent, and at the time -and I think still- Python has 3 competing approaches for concurrency: threading, multiprocesses (for parallelism), and asyncio.

Although it’s nice to have a variety of options, I think this balkanisation affected the community in negative ways because the options are not compatible with each other (see the emerging “SansIO” libraries for asyncio).

This is actually the reason why Python gets so much praise: thanks to its standard library, there is often a single canonical way to do something (if you need sets use `set`, if you need matrices use NumPy, …), which means that the vast majority of libraries are interoperable* with each other. Same goes for Go when it comes to concurrency, and that’s what guided my choice.

*: high cohesion, low coupling

And I wasn’t trying to defend Go :) Just that I hear a lot of comments like these, but they all ignore the possibility that $IMPERATIVE_LANG is the right choice IN SPITE of the inferior type system. In particular I would love an FP lang with Go’s focus on user-friendliness, simplicity, and practicality.

>It’s human eyes that skim through all the cases, and look for a matching branch for every one of them that “ensures.”

Worse, they've made an exception for simple error checking, and the result is that the majority of the if statements at the top of the file have no else condition. Quickly scanning by eye doesn't help me determine if someone screwed up and missed a scenario.

It was implemented 9 years ago but it could be argued that it was invented in the 1970s

https://youtu.be/eEBOvqMfPoI?t=859

there is a discussion for generics in 2.0

Reply on news.ycombinator.com