Go Is a Shop-Built Jig
robnapier.net
robnapier.net
Now, not everything else has been all good (mostly minor issues with community libs), but the one thing that never ceases to amaze me with go is that: You hammer out a few hundred lines of code, compile, fix those few syntax errors, compile again and 9 out of 10 times your code just works. The simplicity of the language is the key. It's a tool that feels right and gets the damn job done.
This is why I find it unbelieveable when Go users tell me "I never need generics". I look at their code and see
if err = logit(FrobulatingMessage); err != nil {
return err
}
Also, the "I never need generics" made me smile. Sure, one can get by without them, but sometimes, as I said above, it would be really nice to have them.
Admittedly the error pattern is so common that I can imagine people getting very much used to it, but thats not the issue here. The problem is indicative of Go's lack of abstraction power, and its pervasive. There is no difference between `filter`, `map` and a regular foreach - every piece of code that wants to do things like that must re-implement the mechanics of creating new slices and assigning things to members which are accessed using a specific index. So many details - I can't see the forest from the trees!
I see the same kind of noise in legacy messy projects where a piece of code works on multiple abstraction levels and its impossible to think about what a it does without thinking about the mechanics of how it does it.
Given all this I really can't understand how someone can call Go code beautiful and clean. My gut reaction is "this will cause a mess couple of years down the line".
The cost of not having generics in Go is really understated, and it saddens me greatly. With them, Go would be an extremely interesting language. But apparently, the language designers believe that you (the user) are not to be trusted with writing sensible abstractions and therefore are forbidden to do it.
I find that so bizarre. That's on a personal level, I'm not throwing stones.
My two favorite languages before Go came along were Objective-C and Python. Different tools for different problem-sets of course, but Objective-C can quite easily be called insanely noisy.
Go is obtuse, but I find its readability on par with Python in that there's one way to do something, and that way is repeated over and over. I don't have to worry too much about stylistic preferences between programmers, people trying to get fancy while writing code (or trying to show off). Our server code serves thousands of requests per second - I need that code to be rock-solid, not fancy or overtly minimalistic.
You're right, people do get used to the error pattern. I can either handle it, ignore it, or toss it up the stack, and I get to make an explicit decision about that every time.
We've been rewriting critical systems code in Go (from mostly Python) and it's a joy. I am, of course, the (unintended) target audience for Go - a dynamic language dev looking for speed, concurrency, and compile-time safety, along with the simplistic beauty of gofmt, goimports, and so on. But I do find it beautifully simple, if not entirely "beautiful."
Edit: formatting.
I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Command + J. Want to refactor code, much easier than in go. So tooling is a big problem I encountered.
Next in line is lack of reusable data structures. Sure, embedding of structs is supported, but lets see...what will you do with a person struct (name, age, gender) that should be part of a employee struct and also the executive struct. You have 2 options 1) copy paste the person struct fields into each of the other structs or 2) you have interfaces and implementations of those interfaces so you can only deal with it through interfaces using embedded structs. What we really want is a flattened struct (just like inheritance). Most time people use inheritance not because its the right thing to do for that piece of functionality, but because it allows easily flattening out a data structure so you have reuse of a common data structure with common properties across other data structures. This one killed it for me with go. I can't reuse. I am not google to have loads of dollars and when I try to make things work, I need to be able to keep an eye out for bugs that can creep in with go where re-use is artificial or takes excessive work to get.
All in all, maybe go has its niche, but for a small shop that runs on scanty resources and needs to build robust and reliable applications, a heavy weight like Java or .Net is still ruling the roost.
That's what we call struct embedding. Check this http://talks.golang.org/2014/go4java.slide#33 for more details.
This is not to say inheritance is better. I am just illustrating how reuse is harder with go because it expects a lot more code to do a simple thing.
Being able to fire up a fully formed, non-handicapped environment consisting of only vim and some command line tools is great. I've tried repeatedly on the JVM to accomplish this and always end up back with bloated IntelliJ and the vim plugin as my only option.
I would say that in the last 15 years I've used inheritance correctly a handful of times, embedded structs are nearly always the correct solution to data structure reuse problems. That Go prioritizes composition over inheritance for data structure reuse is one of its fundamental value propositions, that anyone that has used Java extensively thinks otherwise is baffling to me.
If Go had a longer history I'd probably argue the exact opposite conclusion of you. If you are a small shop with scanty resources and need to build practical business solutions Go seems like a great choice. Conversely, if you are able to afford the best developers and have massive enterprise software needs, maybe Java or .Net makes more sense.
Bloated it may be but helps me get the job done faster...much faster than I can do it in vim. I work on a mac with 16 GB RAM and thats sufficient for lots of processes. Every bit of the way, I have documentation I can lookup right within as I type, I have autocomplete that always works, I have debugger support to catch little things I missed, tons of libraries and plugins that have stabilized over the years...whats not to like? The downsides (and the reason I looked at go) are both Java and .Net are memory hogs. I needed something more lighter that would offer the same level of productivity during development.
In my vim setup with simple key strokes, I can go to the source of, see the type definition of, see the documentation for the call under the cursor. I have formatting, vetting, and if you want compiling on save of the file (and it's super fast). I have autocomplete that behaves exactly as I want it to.
I wish there was better ctags support for go, and the go oracle tool is more prototype than production software, but on the whole I am much happier with my development chain in go than I've ever been on the JVM or .NET.
That seems to be the opposite usual scenario for "heavyweight" enterprise frameworks.
I actually think Go hits the sweetspot - faster to develop in than Java/.NET, but much more robust, reliable and faster than the scripting languages.
This is not to say go is bad at all. Its been designed by people 1000x smarter than me. But it isn't helping small shops go any faster or be more productive than they are with current setup. Talk about progress of the 21st century programming language...can't find much.
Well I haven't done much web programming in Go, so I would not be very fast. I have done a lot in Python, and I usually finish prototype apps within days while the Java teams are still stuck in meetings with the Oracle DBAs trying to work out why Hibernate is generating shitty SQL again. And I believe Go is comparable to Python as far as productivity is concerned, but with type-safety and speed.
I think there is a lot to commend of Java, well at least the JVM, and the tooling and libraries are great, as is the performance. But I rarely hear anyone argue it is a fast, agile language to develop in.
Play doesn't use a scripting/interpreted language, it uses Scala, a statically-typed one, but with type inference which you may have confused with dynamicity. As for Groovy/Grails, they seem to be dying off lately.
I'd note that all the replies at this time argue the point about data structures, but none address the tooling.
I want my autocompletetion, dammit! And I don't want to use Emacs or Vi to get it.
The lack of refactoring support was what ended up making me switch back to Java+Dropwizard. I'm just much quicker at evolving services because of the better tooling.
I don't know about you but I'd rather work with people that understand the tools they are using and when it's OK to do fun stuff and when it is important to exercise restraint and "dumb it down" for the good of the team. Using the language to solve the problem of uneven programmer ability feels a bit off. It's something out of 1984. You can't say "great" in Go you can only say "good++".
Or, less anecdotally, I maintain about twelve services in Go, including web services, proxies, and an analytics engine, and I have never been woken up in the middle of the night with a failure. That was certainly not true when I was writing Python or Javascript. Erlang or Swift might offer comparable reliability, but it comes at the cost of a lot of complexity.
Also, your "less anecdotally" is by definition pretty anecdotal.
Of course for toy or small services, go is fine. Erlang certainly could use the "build a binary run it anywhere" distribution model of Go tool.
But reading all these pro-go articles, it strikes me that none of them seem to be written by people who really understand concurrency.
Believe me, I wish Go was written by people who had understood erlang. There's a lot to like about it and it has momentum.
Look at the examples on the page. Would you really rather see the Go one at 3AM? It's twice as long, and the superficial similarity of each if(err...) stanza obscures the important differences. On a large codebase that adds up. Maybe the "complexity" meant the Swift took longer to write (though I'd dispute that too) - but if it's more readable and more maintainable, that's a positive tradeoff.
In my experience really good developers don't see it like that, they see it more like the Brian Kernighan quote:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
It isn't that they are worried that "lesser" programmers will make a mess using "clever" code, but rather they are worried how long it will take them to debug their own "clever" code, or just decipher such code they produced themselves in the future after they haven't looked at it in 6 months.
If you have an infallible sense of discipline then you don't need this sort of guidance, but given unlimited flexibility a lot of developers can easily lapse into fat-kid-in-a-candy-store mode regardless of their knowledge and skill level.
If we understand the domain and understand what we are building then we can afford to be innovative on the technology. If we are trying to be innovative in what we are building then we need to choose proven (aka boring) technology.
I kinda like that philosophy, and didn't realize that I somewhat adhere to it: I tend to try to keep to tools I'm familiar with when I'm solving problems that I know are new to me. It lets me focus on the problem and avoid thinking too much about the tools. But if I'm in learning mode or need to implement something I understand well, I'll often reach for a new tool just to play around with it or try something different.
Perhaps I could rephrase it as being conservative in my technology choices when building innovative products.
Visually: http://www.adlinktech.com/solution/img/20131121-1.jpg
New domain => use known technology.
Known domain => play with new technology.
It could also be that he realizes that he is a PL snob/geek, and that makes him more likely to pick up and learn weirder/'more powerful' languages/paradigms. Other programmers (arguably most programmers) aren't PL geeks, not for a lack of ability, but for a lack of interest. Choosing to use more advanced languages may be great for him, but may just cramp the style of other people that aren't PL geeks.
This belies a multitude of real problems Go doesn't solve, like generics or preventing data races
You don't need anything beyond assembly language, really.
The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.
To me, this is a variant of the Blub paradox at work.
This should be evidenced by the fact that Go is the only mainstream statically typed language without parametric polymorphism. Worse, trying to bolt it on after the fact has generally lead to ugly solutions, like C++ templates or Java's generics.
I expect Go will eventually follow Java's lead and bolt on generics awkwardly.
Not to me. Not to the author of this article.
> I expect Go will eventually follow Java's lead and bolt on generics awkwardly.
Nope. They'll either be done right or not at all. We're not ignoring Java's mistakes.
At this point I'm not sure how Go can do generics well, so if "right or not at all" is really the bar, then Go will probably never get them.
Wikipedia has a nice description:
https://en.wikipedia.org/wiki/Go_(programming_language)#Race...
There are plenty of go fanboys out there who will rage about go getting any kind of criticism, but this was a really thoughtful take on why go is a good practical language despite the problems.
What is with you? The article is talking about languages, not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck).
> enterprise features like exceptions and generics
What is an "enterprise feature"? Sounds like a Java-world word though.
I also don't understand how generics and exceptions "ensure consistency across the platform".
I think what the grandparent poster meant to say was:
>Working in the enterprise, features like exceptions and generics make it easier [...]
"Go feels under-engineered because it only solves real problems" "and so you build real solutions rather than finding excuses to use your beautiful tools"
The implication from reading the article is that those of us that rely on those so called exotic features aren't doing so for serious business and technical reasons. And it seems to be a common thread amongst many Go users.
And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system. You can build error handling classes but often handling errors explicitly doesn't scale.
The implication you inferred from reading the article is that...
I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer.
> And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system.
Although I don't think "exceptions allow you to handle errors in a consistent way" (based on my long and still on-going experience with C++), I still don't see how exceptions and generics "ensure consistency across the platform".
> You can build error handling classes but often handling errors explicitly doesn't scale.
You don't build error handling classes in Go.
That much is true, you compare strings!
I've encountered people doing this. When I said "If I had Maybe here then I could write 1/5 as much code," someone showed me a class that maintained whether it had encountered an error, and each method would do nothing and return the previous error if so. This allowed him to write 1/5 as much code in the method that actually does stuff, just as he would in Haskell or Swift. Unfortunately the approach of reducing every function full of noisy error checking to a bunch of calls on one object is pretty bad in general...
It's fine to say for economic or organizational reasons you're not moving to Go, but don't say it's because you need exceptions or generics unless you've spent a serious amount of time trying it the other way.
I'm getting interested in Nimrod (or Nim as I think it's planning to become). Compiles to native binaries via C, C++ or ObjectiveC. Even compiles to JavaScript. So it will run on all consumer and server platforms, on microcontrollers and in browser.
And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection.
It's a tiny community which hasn't even managed to get a Wikipedia page to stay up, but I'm barracking for it.
And? iOS and Android supports are on their way in case you're not following recent developments. In case you're interested in writing programs for mobile devices, there's already a supporting go.mobile repository with (mainly targeting Android at the moment).
> And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection.
Sigh... this "where's my feature!" argument almost always comes up.
It is not reasonable to expect that feature X that is very important to you has to carry the same weight for other people.
Some people think that it is unthinkable to write programs without feature X. If you think that way, then Go is probably not a language for you. Note however that there are many people who do not think that absence of feature X is a crippling thing, and do enjoy writing programs in Go.
> It's a tiny community [...]
in total contrast with... Nimrod community?
> in total contrast with... Nimrod community?
He _was_ referring to the Nimrod community here.
Yes, but it remains to be seen how Go's view on data structures map Objective-C and Java APIs.
As for Android support, the Android team doesn't seem to care any little bit about it, given their statements on Google IO.
So you have developers of a Google language trying to target a Google platform, where the platform owners just want to support Java (NDK is a kind of stepchild).
Even though I don't like some of Go's decisions, it would be nice to see it on Android. After all, I created the ticket request on Android Tools.
But the feedback at Google IO from Android's team in this regard was disappointing.
The ticket was created back when I was still into Go and was wishing for first level support on Android.
Still I think it would be nice if it would be supported for those that like the language.
What I am doing are very basic hobby projects, when private life allows for, which is seldom the case nowadays. You can check some of them with my nick at GitHub.
If I would be doing a commercial app, I would be buying either Qt or Xamarin, mainly because they are better known and using Pascal like languages (except maybe Ada) is no longer relevant on my CV.
I'll make it simple. Nimrod has one feature - only ONE - which differentiates it from Go. It's not generics, it's not inheritance, it's not proper error handling (cos they're all just fancy features which nobody really needs, right?), it's not even optional garbage collection (although that's a part of it, Go is not suitable for constrained real time applications because of its opinionated lack of optionality in this space).
It's REACH.
You know, the thing that has made JavaScript the most widely used language on the planet - and nobody's claiming THAT's got the greatest feature set.
> iOS and Android supports are on their way in case you're not following recent developments.
Yes I am, and the closest I came up with was this:
https://bitbucket.org/minux/goios/wiki/Home
Seriously? I mean, have you tried this? Have you even tried to make sense of the build instructions?
If you have the inside line on some secret Google plans for Go then good on you. But if you're going to make public claims like this - in a forum where people might be interested to hear about tools that help them DO cross-platform development rather than just dream about doing it one day - you should be prepared to back them up.
Challenge: you implement a cross platform library in Go, I'll do one in Nimrod, we'll upload working XCode and Android projects that use our shared library and that compile to App Store / Play Store eligible apps to Github. I'm up for it - are you?
Well, you can if you MUST: https://bitbucket.org/minux/goios/wiki/Home
> Or your Swift to Linux.
I suspect that'll be a different story next year.
A function named "frobulate" - what is frobulate? I dunno. The function calls: thingsToFrobulate, logit, cleanupOldest, processOld, doNewThing, cleanup and somehow FrobulatingMessage is set on the way.
Honestly; you can do the most clever functional programming in the world but if you naming is like this then your code is just going to be bananas.
And BTW: both Swift and Go are missing exceptions; I think those would be very helpful here.
Once you know that the names being used are not considered to be "important", the other names aren't as important as well, only the syntax. These metasyntactic variables are useful for avoiding situations like "Who's on First?" (e.g. https://www.youtube.com/watch?v=kTcRRaXV-fg ) which is humorous to native-English speakers, but probably incoherent to non-native English speakers.
- Type system needs to be improved e.g. generic code
- Verbosity, duplication of code are painful
- Lack of functional features
- Tooling
- Maturity
For me, the biggest pain point is, to be honest, dealing with json. json in Go is not as fast as you would expect, due to the overhead of runtime reflection. Parsing "loose/dirty" json is also painful. If you cant be sure ahead of time if a value is `"1"` or `1` (int or string of int), and have to support both, you are going to have a bad time.
> If you cant be sure ahead of time if a value is `"1"` or
> `1` (int or string of int)
Sometimes you actually have to deal with what you get, and can't just "fix the other end".
I personally struggled with the json parsing issue a fair bit, but persevering resulted in me having a mostly static typed setup which has ended up being much better than when I've used JS or Python.
I haven't had an issue with code duplication at all. If you do, you might just not have gotten deep enough into how interfaces work yet.
When you use the standard library it's clear it was designed by people who have been programming computers since the Plan 9 days, I consider it much more mature than Python's equivalents.
In terms of tooling, having go fmt run on every save is wonderful, your code is always and instantly formatted perfectly. Beyond that, I haven't needed much.
For me, that means every time I attempt to write code in Go my nose is rubbed in the "this language was built by assholes who have no respect for you".
I guess it does take some of the aesthetic or artistic quality out of it, but in practice it's never bothered me. On the contrary, not having the option removes quite a bit of mental overhead on what (to me) comes down to a fairly religious but ultimately inconsequential viewpoint.
Why? Go types (without generics) are much stronger than in Python aren't they?
In python, every function is as generic as it can be.
Map func(interface{}, func(interface{}) interface{}) []interface{}
Map([]string{"a", "b", "c", "d"}, ToUpper)The situation where you drop the types is the equivalent to Python isn't it?
Saying "we don't need map, we have for", is akin to saying "we don't need toUpper, we have for loops" or "we don't need functions, we have goto".