If I were to build a list of the reasons I use go, it wouldn't be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language.
You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages).
So for future language designers (or existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box "good enough" performance.
I use go a lot now. However, I must admit I find the use of interface{} "aka empty interface, aka void*" a weird one. It's technically correct, but it's an odd semantic.
> But interestingly, while I program go every day, I sort of hate it as a language.
I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
>But interestingly, while I program go every day, I sort of hate it as a language.
I would be interested in asking you to put some of these thoughts down. This can be contentious as it's matters of taste (i.e. I don't want others to reply to you defending it), so if you wanted you could email me - my contact is in my profile. Just a few thoughts -- i.e. what you had in mind when you wrote that -- would be really helpful for me.
I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this.
That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.
Ultimately, programmers fall in a bell curve. Most languages which benefit extensively from that research target people on the right of that bell curve. Go, with its lack of complicated mechanics targets the middle of the bell curve.
I don't have the luxury of working exclusively with people on the far right of the bell curve, so I'll end up picking Go with its simplicity for most projects. I can be assured that almost anyone can pick up code written in Go, and be productive much faster as a result.
> I wish there were better languages that had such nice tooling
Have you considered that the reason why go has such great tooling is precisely because of its desperate grip on simplicity and non-configurability -- the very things you might call upon as why it's "bad".
While I neither love nor hate Go - I'm really confused about "Go gets tooling right". Is it mostly about the built-in gofmt and compiling to binary? Dependency management is far from right, for example, and so are stuff like hot code reloading, remote debugging, containerized development, etc. How does Go get tooling right compared to, say node/npm or java?
Google doesn't invest heavily in Go. It almost certainly invests more in JS, Python, Java, and C++. I think the difference is philosophical--Go doesn't pretend that every obscure edge case deserves equal support to the main case, and so its tooling is much simpler.
Does someone want to give a reason for down voting this comment? There isn’t anything controversial here. For myself, lack of genetics are enough reason not to use the language. My personal style relies a lot on them and I don’t see myself sacrificing that power for above average tooling.
I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works.
One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools.
Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions.
I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else's code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else's code to figure out if it's buggy or you're using it wrong, it is priceless.
There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-)
(I'll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it's not like it's impossible.)
I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscore
My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought.
But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference.
Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.
My background - self-taught in C, wrote BASIC to make money in High School, learned Java (and used professionally). Eventually ended up with Ruby (Rails). I developed my own LISP-like for many years.
Now most of my hobby programming is in Go. I really like it's connection to C. You feel the connection through to lower level programming. I also like the emphasis Go both emphasizes data structures and is first-class with functions. The combination of the two are really easy for me to navigate, but extremely expressive too.
It feels like a language that is very grounded in the fundamentals as I see them, but with a modern outlook and tooling. It feels amazing to write a web-based application with the power of C, but feeling confident you're not going to blow your own foot off every step of the way.
> I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores
A lot comes down to preference and which language you're used to program, but here is an objective fact: having to reach for the underscore key with your pinky finger on shift is a hassle, especially when you have to do it so often.
I suspect it accelerates exposure to carpal tunnel syndrome too.
In contrast, the uppercase letters required for camel case can be done either with two hands or with one hand but without reaching as far as you need to to reach the underscore key.
Go is an alternative for C (for services), PHP, and server-side JS. I don't understand why people keep comparing it to languages like C++, C#, D, Java, Rust, or Scala. The problems these two sets of languages solve are fundamentally different.
"for all the deficiencies Go has, it is somehow highly compatible with the way my brain works."
I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite pleasant for a non-trivial subset of programs.
The short answer is that it has a lot of features that people, generally not being used to them, work better than people may realize from the bullet points and often work together better than people realize. Favoring composition over inheritance is a legitimately good choice. Being able to declare interfaces that other objects I don't control conform to has a lot of little effects that you wouldn't anticipate in advance, to the point that while I understand the bondage&discipline impulse to require code to declare what interfaces it supports, I would consider that a legitimate mistake in most of the languages that do that. (In practice, it turns out the problem of "accidental satisfaction" basically doesn't exist. We learned that from the duck typing languages like Python and how they never really had a problem with that.) And while the grand concurrency stuff may seem neat, the little stuff can be nice too; just yesterday I wrote some code that takes a list of servers to query for some particular thing, and it was easy to write it to do them all simultaneously; that wasn't a Grand Architecture thing, it was just a function that casually did something that is a royal pain in many languages. (There are also languages that can do it better; I actually know many of them. Erlang would be roughly a tie here and Haskell could look really awesome if you put a bit of work into it. Elixir might beat Go, not sure, but I know Erlang itself doesn't.) And there's some other things like that.
The other thing about Go is that I like it for work, but not necessarily for my hobby. The thing about all those restrictions in Go that apply to me is that they symmetrically apply to my coworkers. As much fun as a more powerful language can be, it becomes a lot less fun when you've got dozens of developers trying to work in one code base in those languages; what is power for you is power for them, too, and, well, let's just say they are not always going to be the most expert developers in the world. I've seen... things. And at times, I've even been the one who did the "... things". So even though I know how to use Haskell productively and generally correctly, I'm generally very uninterested in introducing it into the team environment that I have. This is, IMHO, a very important point that I don't hear discussed often enough.
Basically, if you take HN's opinion of "Go is useless and should be wiped from the face of the Earth" as a scientific theory that predicts how useful it would be, the theory is falsified. It is useful and some of us even enjoy it for certain tasks. But I for one would never suggest it is useful for everything and actually frequently warn people off from certain tasks.
The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn't add much when compared to other languages. Maybe that's a pragmatic choice, but it feels short-sighted to me.
With the exception of channels, Go doesn't add much when compared to other languages.
It doesn't add things, it takes them away, notably exceptions, inheritance, generics. I disagree that's short sighted, it's precisely for long term maintenance that it becomes important to have less ways to do things. You may not agree with the choices, but they are not only about being easy to learn, more about being easy to read.
It matters for large teams and when you got hundreds of languages to choose from. I am sure Haskell is great but after a couple of weeks studying it I realize I don't have time for something I don't know if will pay off or not. In contrast with Go you can see benefits almost immediatly
> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times.
Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs.
And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost."
So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties.
This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes.
Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library.
I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.
As Sandy Metz once said, "A little duplication is far better than the wrong abstraction."
After a decade of OOP indoctrination and misuse, we see the results of this.
> Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible
This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.
Regarding your last paragraph, it's a reflection of the state of the industry. The vast majority of "software engineers"/"full stack developers" can't be bothered to learn new skills or improve their existing ones, so any popular programming tool is stuck catering to the least common denominator.
Do you carefully review your own code? Do you voluntarily learn any new skill beyond "blog post intro tutorial" level? Do you think about the consequences of a change you make beyond the immediate need it addresses? Congratulations: Regardless of talent, you're already better than ~90% of professional programmers. You're a "10x developer" by virtue of the fact that by a reasonable baseline of quality the remainder are "0.1x developers" or worse.
I don't think that Google is wrong to focus on mitigating the damage that the majority of engineers will inflict on a codebase. In fact it's depressing how right they are, and what the realities of software engineering look like at scale. It confuses me though that small teams select tools built to solve those problems.
>This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes.
A certain demographic can't stop waxing erotic about "being in the flow" and so love nothing more than churning out 1000 lines of mindless boilerplate, for this chunk endless if-nil checks are a feature not a bug because it's rote and adds to the line count.
When Java was first introduced, the world was abuzz about this cool new language which you could "write once, run anywhere". It took some time, but as it grew in popularity, articles started appearing about how much Java sucked because it was slow and bloated, required a ton of boilerplate code, and eventually because "write once, run anywhere" turned out to be a myth, along with a boatload of other reasons. The honeymoon wore off, and legions of Java-haters were born.
Perl suffered a similar fate. When it came out unix was just surging in popularity with the internet boom and a lot of people were thrilled to have a single language you could learn which combined the features of common command-line tools like sed and awk, and that was a "real programming language" that was more powerful than shell scripting, and which grew to have a ton of useful libraries in the form of CPAN. Years later, and Python and Ruby started getting popular, the "Perl sucks!" mantra sprang up and the once-mighty Perl shrank before the upstarts.
Ruby and Python are getting their turn now, and I'm starting to see some people expressing hate towards them as well, though it hasn't quite reached the pervasiveness of Java and Perl hate yet.
Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What's not to like. Well, the replies to this post are showing that for some the honeymoon is already over.
Other languages had their day in the limelight, only to wind up being hated: C++, Lisp, Fortran, Cobol, HTML, Javascript.
Bjarne Stroustrup observed that "there are two types of languages, the ones everyone complains about, and the ones nobody uses."
Whenever some shiny new language comes out, promising to solve everyone's problems in some domain, and people start jumping on the bandwagon and singing its praises to high heaven (which seems to happen ever couple of years), I try to take a deep breath and step back. There will likely come a day, before too long, when they too will be subject to hatred and scorn, just as all the other popular languages before them.
> Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What's not to like. Well, the replies to this post are showing that for some the honeymoon is already over.
As someone who has paid attention to this since Go was released, there never was a honeymoon. The complaints in this thread have been the same exact complaints people have been lodging against Go since 1.0 was released.
What you're seeing is very simple to explain. Some people love Go. Some people like Go. Some people dislike Go. And some people hate Go.
I've been using Go for a while, and am frankly amazed at the quality of the tooling.
I'll add something others haven't mentioned... the profiler produces an absolutely amazing graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this.
I think regardless of how each one of us sees Go, its adoption among DevOps (Docker, K8s), Apple and Microsoft means that just like with C and JavaScript it will become unavoidable to use it for certain tasks.
I'm kind of wondering about why is there no production ready JavaScript/TS to exe compiler that packages all dependencies and creates a single executable - like go.
With the amount of mind share that js ecosystem has, I thought that would be a thing.
Wow this is extemely close to my own reasons for having a preference for Go. Very well articulated. The clarity of Go code can not be empasized enough. To be fair my favourite languages are Julia and Swift but that neither can really math Go in clarity and simplity.
I know a guy who used to teach Haskell at a university who now runs a development shop at a startup that uses Go. From I recall his main reason for choosing it was to hire cheaper less experienced developers. I remember talking to him about Go and he remarked something like: If you want to clean modular code don’t use Go.
Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency.
Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete.
To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1]
I wouldn't list the standard library as a great strength of Go. While some parts of it are quite good, some others are terrible. Notably, logging and argument parsing are pretty bad. Compare Go's "flags" and Python's "argparse" for example. And Go's "log" and Python's "logging". The Python versions are not perfect but are at least quite usable. In Go, I have yet to see a project with more than 1k lines of code that won't use a third-party argument parsing and logging package.
For logging, each package will use its own logging mechanism. Sometimes, you are lucky and you can pass your own logger (with a random interface as the interface is not part of the standard library either). Sometimes not.
For a language born less than 10 years ago, this is a pity.
What would convince an avid Python user to switch to Go st this point? Let’s narrow down the scope to an API backend to be more specific (isn’t that’s where Go’s performance thrives?)
I haven't looked at Go yet, but all these "is so easy to learn" and "generics are bad because they're not easy to learn" articles on HN, I have to wonder if this language is really so great or people push it because of the politics of people making it.
[+] [-] kasey_junk|8 years ago|reply
You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages).
So for future language designers (or existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box "good enough" performance.
[+] [-] jwilliams|8 years ago|reply
I use go a lot now. However, I must admit I find the use of interface{} "aka empty interface, aka void*" a weird one. It's technically correct, but it's an odd semantic.
[+] [-] kazinator|8 years ago|reply
To programmers under twenty five. And that explains not only Go, but volumes of computing history.
[+] [-] cyphar|8 years ago|reply
I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
[+] [-] secure|8 years ago|reply
I agree with the sentiment you expressed: the overall experience when using a language matters to me much more than individual language pros or cons.
[+] [-] hota_mazi|8 years ago|reply
The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).
[+] [-] logicallee|8 years ago|reply
I would be interested in asking you to put some of these thoughts down. This can be contentious as it's matters of taste (i.e. I don't want others to reply to you defending it), so if you wanted you could email me - my contact is in my profile. Just a few thoughts -- i.e. what you had in mind when you wrote that -- would be really helpful for me.
What makes you hate the language?
Thanks so much for any thoughts.
[+] [-] steinuil|8 years ago|reply
That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.
[+] [-] int08h|8 years ago|reply
I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings.
However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.
[+] [-] falcolas|8 years ago|reply
I don't have the luxury of working exclusively with people on the far right of the bell curve, so I'll end up picking Go with its simplicity for most projects. I can be assured that almost anyone can pick up code written in Go, and be productive much faster as a result.
[+] [-] infogulch|8 years ago|reply
Have you considered that the reason why go has such great tooling is precisely because of its desperate grip on simplicity and non-configurability -- the very things you might call upon as why it's "bad".
Maybe this correlation is more than coincidental.
[+] [-] rdsubhas|8 years ago|reply
[+] [-] weberc2|8 years ago|reply
[+] [-] lanestp|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] krylon|8 years ago|reply
One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools.
Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions.
I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else's code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else's code to figure out if it's buggy or you're using it wrong, it is priceless.
There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-)
(I'll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it's not like it's impossible.)
[+] [-] pavlov|8 years ago|reply
My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought.
But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference.
Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.
[+] [-] jwilliams|8 years ago|reply
Now most of my hobby programming is in Go. I really like it's connection to C. You feel the connection through to lower level programming. I also like the emphasis Go both emphasizes data structures and is first-class with functions. The combination of the two are really easy for me to navigate, but extremely expressive too.
It feels like a language that is very grounded in the fundamentals as I see them, but with a modern outlook and tooling. It feels amazing to write a web-based application with the power of C, but feeling confident you're not going to blow your own foot off every step of the way.
[+] [-] hota_mazi|8 years ago|reply
A lot comes down to preference and which language you're used to program, but here is an objective fact: having to reach for the underscore key with your pinky finger on shift is a hassle, especially when you have to do it so often.
I suspect it accelerates exposure to carpal tunnel syndrome too.
In contrast, the uppercase letters required for camel case can be done either with two hands or with one hand but without reaching as far as you need to to reach the underscore key.
[+] [-] fnl|8 years ago|reply
[+] [-] jerf|8 years ago|reply
I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite pleasant for a non-trivial subset of programs.
The short answer is that it has a lot of features that people, generally not being used to them, work better than people may realize from the bullet points and often work together better than people realize. Favoring composition over inheritance is a legitimately good choice. Being able to declare interfaces that other objects I don't control conform to has a lot of little effects that you wouldn't anticipate in advance, to the point that while I understand the bondage&discipline impulse to require code to declare what interfaces it supports, I would consider that a legitimate mistake in most of the languages that do that. (In practice, it turns out the problem of "accidental satisfaction" basically doesn't exist. We learned that from the duck typing languages like Python and how they never really had a problem with that.) And while the grand concurrency stuff may seem neat, the little stuff can be nice too; just yesterday I wrote some code that takes a list of servers to query for some particular thing, and it was easy to write it to do them all simultaneously; that wasn't a Grand Architecture thing, it was just a function that casually did something that is a royal pain in many languages. (There are also languages that can do it better; I actually know many of them. Erlang would be roughly a tie here and Haskell could look really awesome if you put a bit of work into it. Elixir might beat Go, not sure, but I know Erlang itself doesn't.) And there's some other things like that.
The other thing about Go is that I like it for work, but not necessarily for my hobby. The thing about all those restrictions in Go that apply to me is that they symmetrically apply to my coworkers. As much fun as a more powerful language can be, it becomes a lot less fun when you've got dozens of developers trying to work in one code base in those languages; what is power for you is power for them, too, and, well, let's just say they are not always going to be the most expert developers in the world. I've seen... things. And at times, I've even been the one who did the "... things". So even though I know how to use Haskell productively and generally correctly, I'm generally very uninterested in introducing it into the team environment that I have. This is, IMHO, a very important point that I don't hear discussed often enough.
Basically, if you take HN's opinion of "Go is useless and should be wiped from the face of the Earth" as a scientific theory that predicts how useful it would be, the theory is falsified. It is useful and some of us even enjoy it for certain tasks. But I for one would never suggest it is useful for everything and actually frequently warn people off from certain tasks.
[+] [-] kazinator|8 years ago|reply
[deleted]
[+] [-] wasted_intel|8 years ago|reply
[+] [-] grey-area|8 years ago|reply
It doesn't add things, it takes them away, notably exceptions, inheritance, generics. I disagree that's short sighted, it's precisely for long term maintenance that it becomes important to have less ways to do things. You may not agree with the choices, but they are not only about being easy to learn, more about being easy to read.
[+] [-] emperorcezar|8 years ago|reply
Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.
[+] [-] Thaxll|8 years ago|reply
[+] [-] webscalist|8 years ago|reply
[+] [-] jernfrost|8 years ago|reply
[+] [-] KirinDave|8 years ago|reply
Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs.
And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost."
So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties.
This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes.
Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library.
I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.
[+] [-] treehau5|8 years ago|reply
After a decade of OOP indoctrination and misuse, we see the results of this.
> Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible
This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.
[+] [-] thesmallestcat|8 years ago|reply
Do you carefully review your own code? Do you voluntarily learn any new skill beyond "blog post intro tutorial" level? Do you think about the consequences of a change you make beyond the immediate need it addresses? Congratulations: Regardless of talent, you're already better than ~90% of professional programmers. You're a "10x developer" by virtue of the fact that by a reasonable baseline of quality the remainder are "0.1x developers" or worse.
I don't think that Google is wrong to focus on mitigating the damage that the majority of engineers will inflict on a codebase. In fact it's depressing how right they are, and what the realities of software engineering look like at scale. It confuses me though that small teams select tools built to solve those problems.
[+] [-] Xeoncross|8 years ago|reply
Go is the first language where I can actually access the original socket permission error because it was actually passed up.
[+] [-] Avshalom|8 years ago|reply
A certain demographic can't stop waxing erotic about "being in the flow" and so love nothing more than churning out 1000 lines of mindless boilerplate, for this chunk endless if-nil checks are a feature not a bug because it's rote and adds to the line count.
[+] [-] pmoriarty|8 years ago|reply
Perl suffered a similar fate. When it came out unix was just surging in popularity with the internet boom and a lot of people were thrilled to have a single language you could learn which combined the features of common command-line tools like sed and awk, and that was a "real programming language" that was more powerful than shell scripting, and which grew to have a ton of useful libraries in the form of CPAN. Years later, and Python and Ruby started getting popular, the "Perl sucks!" mantra sprang up and the once-mighty Perl shrank before the upstarts.
Ruby and Python are getting their turn now, and I'm starting to see some people expressing hate towards them as well, though it hasn't quite reached the pervasiveness of Java and Perl hate yet.
Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What's not to like. Well, the replies to this post are showing that for some the honeymoon is already over.
Other languages had their day in the limelight, only to wind up being hated: C++, Lisp, Fortran, Cobol, HTML, Javascript.
Bjarne Stroustrup observed that "there are two types of languages, the ones everyone complains about, and the ones nobody uses."
Whenever some shiny new language comes out, promising to solve everyone's problems in some domain, and people start jumping on the bandwagon and singing its praises to high heaven (which seems to happen ever couple of years), I try to take a deep breath and step back. There will likely come a day, before too long, when they too will be subject to hatred and scorn, just as all the other popular languages before them.
[+] [-] burntsushi|8 years ago|reply
As someone who has paid attention to this since Go was released, there never was a honeymoon. The complaints in this thread have been the same exact complaints people have been lodging against Go since 1.0 was released.
What you're seeing is very simple to explain. Some people love Go. Some people like Go. Some people dislike Go. And some people hate Go.
[+] [-] wyager|8 years ago|reply
Of course Bjarne would say that. The reality is, there are some languages that people use a lot and don't complain about nearly as much. Some languages are just actually worse to use. http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...
[+] [-] chris_st|8 years ago|reply
I'll add something others haven't mentioned... the profiler produces an absolutely amazing graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this.
0: https://blog.golang.org/profiling-go-programs
[+] [-] pjmlp|8 years ago|reply
[+] [-] sandGorgon|8 years ago|reply
With the amount of mind share that js ecosystem has, I thought that would be a thing.
The keyword being "all dependencies"
[+] [-] jernfrost|8 years ago|reply
[+] [-] gmoes|8 years ago|reply
Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency.
Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete.
To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1]
[0] http://www.elegantcoding.com/2012/02/software-reuse-complexi...
[1] https://www.daedtech.com/how-developers-stop-learning-rise-o...
[+] [-] vbernat|8 years ago|reply
For logging, each package will use its own logging mechanism. Sometimes, you are lucky and you can pass your own logger (with a random interface as the interface is not part of the standard library either). Sometimes not.
For a language born less than 10 years ago, this is a pity.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] nnd|8 years ago|reply
[+] [-] ausjke|8 years ago|reply
[+] [-] squeeeeeeeeeee|8 years ago|reply
[+] [-] DinoDano|8 years ago|reply
[+] [-] empressplay|8 years ago|reply