Hacker News new | past | comments | ask | show | jobs | submit login

Golang is truely modern C. Popular, "simple" (in the twisted sense) and riddled with landmines. :)



Tell me the language that you're using and I'll find multitude of warts and "landmines".

2 out of 3 listed in the article (scoping of loop variables and variable shadowing) is the same in pretty much every other language, for good reasons.

The semantics of nil interface are surprising on first encounter, but when you think about other possible semantics, it turns out it's the best solution. Or at least I haven't seen a proposal for how it could behave better.


> Or at least I haven't seen a proposal for how it could behave better.

Java and C# just have null interface values compare equal to null. I've never seen this cause problems and have never heard any complaints about this.


But you can not call methods on null interface values. In Go that is perfectly reasonable and safe to do.


That doesn't matter. Calling methods and performing comparisons are two different things. I covered this here: https://news.ycombinator.com/item?id=12522941


Fully agree and not much of a surprise given that the intersect of the set of principles involved is non empty.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Note that Go was invented to address a very specific socio-economic issue that Google was facing.

Go's simplicity is syntactic. The complexity is in semantics and runtime behavior. It is an economic trade off. A language with a 'complex' syntax, such as Rust, is intimidating to the novice and presents a problem of how to 'integrate' a newbie with an evolving codebase written by old hands.

It is true, imo, that ultimtely, the initial cost haircut exacted by languages such as Rust/Scala/Haskell pay substantial dividends, but there is the 'socio-' aspect of the context for you!


Which is why most simple languages created as a reaction to complexity, end up with complex codebases full of workarounds to fill the lack of features.

In Go it is already visible with developers using error handling libraries and code generators.


> Which is why most simple languages created as a reaction to complexity, end up with complex codebases full of workarounds to fill the lack of features.

I agree with this. It is a ~zero-sum game. We note this phenomena in terms of concurrency, system architecture (microservices), as well: deceptive up-front simplicity will exact recurring payments with compound interest :)

Frankly I think this says far more about our [field] (academic to industry) than any specific tool, or language.

We have a problem in this field and we haven't solved it. (My money is on machines writing most of the code in the future.)

> In Go it is already visible with developers using error handling libraries and code generators.

Agreed, but note that while I'm critical of the uncritical embrace of "solutions" that don't spell out the consequences on the proverbial tin (such as microservices), at least they get to float their boat. Consider that lacking this alternative a possibly substantial subset would be sitting on the beach dreaming of sailing :)

/[minor edit]




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: