I would have assumed to same. Go's ignorance of other programming language work is a fact. And any success is easily explained by the empiracal evidence of programming languages succeeding according more due to their benefactors than their own virtues.
I was an early adopter of Go and used it for some small projects before it hit 1.0. It's a pleasure to use and the ecosystem and the team at Google are top notch. I count it among the most impactful projects that Google has done ... among such accomplishments as Android, Youtube, Search, Maps, Chrome, and Gmail. Go is the bedrock on which thousands of impactful projects, like Kubernetes, Docker, and others are made possible. And those projects in turn empower thousands of startups to create better software.
Hats off to Google for that one. Google has become a sort of lumbering giant but it still does great work.
The thing that shines about Go is its simplicity. It's relatively easy to get started, and to me not having as many whistles and bells prevents high complexity codebases.
> not having as many whistles and bells prevents high complexity codebases.
This is a thinking error I see extremely frequently from golang proponents, and it has never made any sense to me. If it were true, it would mean that forth would be a great programming language to work in to keep complexity low - after all it is an even lower complexity language.
Having an, as I'll rephrase it, anaemic language really just means that people will either limit the scope of what they write in it to low complexity things, or, more frequently in my experience, will simply not bother handling the potentially complex details of what they're trying to do, because it's simply too painful and laborious. Corner cases don't get handled (can you really justify the extra 200 lines to handle that case?), user-facing edges don't get smoothed off (can you really justify the extra 200 lines to be able to handle float inputs to that option?), things generally just get dropped on the floor. And I don't blame people - I get to the end of a day and the idea of having to write yet another for-loop makes me just want to go home instead.
The hair-shirt philosophy of golang is not one I subscribe to.
Things that should be simple are surprisingly complicated in go. If you hit up DuckDuckGo, and search for “golang denounce”, the first two hits are very simple implementations of denouncing a function in go... both of which leak goroutines. I didn’t read past the first two, but I bet you have to read a ways to find one that’s actually correct.
I find reading Go code quite the opposite. It takes a considerable amount of time to figure out that the given 20 lines of code actually do `filter f . map g . fmap sum`, for example. Simplicity in the language means _your_ code has to implement the complexity of the algorithm.
> The thing that shines about Go is its simplicity. It's relatively easy to get started
I think the word "simplicity" needs some quantification, because I think often people mean it's easy for beginners = simple. And that doesn't ring true for my definition of simple.
What I'm more interested in where it is "simple", is that it allows logic that doesn't need to be entangled to remain cleanly seperated so that changes to one need not require you knowing about any other parts of it, and are not at risk of breaking anything else.
And similarly, that if I were to build something with inherent complexity the language would add minimal additional complexity above it.
Brainfuck is “simple”. Much simpler than Golang, even! There’s only eight commands and that’s all you can do. It’s Turing-complete.
Of course this language simplicity means that programming in the language is much harder. To me that’s almost tautological: things the language doesn’t do for you become things you have to do yourself.
Love Go for the batteries include standard library, huge ecosystem, fabulous tooling, and code-linked documentation. Concurrency facilities (but I miss net channels!), easy server creation, performance and lovely dependency-free static binaries are great too.
I personally like go very much and use it for many small internet facing services. Being small and quick (for the compiler as well as generated code) simplifies so many complicated ways to deal with big and slow programs and compilation. But I get the feeling that go is quite uncool and not a definitive hit on its niche (many java based backend still). Do you think Go growth potential ? Id love to but im not so sure.
A lot of major utilities in modern software development are written in Go (e.g. Docker and Kubernetes) so it’s definitely a “hit” by any objective measure. It is not universal like Java but it is an established and mature language that will likely continue to grow.
I don’t think Go is considered uncool - if anything it’s the opposite. Probably fair to say that Go is “cool” for hackers and CTOs but “less cool” for formal computer scientists since its type system is limited (and even then goroutines are interesting as first-class construct). But I like Scheme, F#, and Idris, so don’t take my word for it :)
I really hate the wave of language "competition" and contention. Go is a language that allows lots of developers to get great work done. So is Node.js, so is Haskell, so is Rust, so is Java. The list goes on.
If you find a thing you like, you should use it! If you find a thing you don't like, just don't use it! Find the language that lets you express your intention as easily and correctly as possible and run with it. For some people that is Go, for some people that is Erlang.
I'm certain this thread will devolve into "Go isn't a great programming language because..." type posts, but I really think those posts are kind of ill-intended. The author of this post likes Go, which they're allowed to do, and they should continue using and enjoying it.
I've been seeing this too all over the place. Why do we have to continue break out in this tribal behavior with our identities tied to what language we use. It matters less what language you use than what kind of algorithms and data structures you know, not to mention problem solving skills. And those things can translate to any language.
I'd love for languages to be win/win scenarios, but it does seem they are a bit of a zero sum game. The team you're on will need to pick a language, if it's not the language you prefer you lose, so it's natural to want to influence others.
If you prefer Go, and are on a Java team, you'll want to convince others that Go is far superior, and vice versa.
Indeed. Ironically, the only reason we're in a thread talking about Go is years of "Go is so much simpler than language X" propaganda, without which it would have never gained such a hold in the industry zeitgeist.
Indeed lists 30k Java jobs and 2k golang jobs. OP has a vested interest in marketing their preferred language to increase the availability of jobs for that preferred language.
If more people in the industry appreciate concise and powerful languages that reward deep expertise, I am more likely to find paid work where I can be happy and productive in the future. I started in C, and it’s pretty alarming to see an impoverished language gaining market share after years of progress; that’s why I argue the bar should be getting higher for new languages in production.
I can't help but think that if we all had that mindset, we'd still be programming in assembly. People who don't care enough to criticize the status quo don't put forth the effort needed to change it.
I don't agree. My argument is not that developers shouldn't have opinions, or that developers shouldn't try to improve languages (in the ways any individual developer thinks any individual language should be improved). My gripe is more with those that feel it worthwhile to complain publicly about a language to those that enjoy it. There are more than enough languages to go around - if you're a person that dislikes the Go programming language, rather than trying to make Go enthusiasts agree with you, just go do something else (find a language that you actually do enjoy and build things with it).
> People who don't care enough to criticize the status quo don't put forth the effort needed to change it
Nowhere in my post did I suggest people should not criticize the status quo.
There is a subtle difference between objective constructive discourse and pseudo-religious language fanboyism. The latter happens far more commonly than the former. In fact many who do the latter even believe they're conducting the former when in fact they're misinterpreting their own personal preference as objective fact.
To example this point: the fact that people do still sometimes need write some code in assembly really should demonstrate that your point would be better framed as "different languages serve different use cases so it's pointless convincing everyone to conform to a single language" -- which is precisely the point the OP was also making.
It bothers me when people write a lot of software with hidden jumps in control flow. I want to reason mathematically about the code, not experiment with it to see if it throws these exceptions or retries or what. Is there some layer in the framework du jour that catches them all and spits out an HTTP 200 status html stack trace instead of the expected XML error status?
The objections I personally have against exceptions almost all don't seem to apply for language like Go actually.
The thing that annoys me about exceptions is that they can be slower that you'd think, make safety analysis really hard (i.e. regular control flow isn't too bad, exceptional control flow can be weird), and are a pain to implement. And with Go I don't think of those things as being a priority.
I haven't delved into Go, can anyone vouch for how difficult/painful it is to do simple tasks such as array manipulation? Does it bother you? I've heard that it is rather quite verbose and there should be some easy encapsulations for basic array manipulation, but Go offers no such convenience. What is the shoot-yourself-in-the-foot-ability of Go? As an outsider, Go appears to be C+Python combination but more like C and less like Python. How does it compare to Python+Flask or Ruby on Rails type of frameworks to build web services? I want to give it a try at some point.
It is slightly more verbose than well written Python. I think that puts it a good 5x less verbose than the equivalent Java, tho I have not ported any Java to Go so YMMV.
It is like Python in that it is modern, has a rich set of good libraries to do stuff, a simple method of codes reuse (interfaces rather than dynamic duck typing). You have first class functions so you can write cool call back based Jason transformers or the like. Ten liner Python reformatter is twenty in Go. Still clever and way faster and runs on sixteen or 32 cores with no work, assuming you design the program with the data flow in mind.
I have not written many web services, just one gRPC thing which was the typically slow first use of a new framework couple of days work. Mostly I write network shimmies, eg syslog to Kafka or NAT to squid, or else S3 bucket editing utilities.
The ecosystem is extremely up-to-date and in many areas, among the most advanced languages. No one is leaving Python for a new backwards compatible language. The syntax, while technically old, is quite "modern" because a lot of other newer languages look similar (presumably because of cross-language influence).
If it fits neatly into the built-in data structures or smells quite systemsy and C-like, it's probably fairly easy in Go.
String and array manipulation are similarly painful to C. The lack of generics can be a massive pain in the neck, meaning you end up copy/pasting things, and other people's code doesn't tend to be very easily extensible without actually editing it to add the appropriate interfaces or whatever. The lack of OO is sometimes fine, sometimes not. It's really not a very expressive language. (I appreciate that's a rather fluffy/vague thing to say, but I feel it's true.)
On the other hand, you can cross-compile stuff trivially, you get nice self-contained binaries, it's generally sufficiently performant, and it's simple in the same kind of way C is, only with a garbage collector and easier threading (goroutines are pretty nice).
There's no more ceremony really compared to something like Python+Flask, but the business logic you end up running behind your web API calls _may_ be a bit more verbose and feel clunkier. Or if you're lucky it may not. It's very much dependent on what exactly you're doing.
I think it's a pretty mediocre language because of the compiler intrinsic data structures and functions like maps and slices that cannot be created by the language proper. It can be verbose and tedious, some of the std lib stuff like "context" ends up "infecting" everything (ala async/await), variable shadowing sucks, still has "nil" instead of something more modern and safe like Rust's Result<T>, etc, etc.
If I had designed this language in a "design a new programming language" college class, I'd probably have gotten a C+ for my efforts at best.
What Go is, is a great tool more than a great language. I like to use it because my output from it is usually reliable, is on time, is light on resources, is easy to deploy, and allows me to get kudos at my job and more $$$. It's wonderful screwdriver for today's screws.
But I don't think it's a great language the way a LISP is a great language, or Smalltalk, or Haskell, or OCaml. It won't really open your eyes to a new way of thinking about problems that you didn't already know from your C days. You still have too much interface{} stuff everywhere, or reflection (which is extremely tedious) or pretty-awful code generation compared to LISP macros.
I find my thinking when I did a lot of C network servers was mostly on the state machine. What msgs are needed to do this task and what state needs to be changed to track the piece of work. In Go I design it as a data flow, what inputs, outputs, what channels and go routine pools, etc. the state can be implicit in the local block of the go routine due to the excellence of the run time. And all the cores for free, no sync except to edit hash maps, so design those to be used not per request but less often.
> What Go is, is a great tool more than a great language. I like to use it because my output from it is usually reliable, is on time, is light on resources, is easy to deploy, and allows me to get kudos at my job and more $$$. It's wonderful screwdriver for today's screws.
You are completely right. As a language, Go totally sucks in comparison with other "modern" languages but I think no other "modern" language beats Go when you look for them as tools. Go is a "get things done" kind of language that imposes a lot of constrains on what you can do and how you can do and this limits how developers can express themselves, and it makes Go sucks as a language but these exact constrains make Go excel as a engineering tool because Go code is easy enough to read and understand so it makes your team move fast without break things, fast compilation, fast executions, easy in hardware resources.
> I consider Go not to be a systems programming language — a title much better earned by languages like C and Rust. Rather, Go is the best-in-class for a new breed of software: an Internet programming language. The wealth of network protocols implemented efficiently, concisely, and correctly in its standard library, combined with its clever mixed cooperative/pre-emitive multitasking model, make it very easy to write scalable internet-facing software.
Agree! I've been programming with Python for the past 6 years using Django and have now fully committed to writing Go using only the standard library. It's a great language for web-development and would highly recommend it to anyone.
I decided to use Go for a medium sized CLI app at work. It took me about 2 days to get proficient enough to write the whole thing without googling for every line.
There are many great and REALLY modern languages like Nim and Crystal which have no corporate backing and lobbying like Go.
I should have loved Go but in fact had found it to be very verbosy, boring and mediocre at all lang. Of course it more suited for many tasks compared with Java, C++ or Python but... I still cry when try to compare with Nim or Crystal.
Go has been production ready for years, take a language like Crystal that does not even support threading. Nim and Crystal will always be niche because it's not backed by anyting, the community is small ect ... so you can't compare those languages atm.
50 comments
[ 3.6 ms ] story [ 122 ms ] threadI'm going to assume and account for the the time difference the author posted this on april fools day.
> April 2, 2021
oh ok, you're not joking here. :/
Wow, Go IS serious business then, who hurt you? it was just a joke, not meant to be taken seriously.
I was an early adopter of Go and used it for some small projects before it hit 1.0. It's a pleasure to use and the ecosystem and the team at Google are top notch. I count it among the most impactful projects that Google has done ... among such accomplishments as Android, Youtube, Search, Maps, Chrome, and Gmail. Go is the bedrock on which thousands of impactful projects, like Kubernetes, Docker, and others are made possible. And those projects in turn empower thousands of startups to create better software.
Hats off to Google for that one. Google has become a sort of lumbering giant but it still does great work.
This is a thinking error I see extremely frequently from golang proponents, and it has never made any sense to me. If it were true, it would mean that forth would be a great programming language to work in to keep complexity low - after all it is an even lower complexity language.
Having an, as I'll rephrase it, anaemic language really just means that people will either limit the scope of what they write in it to low complexity things, or, more frequently in my experience, will simply not bother handling the potentially complex details of what they're trying to do, because it's simply too painful and laborious. Corner cases don't get handled (can you really justify the extra 200 lines to handle that case?), user-facing edges don't get smoothed off (can you really justify the extra 200 lines to be able to handle float inputs to that option?), things generally just get dropped on the floor. And I don't blame people - I get to the end of a day and the idea of having to write yet another for-loop makes me just want to go home instead.
The hair-shirt philosophy of golang is not one I subscribe to.
I think the word "simplicity" needs some quantification, because I think often people mean it's easy for beginners = simple. And that doesn't ring true for my definition of simple.
What I'm more interested in where it is "simple", is that it allows logic that doesn't need to be entangled to remain cleanly seperated so that changes to one need not require you knowing about any other parts of it, and are not at risk of breaking anything else.
And similarly, that if I were to build something with inherent complexity the language would add minimal additional complexity above it.
Does Go meet that definition of simple?
Of course this language simplicity means that programming in the language is much harder. To me that’s almost tautological: things the language doesn’t do for you become things you have to do yourself.
I don’t think Go is considered uncool - if anything it’s the opposite. Probably fair to say that Go is “cool” for hackers and CTOs but “less cool” for formal computer scientists since its type system is limited (and even then goroutines are interesting as first-class construct). But I like Scheme, F#, and Idris, so don’t take my word for it :)
If you find a thing you like, you should use it! If you find a thing you don't like, just don't use it! Find the language that lets you express your intention as easily and correctly as possible and run with it. For some people that is Go, for some people that is Erlang.
I'm certain this thread will devolve into "Go isn't a great programming language because..." type posts, but I really think those posts are kind of ill-intended. The author of this post likes Go, which they're allowed to do, and they should continue using and enjoying it.
If you prefer Go, and are on a Java team, you'll want to convince others that Go is far superior, and vice versa.
If you prefer Go, and are on a Java team, does arguing with people that are unrelated to your work on the internet change your working environment?
Does arguing on the internet with Java fans increase Go's usage at hypothetical person's work?
> People who don't care enough to criticize the status quo don't put forth the effort needed to change it
Nowhere in my post did I suggest people should not criticize the status quo.
To example this point: the fact that people do still sometimes need write some code in assembly really should demonstrate that your point would be better framed as "different languages serve different use cases so it's pointless convincing everyone to conform to a single language" -- which is precisely the point the OP was also making.
> reason mathematically about the code, not experiment with it to see if it throws these exceptions or retries
Do you consider `panic` (in Go or Rust) a "hidden jump"?
The thing that annoys me about exceptions is that they can be slower that you'd think, make safety analysis really hard (i.e. regular control flow isn't too bad, exceptional control flow can be weird), and are a pain to implement. And with Go I don't think of those things as being a priority.
It is like Python in that it is modern, has a rich set of good libraries to do stuff, a simple method of codes reuse (interfaces rather than dynamic duck typing). You have first class functions so you can write cool call back based Jason transformers or the like. Ten liner Python reformatter is twenty in Go. Still clever and way faster and runs on sixteen or 32 cores with no work, assuming you design the program with the data flow in mind.
I have not written many web services, just one gRPC thing which was the typically slow first use of a new framework couple of days work. Mostly I write network shimmies, eg syslog to Kafka or NAT to squid, or else S3 bucket editing utilities.
That's a funny bit, what is modern about Python? A 30 year old language that predates even Java?
If it fits neatly into the built-in data structures or smells quite systemsy and C-like, it's probably fairly easy in Go.
String and array manipulation are similarly painful to C. The lack of generics can be a massive pain in the neck, meaning you end up copy/pasting things, and other people's code doesn't tend to be very easily extensible without actually editing it to add the appropriate interfaces or whatever. The lack of OO is sometimes fine, sometimes not. It's really not a very expressive language. (I appreciate that's a rather fluffy/vague thing to say, but I feel it's true.)
On the other hand, you can cross-compile stuff trivially, you get nice self-contained binaries, it's generally sufficiently performant, and it's simple in the same kind of way C is, only with a garbage collector and easier threading (goroutines are pretty nice).
There's no more ceremony really compared to something like Python+Flask, but the business logic you end up running behind your web API calls _may_ be a bit more verbose and feel clunkier. Or if you're lucky it may not. It's very much dependent on what exactly you're doing.
If I had designed this language in a "design a new programming language" college class, I'd probably have gotten a C+ for my efforts at best.
What Go is, is a great tool more than a great language. I like to use it because my output from it is usually reliable, is on time, is light on resources, is easy to deploy, and allows me to get kudos at my job and more $$$. It's wonderful screwdriver for today's screws.
But I don't think it's a great language the way a LISP is a great language, or Smalltalk, or Haskell, or OCaml. It won't really open your eyes to a new way of thinking about problems that you didn't already know from your C days. You still have too much interface{} stuff everywhere, or reflection (which is extremely tedious) or pretty-awful code generation compared to LISP macros.
You are completely right. As a language, Go totally sucks in comparison with other "modern" languages but I think no other "modern" language beats Go when you look for them as tools. Go is a "get things done" kind of language that imposes a lot of constrains on what you can do and how you can do and this limits how developers can express themselves, and it makes Go sucks as a language but these exact constrains make Go excel as a engineering tool because Go code is easy enough to read and understand so it makes your team move fast without break things, fast compilation, fast executions, easy in hardware resources.
Definitely a great engineering tool.
Agree! I've been programming with Python for the past 6 years using Django and have now fully committed to writing Go using only the standard library. It's a great language for web-development and would highly recommend it to anyone.
I understand many people feel different but I've been permanently turned off from it.
Golang is my main language unless I need something quick and dirty dealing with strings, in which case I'll use python.
I want to pick up some rust for really low level stuff, but the rust community is a bit of an opaque cult.
I should have loved Go but in fact had found it to be very verbosy, boring and mediocre at all lang. Of course it more suited for many tasks compared with Java, C++ or Python but... I still cry when try to compare with Nim or Crystal.