Hacker News Reader

Comment by Karrot_Kream | Hacker News Reader

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex.

That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could also benefit by getting a better handle on their fundamentals and taking a moment to design their codebase more. As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write.

We shouldn't need to treat the developer like a toddler to get them to write safe code. I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.

View on HN

> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity

As a big Rust proponent, I don't think it makes sense to invoke Rust here. The goal of Rust is to provide a more secure low-level foundation for software; any tools it provides to "ensure data integrity" are in service of that end, and pale in comparison to the sort of correctness that Haskell strives for on principle.

Given that Go is memory-safe (modulo a few concurrency foibles), any software that gets rewritten from C to Go is still a win in Rust's eyes. I know more than a few people in the Rust community who are big fans of both languages (e.g. burntsushi, author of Rust's regex library and ripgrep), and the Rust developers have a lot of respect for the Go authors. Go and Rust have different priorities, and that's A-OK.

Kudos for this insightful comment on the respective merits of Go, Rust and Haskell.

This is the main reason, why in spite of my complaints, I will support any Go project.

The end goal is that the overall software stack should become safer, regardless of what layers one is actually busy with.

I think the big concern is not so much rewrites from C to Go (more or less anything would be better than C), but the fact that there are other choices that'd likely lead to substantially better code which could have been taken but aren't.

> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.

This is a little smarmy, don't you think?

You seem to come ever-so-close to hinting something like "Go isn't fit for writing real applications." Without getting into what exactly a "real application" is, I'll just say I think this suggestion is wrong, unhelpful, elitist, and just generally irritating.

That seems to be an intentional misreading.

The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

And that's an intentional misreading of the Go devs. Read the Go Programming Language or any number of discussions by the guys behind Go and it's obvious that they care about their craft and care about writing real, working applications, while at the same time having a better understanding of what your application is doing. In their view the way to do that is through simplicity, but it's not a design decision intended to create mediocre devs.

Only the most cynical view of the language would see it that way. Just because they don't agree with your programming worldview doesn't mean they are idiots. The fact that people can say smarmy stuff like possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better with a straight face just shows how closeminded and ideological people get about languages. Just because you know what a monad is or use map/reduce/filter plentifully doesn't mean you are a better dev than someone who has spent years honing their skills in an imperative language.

Nobody gets this ideological about natural languages. Nobody in the real world says "Hey, why are you speaking Spanish? It's so inefficient, you should be speaking Mandarin". Just as in natural language, programming languages can be learned and adapted by people of varying proficiencies, and when you "get" their particular way of modeling the world, they become an extension of you and a tool. We should just be happy when people become really good speakers of a language, not whether it is the right one.

Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? Have you seen how clever some of things they've built are? I dunno, maybe some of the original hackers have learned a lot about building complex systems over the last 50 years, and maybe they've got something useful to say.

I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms.

For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf) with faster speaking rates compensating for higher verbosity. In terms of writing systems, though, there's definitely a ton of human potential being frittered away on learning Chinese characters and esoteric English spelling rules, but not much that can be done about it even if the Korean alphabet and German rule-adhering regularity are superior. Programming languages are all faster to learn and are iterated on much more quickly and so the possibility of realistically affecting change leads to ideological arguments.

That was a especially informative reply. Thanks.

Yes, go is a replacement for Java. Google couldn't rely forever on sun forever (see the later acquisition by Oracle and lawsuits with Google). Big companies want to own their main tools.

It's also to separate itself from the Java crowd, which has a rather poor image to a lot of people that google wants to attract.

Better tell that to the Android, GWT, Guava, OpenJDK teams.

Go happens to be a pretty nice replacement for Java in some targeted circumstances, but that is not why Go exists. Go's charter was to address deficiencies of Google's C++ programming environment, not its Java programming environment.

As it happens, outside of (perhaps) Google, C++ serverside development is so rare that Go's strengths aren't very compelling to C++ developers. That Go didn't evolve in the direction its founders expected does not mean that its founders are lying when they explain, clearly and repeatedly, what the original point of the language was.

C++ is addressed by switching to Java. Use Java when you can and C++ when there is no other option.

