Hacker News Reader

Comment by nitrix | Hacker News Reader

It's always the same thing.

People find a language/library too complicated, so they go on their own to write a simpler version, only to find out that they missed very important cases that prevents it from having the same qualities.

Grudgingly, they then gradually re-introduce what they initially strongly opposed against, but now they also have to work around their current design and bogus abstractions that wont let that happen easily.

That's going to create a lot of cruft, edge cases and API complications, to the point where a bystander might decide it's too complicated and, they too, go on their own write a simpler version.

Go hasn't learned a single thing.

View on HN

> Go hasn't learned a single thing.

How do you explain the success then?

Go hasn't tried to be all things to everyone. There are lots of things out there that need simple solutions and Go provides for that with and nice middle ground of dev and computer performance.

If I want to read from one computer, write to another computer, concurrently, with low footprint, and speed, it's a great tool.

If Go has learned nothing, are Go programmers just picking something more difficult that performs worse? I've found it has dislodged services that were previously written in Node, Ruby, or a whole J2EE stack. Sure there are people out there trying to make it all things to everyone and it fails in some of those things, but it does great at others.

> How do you explain the success then?

A megacorp funding 100 engineers to work on the compiler, libraries and tooling for 10 years

In other words, the same way you explain the success of eg Java.

Java was a safer C++. Go was a safer C. They both ignore a lot of good ideas from other languages, but I find it easier to forgive Java given its age and how much it’s caught up.

Java also had multi-billion dollar marketing campaigns.

Either Go is a horrible language that did not learn anything or it is a language developed by some of the best engineers for a long time. If you are claiming that both things are true, then how do you explain it?

Google engineers are not some demigods or mythical geniuses and people should stop thinking that. They are successful within the framework of what they know, which is mostly C and C++. None of these people have academic background in language design, and it shows.

I suspect that much of Go's popularity stems from one thing that's completely unrelated to its language design woes: its ability to generate standalone binaries with minimal dependencies (and specifically none on Linux, which is prevalent for container use).

Go itself is not particularly simple, actually. It's simplistic, meaning that you have to jump through more hoops to do common things. For a concise example, consider adding an item to a slice in Go vs adding an item to a collection in pretty much any other modern language.

Two anecdotes why I hate the way they went with //go:generate as workaround.

Borland first attempt to C++ "generics" was the initial release of Borland International Data Structures 1.0 (BIDS) around 1990, where they used the preprocessor to generate multiple copies, something like

    #define LIST_T int
    #define LIST_TYPE MyIntList
    #include <bids/list.h>

Rice and repeat for all required types, when BIDS 2.0 came out this was already replaced by experimental templates support.

Around 2005 it was common to use Eclipse EMF framework, alongside plugins to generate Java code (<= 1.4) that would create type safe subclasses from collections with Object.

So learning is a hard process, then again this was their point of view when C was created,

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

But at least it keeps grad students busy in the programming language departments ;). Imagine that all we had was Haskell and maybe a strict variant of it. These guys would quickly run out of topics that could be explained in less then 5min to a casual developer.

I’m not denying that there are a lot of difficult concepts and million dollar words in advanced functional programming but I will say that I personally took years to understand what was going on with OOP when I was learning programming. Functions made sense, classes and objects and inheritance and subtype polymorphism did not.

Pure functions are incredibly simple thing to understand, much like an algebraic equation you provide inputs and get an output.

There's a lot to love and learn from functional programming.

Times and paradigms change. We need to thank these people or we would still be using Java EE

More importantly the hardware changes and the patterns designed to plug platform shortcomings would have to go away.

I rather use JEE, now JakartaEE, as Go as yet to offer anything that has parity with it.

Reply on news.ycombinator.com