[sat]

Seriously, in good faith, I attempted to learn and write a simple web application in go.

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.

[kasey_junk]

That's funny, because I'm also a Go skeptic but your 2 points are literally exactly the opposite of mine. On the top 2 of the things I like about Go they are tooling and removed inheritance.

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.

[sat]

>> bloated IntelliJ and the vim plugin as my only option

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.

[kasey_junk]

But that's the beauty of the go tool chain. I have a source browser (godef), a documentation browser (godoc), a code style formatter (go fmt), code vetting (vet), unit testing (go test), a linter (golint) etc. and they are all fast command line programs. This means that it is trivial to setup a vim/command line environment the way I like.

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.

[campoy]

"What we really want is a flattened struct"

That's what we call struct embedding. Check this http://talks.golang.org/2014/go4java.slide#33 for more details.

[sat]

Embedding won't give you a flattened structure with transparency you expect. In other words struct B embedded in struct A will only create a syntactic sugar so that you can access properties of B through A. It won't work in other cases .Check this out - http://stackoverflow.com/questions/24333494/golang-reflectio...

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.

[tagrun]

As you have discovered the hard way, trying to write Java in Go is not productive.

[polux]

IDE support is not a prerogative of Java.

[sat]

I attempted not to. What pulls me back is the fact that I am trying to force go to help me reuse data structures I already have (without turning to reflection everytime or manually typecasting).

[nl]

I've tried Go some too. I disagree with your assessment of the data structures (inheritance isn't always great), but the tool thing I strongly agree with.

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.

[smegel]

> 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 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.

[sat]

Here is a competition. I'd write in Java and you can write in go. Lets crank out a simple ToDo CRUD application. Any bet who will finish faster?

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.

[smegel]

> Lets crank out a simple ToDo CRUD application. Any bet who will finish faster?

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.

[sat]

Well, I was just comparing Java - a complied, strictly typed languages to another in the same domain - Go. Scripting and interpreted languages like python, ruby are a different thing altogether. I agree with you that ruby/rails or python/django get it done a lot faster. On the JVM, we get close but not quite - with Grails and Play. Spring Boot seems to be getting up there as well in terms of productivity. They still have some way to go.

[vorg]

> Scripting and interpreted languages like python, ruby are a different thing altogether. I agree with you that ruby/rails or python/django get it done a lot faster. On the JVM, we get close but not quite - with Grails and Play

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.

[mentat]

Have you looked at this? http://howistart.org/posts/go/1

[sat]

Struct embedding is just syntactic sugar. Have you tried using reflection to look at the fields of the struct? You don't have a chance of looking that the embedded field properties as if they were truly embedded (flattened out as in inheritance) using reflection. Now put that opposite inheritance. No matter what you do (reflection, direct access what not), you still can get to those properties. See why I am saying go is making it harder? Its those cranny little details that you experience that drop your productivity.