Java didn't cut it for Google because see my previous post.

I always hated Java but really like Go. Think it's because the Go culture and ecosystem strives for simplicity.

> Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons?

It was Pike himself that stated that as a goal for Go at one of the early Goconfs, because new Googlers aren't skilled enough to pick up C++, Java or Python.

If you wish I can track it down for you.

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

That's the quote people like to jump on. You could read it as humility or a nod to other languages, but it probably wasn't intended to be read as "we've designed a stupid language", and even if Pike agreed with that reading, he probably wouldn't agree that keeping programmers mediocre is a goal or a side-effect of a non-brilliant language. Don't mean to put words in his mouth, but the above quote obviously isn't meant to support anything like:

Which is an extreme criticism, but it's a pretty common assumption in most of these discussions. I mean, look at the most upvoted posts in this thread.

He didn't say they weren't skilled enough to learn those languages - in fact he explicitly said they likely would know those. There's clearly a ton of evidence showing that Googlers can learn them, but having a short learning curve for the new language they're introducing still seems useful.

His quote was:

> "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

It seems opposite of what you mentioned regarding C++/Java/Python.

Not really, because in spite of "probably learned Java, maybe learned C or C++, probably learned Python", Go thin set of features makes a good developer in any of those languages feel like elite.

This is such an old programming language flame war trope that it was probably first written in Aramaic. When I started programming as a teenager and commented on FIDOnet BBS's, people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

> This is such an old programming language flame war trope that it was probably first written in Aramaic.

I love the quip, but

> people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.

This is an inversion of the sentiment being expressed: the suggestion is to use languages that allow you to shift more cognitive overhead to the compiler and tooling. If anything, I program in Rust when I fear that the keeping track of all the little bits Go doesn't help me with will take up too much of my puny human brain.

That's nice and all, but how is it relevant to my paraphrasing of the grandparent comment to clarify the distinction from the parent's misreading?

As the sibling comment points out, you managed to misidentify the trope to boot.

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write.

How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)? This was mentioned in ample detail by Rob in the article. Is Kubernetes not a "productive" system by your definition?

The article is scant on details as to what exactly it was about Golang that propelled these companies to stardom, if it even did that at all. Do not mix causation with correlation, though this goes both ways and I maybe wrong in doubting Golang.

> How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)?

Go was simply the first language to successfully target the niche of imperative, natively compiled, GCed languages. It wasn't the first language of this kind, but the first to have a reasonable amount of adoption/backing. Whatever other flaws it has or had were trumped by the lack of serious competition in this area.

I worry that a lot of developers who have been using languages like Java or C# see Go and immediately feel the need to point out that Go doesn't support language features that they've come to rely on, and so they see that as a weakness or a flaw.

With Go, you're getting a lot of high-level language features like anonymous functions, while also gaining the control that you're not able to get in higher level languages like Python or Ruby or Java.

I think this works out great for cloud computing, where performance is a major requirement, but the technology is expanding rapidly enough that a step up from C or C++ is very necessary.

