Hacker News Reader

Comment by jacques_chester | Hacker News Reader

> I'm all for opinionated language design, but when you use your compiler to cudgel your coders at the cost of productivity, you lose.

Well, the thing is that in the long run, the cost of any software system is dominated by fixing bugs with high degree of latency. Removing various classes of error by compiler fiat is an approach that is wildly unpopular but well studied.

This sentence might have been written as:

> I'm all for opinionated language design, so long as I agree with the opinion.

And that's fine. I can only speak for myself when I say that while younger me was annoyed that the damn compiler won't get out of the way, older me is annoyed that the damn compiler didn't catch this obvious defect for me.

The difference is that older me is writing less trivial programs and dealing with more existing code and writing more complicated systems.

View on HN

It seems to me that the kind of people that are keen to have their compiler eliminate classes of errors in this way most likely won't be attracted to Go because of its other 'deficiencies', like null/lack of option types, lack of generics, mutability and so on. So it hits an uncomfortable middle point: 'annoying' to use, but still doesn't provide much guarantee about classes of error that most people would consider more serious than importing a module you don't use. (The latter is much easier to implement though, and that seems to have been a big driving force in various decisions about the language)

Disclaimer: I've never written a line of Go, so this is just my perception as an outsider. Go does seem to get a lot of flack from people with theoretical interest in programming languages (think LtU commenters). My speculation is that this is partly pushback against the (perceived) 'Go was created by the smartest guys in the industry' memes, along with the fact that it ignores most of the last 30 years of PL research.

Yes, I remember there was a great deal of wailing and gnashing of teeth when Go first turned up. My personal favourite was the bloke who compared Go to "Brand X" and found that the latter (which is older than C) was the better language, in his opinion [1].

I mean it's not as though using type system technology invented in the 1980s would have been such a stretch for a language created twenty-something years later.

The thing is, though, that Go has gotten lots of para-language stuff right. It ships with gofmt and inbuilt tools for manipulating code, it has decent concurrency out of the box, it compiles and runs fairly quickly. It's really meant to be a better C from a universe where C++ was never invented (I've seen it compared to Limbo, a language developed on Plan9 -- given the heritage, that would make sense).

[1] http://cowlark.com/2009-11-15-go/

> The thing is, though, that Go has gotten lots of para-language stuff right.

If one studies the history of programming languages, one comes to realize that this has as much or more to do with the success of a language than the language itself.

Oh, absolutely. Path dependency is huge, for example.

If any of the static functional languages had this same feature I'd agree - but they don't as far as I know its a warning in them. To me this isn't about "safety" its about keeping code clean. Go doesn't really put much emphasis on safety in the sense that Scala, Haskell or Rust does.

I'm all for compilers that cudgel coders, as long as they cudgel indiscriminately. It's the coddling ones that club you in the quiet moments of the night because you weren't minding your results that I despise.

Reply on news.ycombinator.com