Go is a great programming language(drewdevault.com)
drewdevault.com
Go is a great programming language
https://drewdevault.com/2021/04/02/Go-is-a-great-language.html
50 comments
> 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.
Definitely a great engineering tool.
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.
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.
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.
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.
I kindly disagree in many respects and have chosen not to use go after having rsi from a large project using it.
I understand many people feel different but I've been permanently turned off from it.
I understand many people feel different but I've been permanently turned off from it.
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.
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.
*debounce Stupid autocorrect.
That's not what's called a thinking error, it's a personal opinion. Just like yours
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.
Does Go meet that definition of simple?
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?
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.
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.
Pick your tools.
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.
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.
colesantiago(1)
I agree.
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.
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.
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 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 :)
Java has a massive head start. For its age, Go has caught on quite well.
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.
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'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.
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, 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?
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?
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.
You kinda skipped the relevant part of my question.
Does arguing on the internet with Java fans increase Go's usage at hypothetical person's work?
Does arguing on the internet with Java fans increase Go's usage at hypothetical person's work?
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.
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.
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.
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.
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.
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.
> 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.
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.
It bothers me when people treat it as obvious that exceptions are bad for programming languages. Go programmers love to do that.
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.
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 depends greatly on the task.
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 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.
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.
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.
> It is like Python in that it is modern
That's a funny bit, what is modern about Python? A 30 year old language that predates even Java?
That's a funny bit, what is modern about Python? A 30 year old language that predates even Java?
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).
Yeah I haven’t had any new to me technology that I needed to integrate with where I couldn’t just get some Python lib to do the heavy lifting.
[deleted]
[deleted]
> 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.
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.
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.