Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex.
That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could also benefit by getting a better handle on their fundamentals and taking a moment to design their codebase more. As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write.
We shouldn't need to treat the developer like a toddler to get them to write safe code. I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.
> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity
As a big Rust proponent, I don't think it makes sense to invoke Rust here. The goal of Rust is to provide a more secure low-level foundation for software; any tools it provides to "ensure data integrity" are in service of that end, and pale in comparison to the sort of correctness that Haskell strives for on principle.
Given that Go is memory-safe (modulo a few concurrency foibles), any software that gets rewritten from C to Go is still a win in Rust's eyes. I know more than a few people in the Rust community who are big fans of both languages (e.g. burntsushi, author of Rust's regex library and ripgrep), and the Rust developers have a lot of respect for the Go authors. Go and Rust have different priorities, and that's A-OK.
I think the big concern is not so much rewrites from C to Go (more or less anything would be better than C), but the fact that there are other choices that'd likely lead to substantially better code which could have been taken but aren't.
> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.
This is a little smarmy, don't you think?
You seem to come ever-so-close to hinting something like "Go isn't fit for writing real applications." Without getting into what exactly a "real application" is, I'll just say I think this suggestion is wrong, unhelpful, elitist, and just generally irritating.
The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.
This is such an old programming language flame war trope that it was probably first written in Aramaic. When I started programming as a teenager and commented on FIDOnet BBS's, people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.
> This is such an old programming language flame war trope that it was probably first written in Aramaic.
I love the quip, but
> people literally said it about assembly language. If for no other reason than to preserve your own dignity, please don't imply that people program in a particular language because they're not good enough to program in other languages.
This is an inversion of the sentiment being expressed: the suggestion is to use languages that allow you to shift more cognitive overhead to the compiler and tooling. If anything, I program in Rust when I fear that the keeping track of all the little bits Go doesn't help me with will take up too much of my puny human brain.
And that's an intentional misreading of the Go devs. Read the Go Programming Language or any number of discussions by the guys behind Go and it's obvious that they care about their craft and care about writing real, working applications, while at the same time having a better understanding of what your application is doing. In their view the way to do that is through simplicity, but it's not a design decision intended to create mediocre devs.
Only the most cynical view of the language would see it that way. Just because they don't agree with your programming worldview doesn't mean they are idiots. The fact that people can say smarmy stuff like possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better with a straight face just shows how closeminded and ideological people get about languages. Just because you know what a monad is or use map/reduce/filter plentifully doesn't mean you are a better dev than someone who has spent years honing their skills in an imperative language.
Nobody gets this ideological about natural languages. Nobody in the real world says "Hey, why are you speaking Spanish? It's so inefficient, you should be speaking Mandarin". Just as in natural language, programming languages can be learned and adapted by people of varying proficiencies, and when you "get" their particular way of modeling the world, they become an extension of you and a tool. We should just be happy when people become really good speakers of a language, not whether it is the right one.
Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? Have you seen how clever some of things they've built are? I dunno, maybe some of the original hackers have learned a lot about building complex systems over the last 50 years, and maybe they've got something useful to say.
I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms.
For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf) with faster speaking rates compensating for higher verbosity. In terms of writing systems, though, there's definitely a ton of human potential being frittered away on learning Chinese characters and esoteric English spelling rules, but not much that can be done about it even if the Korean alphabet and German rule-adhering regularity are superior. Programming languages are all faster to learn and are iterated on much more quickly and so the possibility of realistically affecting change leads to ideological arguments.
Yes, go is a replacement for Java. Google couldn't rely forever on sun forever (see the later acquisition by Oracle and lawsuits with Google). Big companies want to own their main tools.
It's also to separate itself from the Java crowd, which has a rather poor image to a lot of people that google wants to attract.
Go happens to be a pretty nice replacement for Java in some targeted circumstances, but that is not why Go exists. Go's charter was to address deficiencies of Google's C++ programming environment, not its Java programming environment.
As it happens, outside of (perhaps) Google, C++ serverside development is so rare that Go's strengths aren't very compelling to C++ developers. That Go didn't evolve in the direction its founders expected does not mean that its founders are lying when they explain, clearly and repeatedly, what the original point of the language was.
> Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons?
It was Pike himself that stated that as a goal for Go at one of the early Goconfs, because new Googlers aren't skilled enough to pick up C++, Java or Python.
The key point here is our programmers are Googlers, they’re not researchers. 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.
That's the quote people like to jump on. You could read it as humility or a nod to other languages, but it probably wasn't intended to be read as "we've designed a stupid language", and even if Pike agreed with that reading, he probably wouldn't agree that keeping programmers mediocre is a goal or a side-effect of a non-brilliant language. Don't mean to put words in his mouth, but the above quote obviously isn't meant to support anything like:
The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.
Which is an extreme criticism, but it's a pretty common assumption in most of these discussions. I mean, look at the most upvoted posts in this thread.
> "The key point here is our programmers are Googlers, they’re not researchers. 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."
It seems opposite of what you mentioned regarding C++/Java/Python.
Not really, because in spite of "probably learned Java, maybe learned C or C++, probably learned Python", Go thin set of features makes a good developer in any of those languages feel like elite.
He didn't say they weren't skilled enough to learn those languages - in fact he explicitly said they likely would know those. There's clearly a ton of evidence showing that Googlers can learn them, but having a short learning curve for the new language they're introducing still seems useful.
> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write.
How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)? This was mentioned in ample detail by Rob in the article. Is Kubernetes not a "productive" system by your definition?
I worry that a lot of developers who have been using languages like Java or C# see Go and immediately feel the need to point out that Go doesn't support language features that they've come to rely on, and so they see that as a weakness or a flaw.
With Go, you're getting a lot of high-level language features like anonymous functions, while also gaining the control that you're not able to get in higher level languages like Python or Ruby or Java.
I think this works out great for cloud computing, where performance is a major requirement, but the technology is expanding rapidly enough that a step up from C or C++ is very necessary.
A lot of the complaints I hear are related to abstractions, too, and I understand those to an extent. I also think that if you're complaining about the lack of generics, maybe you're not thinking about interfaces correctly. A perfect example is the beautiful simplicity that is the [`io.Reader`](https://medium.com/@matryer/golang-advent-calendar-day-seven...).
So, whenever someone says something like the OP:
> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.
I take that as meaning, "I've never seriously used Go beyond writing a hello world app. It doesn't have the features I rely on to be productive, therefore I don't think it's a capable language for larger projects."
I will say though, dependency management in Go is hell. I wish Go had something like Cargo.
>I will say though, dependency management in Go is hell. I wish Go had something like Cargo.
This is the number one thing that has kept me from going full on Go. The killer feature of Node was NPM, not Javascript. Unless Golang comes up with something comparable it will forever remain niche.
It is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do.
There's a lot of "gotya"s with using dep though.
One that gets me a lot is the fact that I like to commit my vendor folder, just for faster CI.
So if I committed my vendor folder with a copy of "k8s.io/client-go", and then in a different project I imported a package from my vendored project, it would never compile until I removed my local copy of that "vendor" folder, since it's looking for that specific dependency ("my-project/vendor/k8s.io/client-go").
Ok, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.
If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder.
Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this:
pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as type "github.com/project/a/vendor/github.com/dependency/pkg".Example
It's not a big deal because if I just remove "github.com/project/a/vendor" from my $GOPATH then the problem is resolved.
because of this, I guess my real complaint here is that "vendor" doesn't seem to be the right word. I'm really just looking for something to complain about.
Oh I see. I think the conventional wisdom here is to only ever vendor the end use (binary) projects, not libraries (and maintain such a distinction). (But I guess that's as helpful as "you're holding it wrong".)
So your problem is you have ("binary") packages A and B, and a helper package at A/H that you want to import into B. But A is vendored at A/vendor, so A/H always looks for dependency D at A/vendor, which is wrong for B.
I would fix it by moving A's main into A/cmd, and vendor at A/cmd/vendor instead. A/cmd can still import all its' helper packages like before, but now B can also import them without getting snagged by A's vendoring because it vendors another level up.
Hmm yeah I think that would be a good option. One potential problem with that is running tests on the individual packages. I believe that the vendor folder would have to be in a descendant folder. So like... "./vendor", or "../vendor", "../../vendor", and so on. If the vendor folder was in "./cmd/vendor", and you ran the test "go test ./pkg/example", it would not find the vendor folder.
My solution was just to not commit the vendor folder, and before the test starts, run "dep ensure".
Oh that's certainly a good point and a deficiency in my design.
But then again if you're only testing H against A's vendored dependencies specifically, you're missing testing it against B's. I'm not sure how you would fix that.
First a note, godep is a different tool then the one you mean [1], that does the same.
> dep still has nasty bugs, but in general these are comparable or fewer to other tools out there.
(From the Github readme)
I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others use the lowercase.
Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all.
So I had to resort to a different dependency management for now, which did some linking to fix the situation.
AFAIK it's still not decided when/if it will join the main distribution.
I've not tried it for a while now but last I saw it was even more opinionated about GOPATH than the existing tooling, and it wasn't at all easy to figure out what it wanted me to do. Maybe it's improved since though.
> How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)?
Go was simply the first language to successfully target the niche of imperative, natively compiled, GCed languages. It wasn't the first language of this kind, but the first to have a reasonable amount of adoption/backing. Whatever other flaws it has or had were trumped by the lack of serious competition in this area.
The article is scant on details as to what exactly it was about Golang that propelled these companies to stardom, if it even did that at all. Do not mix causation with correlation, though this goes both ways and I maybe wrong in doubting Golang.
The language that appeals to the masses with low barrier to entry in a niche always wins the popularity contest in that domain. I attribute it to herd mentality; assuming skill has a standard distribution, the average developer herd gets a massive head start.
You can see the idiot friendly language eclipse in popularity in other domains too even though "better" alternatives exist:
- elegant general purpose: python over ruby
- web: php over python/rails
- SQL databases: MySQL over Postgres
- NoSQL: MongoDB over CouchDB/Postgres
Go's just the first mass appeal language in the concurrency performance domain and it just opened the door to a lot of developers who before wouldn't dare play in the space.
PHP has some unique design considerations that make it better suited for web. PHP's main significant weaknesses for that domain would be the lack of a strong type system, lack of strong event based server ecosystem (what reactphp does, nodejs, golang, etc.), and it's slower than Java. It has multiple popular long supported rails alternatives. Python and Ruby have nothing over PHP for web development. PHP has the absolute best first class support for isolated http request handling, live updating only challenged by erlang, standard library designed entirely around webdev, great tooling for building c extensions, widespread cpanel hosting, and composer (pip is garbage compared to composer).
So while you might like ruby/python because it's prettier or because PHP 4 was awful, the idea that one of them is a better web language is totally laughable. If you asked me to define a language better than PHP for web applications, I would have you a long list not even considering python and ruby.
Some of the dumber but more popular solutions here are just older ones. And please refrain from starting unsubstantiated flamewars. What's next, editors: emacs over vi ? Colors: black over white ?
What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple.
You talk about giving the developer tools, but those tools can be augmentations on top of the basic building block that is the language. That way, anyone can build tools for their needs, without complicating the lives of others. No need to build all the tools into the language, that's very constraining.
> What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple.
This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library.
More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.)
The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs.
Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.
But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming same popularity, I think a quality language tool for Rust has more potential to be monetized (just like those for C++) than those for Go, because the former has much higher barrier to entry and hence less competitors.
We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs.
That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semantics like C++ does) can support autocompletion with comparable levels of implementation effort.
Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?
I don't know. I have a hunch that lots of macros still will be better with the new macro system, but we'll see.
Anyway, regardless, there's certainly more work to do! And it's being actively developed quite heavily. For example, it will be on stable Rust very soon.
> Are Docker and InfluxDB simple apps? What do you consider simple and what do you consider complex?
Docker and InfluxDB are investor funded organizations that contribute to open source. I'd argue that their success has more to do with the monetary input than anything to do with the language itself.
I don't understand your argument. You can't develop complicated GoLang apps unless you have tons of money? But you can develop complicated Rust apps without tons of money?
an army of "toddler" developers can overthrow a single hero in terms of productivity, and using a "toddler" programming language makes sure that newly joined "toddlers" can understand (and also maintain or upgrade) existing code, so that the army can just keep growing.
Oh I'm not disagreeing there. I prefer not being a soldier altogether though. There's a reason I didn't go into the military.
I'd also suggest that an army of experienced devs is more effective than an army of non-experienced "toddlers". Programming languages and CS fundamentals aren't elite, impenetrable cliques; they can be learned.
They aren't elite, but the latter are already overemphasized and have very little to do with writing quality code or engineering, with some few exceptions.
And the choice of language is incidental for the most part as well.
> an army of "toddler" developers can overthrow a single hero in terms of productivity
Depends on what you mean by toddler.
Golang devs imo are not toddlers. The point seemed to be that golang devs could just learn to write C, which is valid. So could Rust developers. But if that was the goal, you'd think both groups would only be using C.
When I think of "toddler" developers, I think of interns being hired into a company to write code with no experience working under mid-level developers that also lack experience, and 5 years later you have what is called f-ing hell. I've worked at a company like that before, and know someone that worked in a company that was mostly VB developers. Same concept but without interns.
For sure. The problems happen when insufficient experience, knowledge, and leadership is combined with anything.
With enough fuel, fire, and gained wisdom, anything is achievable.
But, 10 kids playing with building blocks can't easily build an automobile, whereas one smart, dedicated engineer with a lot of metal, some tires, and better tools could pull it off. So, tools and resources matter, too.
Nobody is treating developers like toddlers. In corporate environment developers are paid to do what management wants. In more free environments developers can use what they want and if they are not using Rust/Haskell may be they do not find use for it.
With several components we're building in Go I have to say I don't see it stopping us from being too clever, too complex, and too verbose. In fact the workarounds to just get some things done without having a whole lot of duplication are fairly annoying. `go vet` with the strictest settings should probably the default if that was actually the goal.
> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.
I write raft based distributed applications in go, it uses millions of raft clusters concurrently just for its nightly tests. That simple app is not that easy.
Introducing too much of such language X is better/stronger than Y propaganda is not helpful at all.
I like Go as a language, for the decisions and trade offs that they made when creating it and for the cross platform bits. Clearly the performance is sharp too.
I just don't find it particularly productive for full stack web work. API's or other high performance interfaces...great though.
Developer productivity is overrated, or at least we have no concrete ways of achieving it. The person who approaches everything with a for loop and doesn't have to even consider whether to use a list comprehension, map and filter, or loop is going to be very productive simply because there is no choice to be made. This is only exacerbated in teams.
You're absolutely correct on basics, and those can't really be worked on unless devs are stripped of everything but basic constructs like the function. Rust and Haskell are too much for the average dev and maybe even good devs
One of Larry Wall's slogans for Perl is "Easy things should be easy, and hard things should be possible." In its own way, that's what has made Go the kind of success that Perl once was.
Perl was the glue language of the web and Go is the production language of the cloud.
I'm actually a bit scared to imagine a world in which Go was not created, given how much success I've personally had with it.
I think that's a great comparison. Some people love Perl and some hate it, but there's no denying it was a tremendously important language in the 90s. The duct tape of the Internet.
(I don't happen to like either Perl or Go myself! But I think I can see why others do.)
Seems like the core philosophy of Go is the end result of Python's "there's one way to do it".
The "Go's design and users are dumb" meme needs to die. It's not even a constructive criticism. It's dishonest, insulting, and it's too bad grown adults and professionals can't see beyond it.
That meme isn't going to die because one of the creators of Go himself said it was created for dumb users (sorry, Googlers "who can't handle a brilliant language"). There wasn't any constructive criticism coming out of the Go team towards these other languages, rather, they were simply "too complex" in a general sense.
The creators have also strongly resisted adding features others consider basic for a decade now, with a variety of nonsensical justifications.
It's a stretch to even claim Go was designed at all. From the very blog post this thread is about, we find this statement:
Russ discovered—that's the right word—that the generality of Go's methods meant that a function could have methods, leading to the http.HandlerFunc idea, which was an unexpected result for all of us.
Go is not exactly a complicated language to begin with, yet the designers "discovered" things about it whilst building it.
Go gets a lot of criticism because it's an empirically very poor language and its designers routinely say absurd things that invite ridicule, like "Go is the language of the cloud" or "We have invented a GC for the next 20 years" or "Go was designed for interns and students who can't handle brilliant languages".
I'm not saying Go's design is dumb, it's obviously successful at what it set out to do.
I'm not trying to be dishonest or insulting. I've described the philosophy of the language in exactly those terms to Go users, in person, and gotten nods of "Yes, that's right, that's why it works."
I think it's more dishonest to claim that the language designers didn't intentionally limit the language to less than the state of the art as of 30 years ago, on purpose, because of concerns about the mental capacity of users. They themselves admit as much.
I took a seminar class in Go in my final year of school, in the spring of 2010. I was hooked pretty early. It was a very chaotic time to be writing Go; the language would change from week to week, so if we did a pull from the Go repo, there was no guarantee last week's assignment would still compile! At the time, the canonical way to compile code was by makefile:
include $(GOROOT)/src/Make.$(GOARCH)
TARG=bin/command
GOFILES=main.go
include $(GOROOT)/src/Make.cmd
I remember reading the netchan and thinking it would be so cool but it was gone by the time I started working Go. I figured I must have been imagining things.
I've been writing Go professionally, full-time, for the past five years.
I'm a polyglot, so before Go, I loved exploring every new language I could get my hands on[0]. I still do, for fun, but Go is the one language that has kept me hooked all this time. It's not for any single feature, or for the community (though that's a great part of it). It's because it's the only language which I feel gets out of the way for me and lets me write powerful, robust, and maintainable software quickly without having to think or struggle against the tools.
For me, Go is like trying to do surgery wearing latex surgical gloves, instead of wearing thick woolen mittens.
[0] Seriously: if you can name it, and there's a working Linux x86_64 compiler/interpreter for it, I've probably tried it.
In the vein of the other questions. What are your thoughts on Nim? I'm one of its core developers and always like to hear what people think of it, in this case especially since I view it as a direct competitor to Go.
I've toyed with Go for a while, but it has not yet become my main language. Can you talk a bit about what you use it for, what your tooling is, and if you've discovered some great go-to libraries and supporting tools?
> Out of curiosity, what is your take on clojure then ?
I have a lot of respect for Clojure, though I don't have much of a use case for it.
At the time I tried it, I was annoyed its semantics for '() and nil - they're sort of a hybrid between how Common Lisp does it and how Java does it. Which makes sense - the Common Lisp approach would be a nightmare to implement on top of the JVM while maintaining interoperability, but as someone whose primary language before that was Lisp, it was a bit weird to try and get used to.
I love functional programming - before Go, Lisp did pay a number of my bills, after all! - but to me it feels more like art than work. It's fun to figure out the most elegant, Lisp-like way to approach a problem. It's fun to convert an arbitrary task into a language-recognition problem and then write the compiler to recognize that language as the implementation to the solution. I get the same feeling from it that I do when I finish a drawing and stand back to look at it. I don't want to touch it, lest I smudge it - I just want to sit back and appreciate the finished result.
But it's a completely different kind of satisfaction that I get from writing Go - there, the fun is in how quickly I can solve a problem, and how confident I am in the reliability, robustness, and long-term maintainability of my initial effort. That's where Go really shines for me, and it's not like the joy of having created an beautiful work of art. It's more like the satisfaction of having built a solid American Colonial house for yourself to live in.
I like them both, but for my professional work, I'll choose Go every time.
So would you say this is more about your mindset when programming in LISPs? I like to use Clojure for my side projects and don't seem to feel the same way about my programs as you do. Even as a long time primarily imperative/OO programmer (but who has tried pretty much every language out there, too), Clojure actually feels like one of the most pragmatic languages I've used.
It's the same with me. I didn't have any lisp experience before learning Clojure. I see it as very pragmatic language, the kind that lets you get shit done, it doesn't get in your way. But that said, I can understand why parent compares lisp to art. I would say functional design is art, because you need to put in a lot of effort to learn it.
> Russ discovered—that's the right word—that the generality of Go's methods meant that a function could have methods, leading to the http.HandlerFunc idea...more general ideas too, like the the io.Reader and io.Writer interfaces, which informed the structure of all the I/O libraries.
Big testament to great interfaces being hugely impactful. For me, the IO and HTTP interfaces are a big part of why Go is so nice to use; the libraries (including std) that emerged around those interfaces and their subsequent interoperability makes everything so coherent.
I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be beautiful at a large scale organization. In my experience java codebases in big companies are nightmare factories because of the freedom you get from more similar languages. The Go dream of having a single decent solution to a problem instead of 20 that range from bizarre to really clever sounds like heaven.
I wish I had more time to take a serious stab at learning it.
The size of the language and the (more or less) one-way-to-do-things style mean that reading someone else’s go—say, from a library you’re depending on—is really easy. The chance you’ll run into language features you aren’t familiar with (which can happen even to long-time writers of some larger languages) or one of several competing and possibly now-deprecated 3rd party bolted-on features making up for painful deficiencies in the base language (ahem, JavaScript) or some nutty flow-obscuring “helpful” nonsense is low.
Unless there is a strong mandate from the top to take time for maintaining and reviewing code I'd say absolutely. Even if those were in place I'd say a strong maybe. Ignoring competency some people just have wildly divergent ways to doing the same thing because of their background. Languages like Java and C++ allow for it because they allow you to do so much. So I agree with the basic tenant of Go that having one way to solve a problem is a huge win for code maintainability and readability. If the one way is clunky and kind of ugly I'm still down for it.
I can see it being a good thing in many organizations. I've worked in organizations with very sharp people who did not care to limit one another, allowing a smorgasbord of languages, frameworks, idioms, etc. Watching them smartly tackle the wide variety of idiosyncrasies that came with each language and framework was frustrating because, while they solved a great many problems, delivering robust working software was not one of them. I don't think everyone would have that problem. But I'd wager a great many would (do).
Large Java codebases in giant companies are often very poor because:
1. Giant non-software companies often have low hiring bars for their software teams.
2. They are full of bored programmers working on boring software, these people then find ways to make their lives more interesting and kill the time by over-engineering things.
3. These codebases are often very large, old, and have suffered many requirements changes with little or no time allocated to clearing technical debt.
There's nothing in Go that'd make any of these things better. It may superficially appear this way because Go is, in the grand scheme of things, still quite new and hardly used in the enterprise (because it doesn't solve anything better than Java), and as such there aren't any large enterprise codebases written in it. But if you compare the language features, it's hard to explain what would make Go result in better quality software than Java and easy to find things that'd make it worse.
My introduction to Go was pretty recent about 2 years ago and we went all in. We had an internal tool that started out as a test MVP written in python. Demand was growing fast so a year later it was an absolute mess of tech debt.
We knew a significant refactoring was needed and figured the best thing to do was to just redesign and build from scratch. One of the guys had played with Go in his spare time so convinced all of us to just try it. Best decision ever, at least for this use case where we needed speed and stablilty. Go's native concurrency features were an absolute joy. It's really opinionated too so it ended up very convenient to use as a team with different coding styles. Thank you Go team!
I sometimes feel crummy to force my preferences on other developers I bring on board. For example, most of my work is PHP, so all of our repo's use spaces, and braces on newlines. When a new dev comes on board, they must follow that format. Funny thing is with GO, I don't mind in the slightest that go fmt . is tabs and braces on the same line. What is so much more important to me is consistency. Go has done a stellar job at providing consistency. As I read when I was getting started, no one loves gofmt's formatting, but everyone loves gofmt.
I have mixed feelings about the language itself, and some of its tooling (GOPATH just makes no sense to me whatsoever, and I've not spent enough time hacking Go projects to understand why it wouldn't be better to just have something like Cargo to handle dependencies), but I firmly believe that go fmt might be the biggest contribution to the language tooling world I've seen for a long time.
We've had autoformatters before, but they were always customisable things, sparsely used. Go shipping a formatter with the core distribution? Go projects routinely adopting it as a requirement for contributors? One standard format defined from the start?
Knockdown stuff. All those pointless arguments about coding style, gone. All that worrying about how to lay things out, gone. Just run go fmt and move on.
I have now become entirely reliant on rustfmt when I'm writing Rust, and I love it. I just write a total horrible mess, press save and it magically becomes neat and lovely.
I wish I had something that powerful operating in my C# environment at work.
Admittedly, at the moment I also wish my C# environment at work wasn't laden with iron-clad layout rules that the tooling isn't capable of fixing for me. All private members must be after the public ones, but static private ones need to be before the instance ones, and all properties go first regardless of accessibility (although remember the private properties have to go after the public properties). And usings must go inside the namespace definition, in alphabetical order except System.whatever, which all come first (in alphabetical order). And you can't split a function argument across multiple lines unless it's a lambda. Microsoft's C# style guide? What's that and why would we care and no it's not prescriptive enough anyway.
It's enough to make your head spin. Good thing I'm only there for six more days.
Give every language a formatter, as standard, and let's just be done with it.
I second this, please remove the forced GOPATH with the upcoming Go 2.0. (GOPATH is annoying to handle with multiple repositories in different paths, and probably there is no reason to have it anymore anyway.)
I really like Go, it's so nice for server side applications.
My ideal system is: clone a repo, run `go restore` to fetch dependencies and then `go build` to spit out a binary or `go run` to quickly start the main function.
Nothing from outside the repo can effect that build. Likewise anything inside the repo can’t effect the outside.
Compartmentalizing each project makes builds more reproducible and more obvious. If anyone else clones the same repo and runs the same commands, they should get the same result.
We actually do this at work; our repository is a full GOPATH layout with subdirectories for src/, test/, doc/, etc. We vendor our dependencies. To build, we have scripts at the top-level that compile all of our components (we ship a whole suite of tools in a single repo), run go vet, run tests, etc. The user never needs to set GOPATH. It's not a perfect system, but we've been using it for 3+ years without too much trouble.
I wrote my first fibonacci sequence test program in Go about four years ago. Now I am full-time admin of a large real-time cryptocurrency charting website that pushes 30MM+ messages to clients per minute, written entirely in Go.
I've learned a ton about programming from Go and I'm not sure I would have managed to build the system at all with another language. Go gets a lot of flak for its simplicity, but what it does it does very well. The concurrency model, networking packages, tooling, and simple deployment make it a joy to work with and I owe a lot to the Golang team. Happy birthday!
I've been using Go on the side since mid-late 2013, so not nearly as long as some here, but I was heavily impressed by both Goroutines and channels as ideas, and by the net/http library.
The general portability and simplicity of the language has made it nice for side-project work.
I've since used go to write a blog engine, several APIs for school projects, and have been working on a scripting language (pisc.junglecoder.com).
We've asked you before not to conduct programming language flamewars on HN. If you keep doing it, we're going to have to ban you. We're looking for thoughtful discussion, not stale sniping.
Does that matter? Languages are born of other languages all the time. What matters are the many reasons why languages like Go flourish and what makes them impactful.
I know the didn't invent them. But Go was my first exposure to them, and to date, one of the few languages to give them dedicated syntax. I realize it's less necessary to do so in some other languages, but it was still a very interesting learning experience.
> It's worth stating that the language is called Go; "golang" comes from the web site address (go.com was already a Disney web site) but is not the proper name of the language.)
You already have a hugely popular game called Go (WeiQi/Baiduk). It just adds confusion to queries to call the language Go instead of Golang. Even the #go channel on freenode has a disclaimer that it's not about the language. It's like calling your language football.
Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)
> Is that true? First time I hear of a dominance of Go in the cloud. (And what does it mean anyway -- any distributed app that runs on the cloud, or cloud infrastructure... such as?)
It isn't. It's like saying Ruby dominates the VM space because Vagrant uses Ruby. Sure there are a lot of orchestration tools written in Go, but look at the actual apps running in the cloud, how many efficient RDBMS written in Go widely deployed? worker queues? full text search engines? ETL solutions? streaming servers? or just actual apps users interact directly with?
It's the "Go is a system language" all over again. It's at best misleading.
But you could argue ruby dominates the DSL space, which is effectively what Vagrant is. A DSL around creating VMs. Same for chef and puppet , but more so.
Kubernetes is built on top of docker, etcd is used as a secret store for kube, and terraform is for infra as code. Google cloud platform offers kubernetes as a service. CoreOS Tectonic has the AWS plugin, and Azure has "Container Service". You can run kube on your own hardware, but the idea is that the service itself can just magically ask for more nodes which implies either on-prem cloud our the actual cloud cloud.
Not a Go programmer myself but I am very grateful for Go. Some of the best software I use everyday uses Go - rclone, gitlab, gogs, gosu, docker to name a few.
I evaluated Go a few months ago for a web project, but it seemed as if there was a lot of manual work involved in mapping objects in and out of a MySQL database and in and out of JSON (basically, 50% of my day-to-day back end work). It just seemed too arduous.
The second thing that bothered me was that an edge-case bug in one of my HTTP handlers paniced the app. If that had happened in production while under load, many users would have gotten an error due to a bug in one user's request.
So, serious questions:
- What is the best way to map objects to/from JSON?
- What is the best way to map objects to/from a database?
- What is the best way to prevent a request from crashing the server and killing a bunch of unrelated requests?
Go's HTTP server handles each request in its own goroutine, and any panics encountered are automatically recovered from. Nothing special needs to be done to prevent a panic from taking down the server.
> What is the best way to map objects to/from JSON? - What is the best way to map objects to/from a database?
If you are doing heavy sql queries, then it might be beneficial for you to use an ORM. There are plently of those out there, so choose one you like. Just create structs for your tables and run your queries.
If you are doing light/moderate sql. Just have an interface for your db calls, wrap your responses in a struct and use json tags for json encoding/decoding.
> What is the best way to prevent a request from crashing the server and killing a bunch of unrelated requests?
I use negroni. And its recovery middleware does exactly that.
> - What is the best way to map objects to/from JSON? - What is the best way to map objects to/from a database?
I'd recommend using the JSON to generate your struct definitions, in a schema-like fashion. I wrote a tool to automate that process: https://github.com/ChimeraCoder/gojson
I use this as a step in the build system for the projects, which ensures that the definitions stay in sync with the API clients/servers themselves.
I don't use go, but it doesn't really seem like CRUD apps are the sweet spot for it. When I think of go, I think of system software, that 10 years ago would have been written in C. I don't think of it as replacing Rails.
Yeah. The repeating the field, only camelCased, in JSON annotations feels needlessly painful to me. Subjective, I know, but that kind of painfulness seems pervasive in my (brief) dabbling with Go, and is one of the main reasons I moved on.
The json annotation is optional, but very powerful since it allows you to set the mapped name of the field to any name you like, allowing you to map json fields with snake_case, CamelCase, kebab-case, etc.
One alternative to writing struct tags by hand is to write a little generator code to map the field names from, say, a reference .json, then calling `go generate` as part of your build process.
I've wondered whether a wrapper library could do rule-based field name mapping automatically with Go's reflection facilities (which could be a productivity win), but I haven't really looked at it closely.
For a language that's been around for 10 years Golang's adoption rate is still pretty low. Searching Indeed.co.uk's API by job title there are currently 25 Golang jobs in London compared with 29 Perl, 188 Ruby and 511 Python. For the UK as a whole it's 34 Golang, 57 Perl, 276 Ruby and 821 Python. Golang has a long way to go yet IMHO.
Which language released in the last 10 years is more popular then ? Golang is arguably niche and does not offer the huge flexibility and ecosystem of say Python, so i am pretty sure it will never come close to that, but there are a good number of usescases where it arguably is the best choice.
Scala, with 164 jobs in London and 225 nationwide, has been around for about the same time as a production-quality release. I raised the point because I think Golang's coverage on HN is disproportionate to its significance in the job market.
London is about 'fintech', so Scala is in great demand.
SF Bay Area is about 'webscale' so Go is popular, as it established as The Cloud Automation language. And HN crowd is mostly leaning to SF. OTOH you wouldn't find a great demand for Oracle DBA or C# skills in The Valley, and that's not because they are not in great demand somewhere else - maybe even basically everywhere else like C#.
Places lean to some niche or other, and vice versa. Apple places its growing hardware teams in Texas despite new campus in The Valley and all that. Why? Because Austin is very much hardware place.
I specified in the parent post searching by job title and also via their API which removes a large number of duplicates. These 2 constraints give a clearer picture IMHO.
Maybe I'm spoiled, but I've had a hard time dipping my toes into Go due to the lack of batteries included frameworks (like Rails or Laravel). Can anyone recommend some resources to give it another shot?
It's been a while since I used it, but Revel[0] is almost within the same family as Rails. The developers of Revel say they're inspired by the Play Framework.
Another option that looks nice is the Buffalo[1]. It's a collection of libraries that are built to play nice with each other, but you don't have to use all of them as a bundle. You can use only the layers you want.
And, I really started digging into the native http support. Go has a lot of really nice things built in and ready to go. Still working on learning what they've got, so maybe I'll end up wanting a framework again at some point. But for now, it's got everything I need for general tasks.
Buffalo I guess, but this is not what Go was build for. This is like asking for a c++ web framework. Yeah, there are some, but generally speaking you don't see people using c++ for building a web app. Components of the app or the inrastructure - yes.
At work we have recently started using Go. When I told one of my developer friends that I was doing some Go projects, he was confused and thought I meant "Pokemon Go". So yeah, you might have a point, sadly.
Don't underestimate the echo chamber here in regards to language popularity.
I manage servers for an awful lot of developers and, from my conversations with them, I'd be surprised if I could say more than single digit percentage have ever heard of Go.
Unfortunately I have to write it nearly every day in my job at Google. The biggest failures are the lack of generics or any form of immutability. It's basically impossible to write any kind of abstraction in Go. That's unacceptable for a language created in the 21st century.
No other social or professional setting tolerates this kind of brazen self importance and posturing seen here without mockery.
This site doesn't allow satire but looks the other way when snarky claims are made without evidence. Blanket assertions must be backed up. At least show the problem you were trying to solve and the new solution in your favoured language/tool/framework so it can be judged.
This is how bad ideas and complexity gain traction without scrutiny and push back. People become vested in Ruby and run down php, people become vested in Rust and run down Go, people become vested in React and run down jquery. How comes tools people were using happily just yesterday are suddenly 'completely unacceptable'?
No one who befitted from these tools and languages is going to run them down publicly because they found something better. This is self serving ecosystem marketing at work that HN seems to ignore. It's as if every self congratulatory commentator often seen here was born an expert and short circuited the process of learning, and can use this platform to run down everyone else and their choices.
It's funny that the very first thing discussed is the name. "Go" always seemed like a bad idea, being hard to google for -- and while they were employed by Google, no less!
It fits with the love-it-or-hate-it nature of the whole language.
I find searching for things with go quite often brings up what I need anyways. When I'm unsure or hit a snag, I'll include the term golang. Have not had many problems searching for stuff.
I remembered my experience learning Go: reading Go language spec for about 2 hours and start being productive. That is not quite possible with other languages, I am afraid.
That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could also benefit by getting a better handle on their fundamentals and taking a moment to design their codebase more. As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write.
We shouldn't need to treat the developer like a toddler to get them to write safe code. I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity, but I guess that says something about me as a developer and why I don't like Golang.