Why Go is my favorite programming language
michael.stapelberg.de
michael.stapelberg.de
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 agree with the sentiment you expressed: the overall experience when using a language matters to me much more than individual language pros or cons.
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 the fact is, in a world where we as developers often are learning and working in a new language every year or two, time-to-productivity and proficiency in a given language is one of the most important, if not the most important, metrics for a language. And Golang knocks this out of the park with its obvious syntax and great tooling. You can bring in a new junior programmer onto your Golang stack and have then turning out useful pull requests in a week or two, which I can't say for languages like Rust.
I _hate_ much of Golang's engineering, but for collaborative programming I think anyone would agree that it's a highly productive language.
Now for a new product that I might sell as traditional installed software, Go makes some sense here since it simplifies install. My clients wouldn't need to install and maintain the VM.
In the end I wonder why switch to a new stack just because? I understand learning the languages to see if they are better tools. I understand learning for the sake of learning. But why bet a business on a new language just because it's cool?
Standing up the app is also instantaneous. Spring boot apps with hibernate often take at least ten seconds. In prod this doesn't matter. But a cheap app start means integration tests are cheap. An fs hook runs both unit and integration tests every time the code changes.
ps. all the things people hate about go are true
If I write a Go server, I'm unhappy if it takes more than 0.2 seconds to start.
My dropwizard server contains almost all possible batteries: ssl, logging, http filters, static content, metrics, DB connection pooling, static content serving, all kinds of URL parameter parsing and URL routing, DI framework, ORM, thread pooling. I think it just inspects and initializes all this data structures in memory, load libraries and classes, etc.
Why should they?
One can always deliver everything together.
Not much different than static linking.
Also there are AOT compilers and with Java 9 we are getting a linker to create customized JREs.
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.
var x int = 5
var i interface{} = &x
*(i.(*string)) = "boom" if (bad_thing)
return ERR_BAD_THING;
... code here to turn off controlled device ...
I said "it's unsafe", not "it's not safer than void*".
> (i.e. exit cleanly without corrupting memory).
This makes no sense. If it exits, who cares if the memory of the process is corrupted?
Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it.
That's the point of static type safety (which Go doesn't provide in this case): it lets you ship code that is provably incorrect and that will not work once deployed (it will exit, like you say).
This is why I said "it's unsafe".
People care when memory is corrupted without the process exiting. It is usually better for a program to crash than for it to continue having corrupted its data. The former gives you x-ray machines which sometimes won't start, whilst the latter gives you x-ray machines which sometimes give the patient cancer.
I say better, not best. Best, obviously, is for as many failure modes as possible to be detected before the code is deployed. Particularly if you're programming a machine that can kill people. But in the comparison between Go's interface{} and C's void*, neither language has that option.
And it's even better to no let this program get corrupted data in the first place, which languages with a weak type system (such as Go) allow to happen whenever you use `interface{}`.
I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you should be talking about.
This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.
package main
import (
"fmt"
"io"
)
type Thing struct{}
func (t *Thing) Close() error { return nil }
func main() {
var x *Thing
var y io.Closer = x
fmt.Printf("x == nil -> %#v\n", x == nil) // true
fmt.Printf("y == nil -> %#v\n", y == nil) // false
}
Go is a strict language, but it's curiously lax about many things, including this. "go vet" won't even warn you that you're unintentionally wrapping nil in an interface. This goes way beyond just a trivial example like the above one, though: Any general-purpose code that has to deal with arbitrary interface{} values can't just check for nils, but need to do things like this:
func UnwrapReflectValue(v reflect.Value) interface{} {
if !v.IsValid() {
return nil
}
if v.IsNil() {
return nil
}
if v.Kind() == reflect.Ptr {
v = v.Elem()
if v.IsNil() {
return nil
}
}
if v.Kind() == reflect.Interface {
v = v.Elem()
}
return v.Interface()
}
I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable implementation of io.Closer. It doesn't even panic. Having a nil-check (i.e. "does this interfaces contain a value?") return true seems dishonest to me.
I agree, that it was a bad choice to call both the zero-value of pointers and the zero-value of interfaces "nil". But in general, the possibility of nil-pointers being valid values and implementers of interfaces is useful. For example if you have a linked list or graph-structure.
I also asked about it on reddit and got this answer: https://www.reddit.com/r/golang/comments/6sktsr/typed_nils_i...
It's not statically type-checked, yes. That's fine too, in my opinion, but also irrelevant for a comparison with void-pointers (because they also don't provide that).
In summary, interface{} is strictly better than void-pointers. Which was exactly my point. Equating the two is intellectually dishonest.
Interesting; for some reason, I was under the impression that you could cast an `interface{}` arbitrarily, but from trying it out, you're absolutely correct. (I should definitely make sure to try these things out before confidently asserting about them...)
> interface{} is strictly better than void-pointers
No arguments here; even if for some reason they weren't type safe (which they are, much to my surprise), I'd still agree with you there.
This seems pretty misleading to me. Sure, it's a hole in the type system, but not a hole in memory safety, unlike void*.
(Even the fact that it's a hole in the type system isn't particularly interesting. Most languages have holes in their type systems, by design. What's important is the amount of use it gets, which is of course somewhat-frequent in Go. Same with void in C, so at the type system level, I agree that there isn't too much to distinguish other than quibbling about frequency of use.)
The number of keywords of a language is completely unrelated to its complexity (see Brainfuck or Lisp).
+ database retrieval and manipulation as a 1st class concept. ABAP doesn't require a 3rd-party ORM and therefore, SQL statements are 1st class syntax.
+ GUI capabilities as 1st class syntax (user interface elements for forms, lists, grids, visual reports, etc)
Golang core doesn't have those, so it understandably doesn't need extra official keywords to address that functionality.
SAP ABAP has more keywords that's typical for a 4GL type of language. Like other business-domain 4GLs, the complexity isn't the language syntax -- it's navigating the gigantic data model to find where important information lives. (e.g. Out of 10,000 tables, where does the sales invoice live? If an invoice is paid, where is that status field? And to make it harder, many of the database column names are German instead of English ... like AUGRU[1] for "auftrag grund" instead of English "OREASON" for "order reason".)
If Golang language spec was revised to include a 1st-class ORM and GUI & report builder into its core syntax, it would be a more apples-to-apples comparison. Golang can have less keywords, because it has less features.
So, you are saying… because it's less complex?
"Complexity" is not a useful label unless you look at what you're actually building:
- If the goal is to show "hello world", yes Golang is "simpler".
- If the goal is an ERP system, Golang is way more "complex".
Between those 2 extremes requires analysis on a case-by-case basis.
I could bootstrap a .Net/Java/whatever app to do the same thing, but our team is swamped with a backlog years long - I could only afford a couple days to develop and release this so a dozen Force.com licenses ended up saving tons on development and ongoing maintenance costs.
To programmers under twenty five. And that explains not only Go, but volumes of computing history.
I’m some way past 25 these days, but if there is one lesson I’ve learned about programming languages over the years, it is that a good supporting ecosystem usually is worth more than even quite substantial improvements in the language itself. It’s not that language improvements aren’t welcome — I think some programming languages are much better than others. However, you’re always going to be limited in how productive you can be with a language that lacks comprehensive libraries or good tools or enough people using it to discuss interesting issues or hire a full team of staff, no matter how brilliant the design of the language itself might be.
I don’t know what the worst mainstream programming languages are today, but in purely technical terms surely C, Java and JavaScript all make the shortlist. Compared to many other contemporary languages, these three all lack features, often take a lot of code to get quite simple things done, and are full of easy ways to make mistakes. And yet, in terms of how much useful software has been written in them, they are among the most successful languages we’ve ever had. Why? At least in part, I think it’s because they have three of the most well-developed ecosystems around them.
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.
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.
The typo/autocorrect here turns this into a much more controversial statement...
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.
No thanks.
interface{} is like Object, if it even exists once in your code, it's broken.
You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do:
if foo, ok = collection.get().(Foo); !ok {
return errors.New("expected a Foo")
}
Seriously, this is why generics exist. I want to write it once, use it everywhere again, and want to have the compiler know if I made a mistake.
1. Using an interface would nuke your performance. Data structures where every data structure operation requires one or more vtable lookups on items in the structure can really hurt your time and space performance. To get good performance, you need true type-level generics so the compiler can specialize at compile time.
2. Anyone could put anything that followed the interface in the data structure, even if it was of the wrong type. To get any form of static type safety, you'd still have to define a wrapper type and a bunch of functions for every type you'd want to put in the data structure. You could save a bit of work by re-using your (slow) code you wrote generically using interfaces.
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.
No, it targets the less experienced - interns, as the language creators said.
Go is a safe programming language, but it is not simple. Go has very rigid rules.
I don't see any difference in complexity between programming in C and programming in Golang. Programming in Golang may even be harder than C.
If you format your code wrong, Golang screams at you.
If you import a package and never use it, Golang screams at you.
If you redefine a defined variable, Golang screams at you.
If you don't use a variable you defined, Golang screams at you.
C is much more forgiving :).
Golang makes dynamic memory management safe, but in nowhere easy. You still use the good old void* via an empty interface. For an intern, garbage collection doesn't matter, an intern is intelligent enough not to leak so much memory so that it will get noticed :).
I sometimes think Golang resembles the early versions of Java. Creating a safer C-like language, with great ideals. With Java the complexity kicked in after a while. Golang still resists the urge to please everyone.
EDIT:
Found it, https://talks.golang.org/2012/splash.article
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
"They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike
I think this is confusing being permissible with difficulty. Because C is permissible, it makes writing correct code in it hard. The fact that the Go compiler has a (relatively) simple type system and is able to point out mistakes like the ones you mentioned makes it much easier to write correct code.
I'd also just like to point out most of the things you list about Go won't cause a crash or undefined behaviour if you were able to leave them in anyway.
As pointed out elsewhere in this thread, interface{} isn't the same as void. void will let you reference anything as a type unsafely leading to undefined behaviour. interface{} carries type information, and while it does cause crashes, it doesn't lead to undefined behaviour.
Also, how is memory management in C easier? Leaking memory is the least of your worries, you could double free, null ptr access, invalid free, have dangling ptrs, etc. Lots of these things are taken care of by Go's GC so you don't have to worry about it.
That gave it away.
- Paid some of the most celebrated engineers to work on it full time. - Support it as a first class language in GCP - Support it as a first class language internally
If you want to see a language Google doesn't invest much into, look at Dart
At any rate, Go's tools don't require significant investment because they are designed for simplicity (there is no package repository, no language-agnostic/fully-imperative build scripting language or project metadata files, no bring-your-own-unit-test-framework, no docstring syntax, etc). Go tools err on the side of supporting too few use-cases, where Java, Python, .Net, C++, etc build tooling typically emphasize explicit configuration over sane defaults.
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.
Turns out pretty much as he says (see given example at play.golang.org). You just type in the style you always have, but with the certainty that in the end it will be the same as the other's, easy to read, easy to maintain, and uncontroversial in terms of formatting. You could agree on google-java-format, I guess. But also potentially waste plenty of time on the decision itself :-) compared to a dictate and tool originating from the language itself.
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.)
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.
It is a pointless but easy thing to debate about. I find Go's solution of de facto forcing a certain style on everyone a little harsh, but it is effective.
> It would be trivial for editors to support either style
Emacs has glasses-mode which displays underscores in camelCase identifiers without changing the source code. It's not the most elegant solution, and when I first heard about it and gave it a try I was working on a code base that used both camelCase and under_score, so glasses-mode actually made the code more confusing, because I never could be sure if the underscore I saw was actually there. But on a code base that uses camelCase consistently, it might help.
My point, though, was that it does not really matter that much - if you come from an underscore_heavy_background, it takes some getting used to, but that is all. Once one is used to it, the consistency across not just my own code but the entire ecosystem really pays off.
> the concept of word separator inside identifiers
That sounds like a very interesting idea. But I think it is probably nearly impossible to introduce into an existing language without breaking a lot of stuff. Perl[56] maybe, there is a package to program Perl in Latin, and if that degree of craziness is supported, I am sure it's possible - it just won't be pretty.
Lua comes to mind as well, because in Lua an identifier is just a string used as a key for hash table that holds the local environment. This is exposed to Lua scripts, with enough cleverness one might add something there, too.
And there's probably a couple more that I missed. ;-? Has anyone actually done any experiments/research in this area?
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 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.
I for one was a very passionate Oberon user and Niklaus Wirth is well known for its minimalism design goals, Oberon-07 is even more minimalist than Go.
Just because I used to program like that almost 20 years ago, doesn't mean I still enjoy using such minimalist languages.
Also, I can't help but point out that I didn't say I enjoy it for all uses either. I don't do my hobby programming in Go, because I don't have the issue of other programmers doing things I disagree with or don't like. Even if I do something stupid in another language, at least it's my stupid thing and so I tend to understand it better than somebody else trying to come in and see it.
My team is starting several new projects in go, where in the past we used either java (and I actually liked java typesystem) or nodejs (and I liked that one as well).
I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics?
Or is there a different style I should adopt?
By using it in its core domain, network servers, where you don't tend to use generics very much. I've observed that generics seem to be less useful when you're almost always only one transformation away from your data even having just been or being just about to be a simple []byte buffer.
"I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics?"
Even if Go had generics it would probably still be a language where you write for loops.
I'm exceedingly iconoclastic on this point relative to the rest of the world: I don't believe "declarative" languages exist. As far as I'm concerned,
reduce(func(x, y) -> x + y, 0, [1, 2, 3, 4])
for _, val := range [1, 2, 3, 4] {
sum += val
}
I am aware of the compositional arguments; my counterargument is that the only language I've used that is slick enough for the composition to end up being useful is Haskell, where the example I gave is
foldl (+) 0 [1, 2, 3, 4]
(You can "win" in Javascript by using that sort of style to compose promises together or whathaveyou, but then, in Go, you're always writing at the promise level, so that doesn't matter.)
Basically, when composing two functions together is any harder than x . y, it's just not something people do.
However, your mileage may vary.
In javascript that would be:
Promise.all(list_of_servers.map(query_server))
You still won't have to add very much more stuff, but you're not going to be that much shorter than my Go in the end, either.
People like you are missing the point.
Yes, you can write anything in Go and with "interface {}" everywhere in your codebase. Like you can write anything in Javascript and not care about type safety since it's weakly typed.
However, not caring about compile time type safety with a compiled language is intellectually lazy. I'm talking about both go designers and developers here.
People want generics not for the sake of it, they want it because they want to write compile time type safe code, that's what generics are, just types.
"interface {}" everywhere isn't "caring about compile time type safety". It's using Go like it is python. What's the point of a compiler if the programmer has to do its job? that the issue with Go. Too much stupid run time tricks for a statically typed language.
Generics exist for a reason, a modern statically typed language who doesn't implement it is broken. And just like people are productive with PHP, anybody can be productive with a broken language. So the productivity argument is a fallacy. Go is the PHP of statically compiled languages. In fact append,delete,make,copy being native functions is no different from PHP implementing hundreds of native functions in its global namespace. It doesn't look good at all.
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.
I'm afraid I fail this intelligence test. What problems are solved by C, Go, PHP and server-side JS but not by any of Java, C++, C#, D, Rust or Scala (and vice versa)?
This seems like a completely arbitrary classification to me.
To expand on this, imagine building some complex application framework with these web-oriented languages. Without decent abstractions and insufficient typed programming support (see e.g. TypeScript to JS transpiling, or writing your own preprocessor macros to simulate generics in Go to avoid having interface{} everywhere, etc), and certainly no support for annotations, macros and other meta-programming techniques. Yes, not all of that high-level stuff is great and takes time to master, and so I understand the niche of Go & PHP & ss-JS: You need to quickly scale up your web services startup, which is often poorly paid work, and so you can't afford experienced developers. Having a simple, common, easy web services development language where you can hire any freshman and get them productive is great. So I'm not saying Go is bad or useless, but it only fits a (big - even, possibly the biggest in software engineering) specific case. ASP, PHP and Node.JS et al. are horrible compared to Go at that, but were the options you had before Go came along, so it's a godsend for web developers.
I hope that explains why I don't see Go as comparable to complex, high-level languages - and in no way in competition with them, in fact.
But I see very little in terms of features or problems they solve that distinguishes Java, JavaScript, Go, Scala and C# from each other when it comes to writing Web backends. It's essentially a cultural choice. So comparing them (and many others) is totally fair game in my opinion.
So in a way, we agree, as that was my whole point - Go & it's predecessors (ASP, PHP, JS, ...) are mostly only good for Web backends: E.g., literally all Go developers I know personally are either fresh out of college or ex PHP programmers, ASPers and JS hackers, and all work exclusively on web development stuff. (But my sample size is maybe a dozen companies, so that's possibly biased, I agree.)
All of these languages are direct competitors in a number of areas today (Web backends, infrastructure services, database systems) and based on language/runtime capabilities (as opposed to cultural and library availability) I see almost no area where there is no potential overlap in the future.
Also, what a language is currently used for and what it is good for are two completely different things. There was a time when Java was mostly used for Applets and desktop user interfaces. It wasn't good at either.
Plus, as said, Go's language "facilities" are a long shot from Java/Scala/C#'s, while having GC can be prohibitive in other areas (C++, Rust, embedded systems, real-time transaction processing), and some areas (e.g. space exploration) even need the ability to change the runtime code on the fly.
I did not claim that at all.
What I dispute is that the set of tasks for which both Go and Java/.NET are suitable is so small that it makes no sense to compare them.
People often have a choice of using Go, Java, Scala, C#, etc, for the same task and that is why a comparison makes perfect sense.
I do agree that Go has made the life of legions of PHP and Node.JS developers easier. And it is nicer to do web development in Go rather than C and Python.
However, claiming that Go "eats everybody's lunch" is rather outlandish.
I didn't say it was. I said comparing Go to Java or C# is useful because these languages are suitable for many of the same tasks.
What you are making of this pretty uncontroversial statement is mind boggling.
Can Go replace C#? That's MS land and comes with the .Net platform. I think nobody will think Go is even remotely gathering its following from C# and the amount of tooling you get there is probably the largest set you can get.
What about Java? That has 20 years of entrenched Enterprise usage. So to make a dent on that, it not only has to have equal languages facilities, it also needs an equivalent ecosystem (maybe?) and, crucially, has to be better: Java replaced C++ as it's a much better fit at what it's used for due to GC and "no" resource management. But I certainly don't see anything that Go does that makes it much better over Java as Java was in it's day over C++.
So no, I don't see Go replacing .Net or the JVM anytime soon.
I never claimed that Go is seeing any significant uptake in Java's or C#'s historical strongholds. I'm not talking about current usage at all. I also didn't say that Go is going to replace .NET or the JVM. I didn't even say that Go is better at anything.
None of what you keep going on about has even the slightest thing to do with the point I was making.
My point is very simple: Go, Java, Scala, C# and their most widely used implementations have similar enough technical capabilities to be useful for many of the same tasks. Therefore it is useful to compare them.
Go vs Java meets these criteria. That's all I'm saying.
>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.
Your claim was that there is no overlapping area of application and hence comparing the languages makes no sense. That is where we disagree if that is still your opinion.
Besides, I see abolutely no reason why Go couldn't be used for writing something like Cassandra, Kafka, Spark, Hadoop or a core banking system. None of these are specifically Web backends. Equally, I see very little reason why Docker or Kubernetes could not be written in Java or C#.
As to transactional processing, there's a reason why that's not using GC languages and why the banking and oil industry are one of the few mainframe clients left. Just because you can do X with Y, it doesn't mean it's economically or technically feasible.
In my opinion there is only one significant technical dividing line between language implementations: Mandatory automatic garbage collection.
No other purely technical characteristic makes a whole lot of difference for the sort of problems that can be solved with comparable results using different language implementations.
That's why it doesn't make much sense to me to put Go in a different basket than Java or C#. Doesn't mean there is no reason to prefer one over the other of course.
All you need to decide on now is if you prefer syntactic simplicity over percieved feature boat, if it's a web development project or not, and if you can benefit from existing code in your language of choice or not.
Pick at least 2/3 to decide... :-)
JS is used for GUI tasks too, so your point seems totally arbitrary. Java is heavily used to write servers and services as well.
> I hope that explains why I don't see Go as comparable to complex, high-level languages - and in no way in competition with them, in fact.
Javascript and PHP are complex high-level languages as well. Your point doesn't make any sense. Go is the way it is because it was designed that people who rejected 30 years of type theory. But now they have a problem, because they repeated the same mistakes as C and now they are planing to break everything with Go2? they just quietly admitted they were wrong, it's time to admit you are wrong as well.
There are very few projects for which you couldn't use Go, JVM and .NET languages equally well purely on the basis of language and runtime features (ignoring hiring, library availability and other cultural aspects)
We learned that the goroutines & channels concept isn't that bad an idea, but that it doesn't prevent you from stumbling over weird race conditions in large, distributed systems. Beyond that, at best one might argue if the lack of nearly all advanced programming features in Go is in itself a feature or a shortcoming.
However, I think that depends more on your personal preference on programming styles, so there's not much more to be learned from arguing about that. So that is why I see there's little that can be learned from any such comparison beyond what's well known already.
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.
A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us".
I can't seem to shake the feeling there must be a better way.
What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?
For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).
My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software?
Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development.
With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.
I'm feeling for answers. I'm not saying I know what we need. I am, like I think everyone else is, still in the observation stage looking for hypotheses.
I did find evidence based software engineering. This offered some interesting papers. I recommend this. There isn't much and it's far away from a cohesive theory but hopefully we can get there, as a field, soon.
If someone is further along, or has some ideas, I'd love to speak with them.
We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.
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.
s/exceptions/error handling/
What Go proposes is awful for a modern language.
There are always error cases to check when handling user input. It's a natural part of the program flow, not really an exception.
I would expect an 'exception' to be something like out of memory or disk corruption.
https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...
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.
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.
Sure, but that's OO's fault and the lesson is not "abstractions are bad" but rather, "OO's good at domain abstractions and bad at universal abstractions."
The takeaway should not be to discard the last 12 years of advances in computer science and call it quits with a bad copy of Erlang's concurrency model and a weak version of C.
> This lends me to believe you actually haven't written any go code for yourself.
I've written about 5000 lines. So not a ton, but enough to have shipped Go to prod and be capable of reading it.
> This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before.
Go is more OOP-focused with its weak interface{} methodology than anything I promote or have used joyfully in the last 6 years. Even the most cursory examination of my presence will reveal that.
Please don't put words in my mouth to tidy your argument.
like writing 500 * if err != nil { return err } is an average Go app? A little yes, but this isn't a little.
What is insane is believing returning errors is actually handling them, it is not, you're just passing the burden on the caller.
Second, Go isn't free of all the bullhshit you described so I'm not sure what is your point, that you don't have to write getters and setters in Go? lol, off course you do have to.
> Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching
Who cares, go back playing Pokemon since apparently that's the only thing you can think off and stop being an hypocrite. What do you think panics are? yes, it's an half-baked exception system, like everything in Go, a language designed by people who clearly didn't know what they are doing, for people who don't.
> Sorry, the if err != nil horse has been beaten to death already
Yes, and don't worry, people will keep on beating that horse, because it was designed by people that clearly don't know what they are doing.
A little exploration is better than a false dichotomy.
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.
Do you have any resources for getting better at this? I don't get a lot of chances for other people to review what I write (yeah believe me I know..) and am looking into better ways to make sure I don't release shit.
I have a decent amount of testing automated for a majority of my projects but that's turning into an extra job on-top of my already demanding job.
Read every checkin twice before committing it. I find and fix many bugs by doing this.
Keep a log of errors and problematic APIs. Periodically review your code for methods and idioms that you tend to misuse. I find it easier to spot one incorrect call to an API when looking at all uses of it.
Enable all compiler warnings and use warnings as errors. It is easier to spot regressions when the build is normally silent. If a project has a noisy build then use the normal warning level and enable additional warnings over time.
I have a hard time being this cynical. I think post-educational market forces drive this trend, not the personal inattentiveness that I sense (perhaps unfairly, please correct me) that you blame.
Go is the first language where I can actually access the original socket permission error because it was actually passed up.
I can't think of a single language except C where this has been a problem for me. What are you referring to?
Much bad can be said about checked exceptions, but they certainly helped with that problem...
Now try to trace them as easily as exceptions. Oh wait, you can't unless you wrap Go errors into some struct from a library that isn't in the std lib therefore everybody has different systems to trace errors /s
i'll take exceptions over this (which go has, panic/defer). error is just a convention, it's not an error system.
Because I felt nothing but frustration at most libs I worked with. I (as others before me) ended up grepping error strings.
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.
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.
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...
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.
Certainly from the very beginning, there'll be some subset of the relatively few people who've actually tried a new language who don't like it for some reason or another, or object on legitimate technical grounds (the border between these two types of objections is murky).
As the popularity of the language grows articles are written, starting in the specialized press and (if the language is lucky) ending up even in the popular press, getting even non-technical managers excited and using the newest buzzwords.
With time, the recognition and consciousness of the language's deficiencies become more widespread among a wider portion of the programming population, and articles and discussions of such complaints become more widespread.
In the end, such complaints may become mere truisms, and the majority of the population just parrot the truisms and stereotypes while having only a superficial or even non-existent familiarity with the language that's criticized.
Of course, you could say that such things were going on all along, but it would be missing the broad ebb and flow of language popularity and people's reactions to them.
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.
No idea how they are using it.
Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC.
Sure, but at the same time it creates awareness in other companies that Go is a good bet that they might adopt as well.
> Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC.
They went with Kotlin.
Dart is still looking for a killer application beyond supporting AdWords, lets see how far they go with Flutter or Fuchsia.
Given that they are written in Go, and as far as I understand it, the way to customize them also requires using Go.
With the amount of mind share that js ecosystem has, I thought that would be a thing.
The keyword being "all dependencies"
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...
One thing I wonder about is a seeming complementary anti-pattern, the "Expert Only Language". Perhaps C++ is the only language that truly fits this description, but one can see shades of it in Haskell, Scala & Rust. To a limited degree, Bash and SQL exhibit similar qualities, because people can use them for years but barely know them.
These are languages where a certain confusing richness is accepted as the cost of doing business, and where a long period of familiarization is assumed to be necessary before doing basic things.
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.
- Good concurrency primitive (channel), although asyncio Futures in Py3 aren't that bad either
- Strong typing
- Easy byte-level manipulation
- Extremely easy to learn
- Simplistic error handling compared to exceptions (there are problems with this I won't go into, but it's easy to learn at least)
- Amazing tooling (gofmt forces your codebase to be consistent regardless of who is writing it)
Sticking with python still, for the time being.
As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.
That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.
Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?
If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.
Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.
Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.
Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it).
Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening.
If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`.
This is something I really miss in the JS and Go and C and C++ world. It all just works.
This seems like a ridiculous edge case to optimize for. It's rare and trivially corrected.
> Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening.
You don't have to configure a $GOPATH in Go. If you don't specify it, it defaults to $HOME/go. Just use `dep` to manage your versioned dependencies or `go get` if you're prototyping. Unlike Gradle, there is no scripting language to learn--static binaries and native dependencies are supported with no extra configuration, and everything is fast without a complicated daemon to install.
I come from originally a PHP background, and for me to do a fraction of what Go can do would require me to go in and mess with php config files and spin up more servers in order to get the performance I need, and with Go that's just not the case.
And aren't assumptions the very thing one has to base on statistics?
Especially since one can pay the bills even easier with more popular languages (e.g. Javascript, Java, C#) with more job postings, so that's not a particular argument in favor of Go.