A lot of the complaints I hear are related to abstractions, too, and I understand those to an extent. I also think that if you're complaining about the lack of generics, maybe you're not thinking about interfaces correctly. A perfect example is the beautiful simplicity that is the [`io.Reader`](https://medium.com/@matryer/golang-advent-calendar-day-seven...).

So, whenever someone says something like the OP:

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.

I take that as meaning, "I've never seriously used Go beyond writing a hello world app. It doesn't have the features I rely on to be productive, therefore I don't think it's a capable language for larger projects."

I will say though, dependency management in Go is hell. I wish Go had something like Cargo.

>I will say though, dependency management in Go is hell. I wish Go had something like Cargo.

This is the number one thing that has kept me from going full on Go. The killer feature of Node was NPM, not Javascript. Unless Golang comes up with something comparable it will forever remain niche.

(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release.

https://github.com/golang/dep

It is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do.

There's a lot of "gotya"s with using dep though.

One that gets me a lot is the fact that I like to commit my vendor folder, just for faster CI.

So if I committed my vendor folder with a copy of "k8s.io/client-go", and then in a different project I imported a package from my vendored project, it would never compile until I removed my local copy of that "vendor" folder, since it's looking for that specific dependency ("my-project/vendor/k8s.io/client-go").

Not sure if I explained that super well.

Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.

I personally like glide more than godep

I think you misunderstand.

If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder.

Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this:

  pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as type "github.com/project/a/vendor/github.com/dependency/pkg".Example

It's not a big deal because if I just remove "github.com/project/a/vendor" from my $GOPATH then the problem is resolved.

because of this, I guess my real complaint here is that "vendor" doesn't seem to be the right word. I'm really just looking for something to complain about.

Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".)

So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is wrong for B.

I would fix it by moving A's main into A/cmd, and vendor at A/cmd/vendor instead. A/cmd can still import all its' helper packages like before, but now B can also import them without getting snagged by A's vendoring because it vendors another level up.

Could that work?

Hmm yeah I think that would be a good option. One potential problem with that is running tests on the individual packages. I believe that the vendor folder would have to be in a descendant folder. So like... "./vendor", or "../vendor", "../../vendor", and so on. If the vendor folder was in "./cmd/vendor", and you ran the test "go test ./pkg/example", it would not find the vendor folder.

My solution was just to not commit the vendor folder, and before the test starts, run "dep ensure".

Oh that's certainly a good point and a deficiency in my design.

But then again if you're only testing H against A's vendored dependencies specifically, you're missing testing it against B's. I'm not sure how you would fix that.

>(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release.

I didn't realize they were working on solving this, that's fantastic. Hopefully it can gain traction.

github.com/golang/dep is actually an already fantastic (and official) solution.

First a note, godep is a different tool then the one you mean [1], that does the same.

> dep still has nasty bugs, but in general these are comparable or fewer to other tools out there.

(From the Github readme)

I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others use the lowercase.

Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all.

So I had to resort to a different dependency management for now, which did some linking to fix the situation.

[1]https://github.com/tools/godep [2]https://github.com/golang/dep/issues/1010

AFAIK it's still not decided when/if it will join the main distribution.

I've not tried it for a while now but last I saw it was even more opinionated about GOPATH than the existing tooling, and it wasn't at all easy to figure out what it wanted me to do. Maybe it's improved since though.

The language that appeals to the masses with low barrier to entry in a niche always wins the popularity contest in that domain. I attribute it to herd mentality; assuming skill has a standard distribution, the average developer herd gets a massive head start.

You can see the idiot friendly language eclipse in popularity in other domains too even though "better" alternatives exist:

- elegant general purpose: python over ruby

- web: php over python/rails

- SQL databases: MySQL over Postgres

- NoSQL: MongoDB over CouchDB/Postgres

Go's just the first mass appeal language in the concurrency performance domain and it just opened the door to a lot of developers who before wouldn't dare play in the space.

Some of the dumber but more popular solutions here are just older ones. And please refrain from starting unsubstantiated flamewars. What's next, editors: emacs over vi ? Colors: black over white ?

PHP has some unique design considerations that make it better suited for web. PHP's main significant weaknesses for that domain would be the lack of a strong type system, lack of strong event based server ecosystem (what reactphp does, nodejs, golang, etc.), and it's slower than Java. It has multiple popular long supported rails alternatives. Python and Ruby have nothing over PHP for web development. PHP has the absolute best first class support for isolated http request handling, live updating only challenged by erlang, standard library designed entirely around webdev, great tooling for building c extensions, widespread cpanel hosting, and composer (pip is garbage compared to composer).

So while you might like ruby/python because it's prettier or because PHP 4 was awful, the idea that one of them is a better web language is totally laughable. If you asked me to define a language better than PHP for web applications, I would have you a long list not even considering python and ruby.

What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple.

You talk about giving the developer tools, but those tools can be augmentations on top of the basic building block that is the language. That way, anyone can build tools for their needs, without complicating the lives of others. No need to build all the tools into the language, that's very constraining.

> What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple.

This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library.

More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.)

The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs.

Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.

But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming same popularity, I think a quality language tool for Rust has more potential to be monetized (just like those for C++) than those for Go, because the former has much higher barrier to entry and hence less competitors.

We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs.

That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semantics like C++ does) can support autocompletion with comparable levels of implementation effort.

Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?

Those three things already work in the RLS. And more: https://www.ncameron.org/blog/what-the-rls-can-do/

Is there an editor that supports jump to definition for macros?

I don't know. I have a hunch that lots of macros still will be better with the new macro system, but we'll see.

Anyway, regardless, there's certainly more work to do! And it's being actively developed quite heavily. For example, it will be on stable Rust very soon.

Thanks.

Developers may not need the sophistication that you describing. In that case it's just wasted effort learning something that is more complicated.

Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex?

> Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex?

Docker and InfluxDB are investor funded organizations that contribute to open source. I'd argue that their success has more to do with the monetary input than anything to do with the language itself.

I don't understand your argument. You can't develop complicated GoLang apps unless you have tons of money? But you can develop complicated Rust apps without tons of money?

That's alright. But are Docker and InfluxDB simple apps or complex apps in your opinion?

The question was not about their success, the question was about wether you consider them simple or complex. You did not answer the question.

an army of "toddler" developers can overthrow a single hero in terms of productivity, and using a "toddler" programming language makes sure that newly joined "toddlers" can understand (and also maintain or upgrade) existing code, so that the army can just keep growing.

Oh I'm not disagreeing there. I prefer not being a soldier altogether though. There's a reason I didn't go into the military.

I'd also suggest that an army of experienced devs is more effective than an army of non-experienced "toddlers". Programming languages and CS fundamentals aren't elite, impenetrable cliques; they can be learned.

They aren't elite, but the latter are already overemphasized and have very little to do with writing quality code or engineering, with some few exceptions.

And the choice of language is incidental for the most part as well.

> an army of "toddler" developers can overthrow a single hero in terms of productivity

Depends on what you mean by toddler.

Golang devs imo are not toddlers. The point seemed to be that golang devs could just learn to write C, which is valid. So could Rust developers. But if that was the goal, you'd think both groups would only be using C.

When I think of "toddler" developers, I think of interns being hired into a company to write code with no experience working under mid-level developers that also lack experience, and 5 years later you have what is called f-ing hell. I've worked at a company like that before, and know someone that worked in a company that was mostly VB developers. Same concept but without interns.

And that disaster situation is going to happen regardless of what language they happen to be working in.

For sure. The problems happen when insufficient experience, knowledge, and leadership is combined with anything.

With enough fuel, fire, and gained wisdom, anything is achievable.

But, 10 kids playing with building blocks can't easily build an automobile, whereas one smart, dedicated engineer with a lot of metal, some tires, and better tools could pull it off. So, tools and resources matter, too.

Nobody is treating developers like toddlers. In corporate environment developers are paid to do what management wants. In more free environments developers can use what they want and if they are not using Rust/Haskell may be they do not find use for it.

With several components we're building in Go I have to say I don't see it stopping us from being too clever, too complex, and too verbose. In fact the workarounds to just get some things done without having a whole lot of duplication are fairly annoying. `go vet` with the strictest settings should probably the default if that was actually the goal.

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.

I write raft based distributed applications in go, it uses millions of raft clusters concurrently just for its nightly tests. That simple app is not that easy.

Introducing too much of such language X is better/stronger than Y propaganda is not helpful at all.

I like Go as a language, for the decisions and trade offs that they made when creating it and for the cross platform bits. Clearly the performance is sharp too.

I just don't find it particularly productive for full stack web work. API's or other high performance interfaces...great though.

Developer productivity is overrated, or at least we have no concrete ways of achieving it. The person who approaches everything with a for loop and doesn't have to even consider whether to use a list comprehension, map and filter, or loop is going to be very productive simply because there is no choice to be made. This is only exacerbated in teams.

You're absolutely correct on basics, and those can't really be worked on unless devs are stripped of everything but basic constructs like the function. Rust and Haskell are too much for the average dev and maybe even good devs

> We shouldn't need to treat the developer like a toddler to get them to write safe code

You'd be surprised.

Have you written anything complex with Go?

Reply on news.ycombinator.com