9 ms·

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 ar

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.

atomical 9y ago
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?
- Karrot_Kream 9y ago
  > 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.
  - atomical 9y ago
    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?
  - foo101 9y ago
    That's alright. But are Docker and InfluxDB simple apps or complex apps in your opinion?
  - usaphp 9y ago
    The question was not about their success, the question was about wether you consider them simple or complex. You did not answer the question.
shabbyrobe 9y ago
Have you written anything complex with Go?
aaron-lebo 9y ago
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
geodel 9y ago
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.
why-el 9y ago
> 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?
- Karrot_Kream 9y ago
  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.
- rbehrends 9y ago
  > 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.
- kminehart 9y ago
  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-seventeen-io-reader-in-depth-6f744bb4320b 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.
h8liu 9y ago
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.
- Karrot_Kream 9y ago
  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.
  - sidlls 9y ago
    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.
- chi18 9y ago
  > 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.
  - mathw 9y ago
    And that disaster situation is going to happen regardless of what language they happen to be working in.
trgv 9y ago
> 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.
- elgenie 9y ago
  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.
  - aaron-lebo 9y ago
    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.
shurcooL 9y ago
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.
- pcwalton 9y ago
  > 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.
  - e3b0c 9y ago
    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.
kibwen 9y ago
> 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.
- ngrilly 9y ago
  Kudos for this insightful comment on the respective merits of Go, Rust and Haskell.
- pjmlp 9y ago
  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.
- peoplewindow 9y ago
  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.
lngnmn 9y ago
Oh, come on! Go is wonderful in some parts. Methods on types (which are structures most of the time), duck-typing and emphasis on interfaces instead of classes gives you almost a statically typed CLOS without classes. In other words, Go is as good as a statically typed C-descendant could be. It is definitely a better C without becoming a farce after "comedy" of C++ (and tragedy of Java).
nyir 9y ago
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.
dis-sys 9y ago
> 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.
brightball 9y ago
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.
icholy 9y ago
> We shouldn't need to treat the developer like a toddler to get them to write safe code You'd be surprised.

atomical 9y ago

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?

Karrot_Kream 9y ago
> 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.
- atomical 9y ago
  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?
- foo101 9y ago
  That's alright. But are Docker and InfluxDB simple apps or complex apps in your opinion?
- usaphp 9y ago
  The question was not about their success, the question was about wether you consider them simple or complex. You did not answer the question.

shabbyrobe 9y ago

Have you written anything complex with Go?

aaron-lebo 9y ago

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

geodel 9y ago

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.

why-el 9y ago

> 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?

Karrot_Kream 9y ago
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.
rbehrends 9y ago
> 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.
kminehart 9y ago
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-seventeen-io-reader-in-depth-6f744bb4320b 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.

h8liu 9y ago

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.

Karrot_Kream 9y ago
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.
- sidlls 9y ago
  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.
chi18 9y ago
> 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.
- mathw 9y ago
  And that disaster situation is going to happen regardless of what language they happen to be working in.

trgv 9y ago

> 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.

elgenie 9y ago
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.
- aaron-lebo 9y ago
  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.

shurcooL 9y ago

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.

pcwalton 9y ago
> 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.
- e3b0c 9y ago
  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.

kibwen 9y ago

> 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.

ngrilly 9y ago
Kudos for this insightful comment on the respective merits of Go, Rust and Haskell.
pjmlp 9y ago
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.
peoplewindow 9y ago
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.

lngnmn 9y ago

Oh, come on! Go is wonderful in some parts. Methods on types (which are structures most of the time), duck-typing and emphasis on interfaces instead of classes gives you almost a statically typed CLOS without classes. In other words, Go is as good as a statically typed C-descendant could be. It is definitely a better C without becoming a farce after "comedy" of C++ (and tragedy of Java).

nyir 9y ago

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.

dis-sys 9y ago

> 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.

brightball 9y ago

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.

icholy 9y ago

> We shouldn't need to treat the developer like a toddler to get them to write safe code You'd be surprised.