News for hackers. Stuff that matters.

sat

Re:Go Is a Shop-Built Jig on Friday September 19, 2014 @03:01PM (#8341940)
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.
Re:Go Is a Shop-Built Jig on Thursday September 18, 2014 @03:55PM (#8337258)
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.
Re:Go Is a Shop-Built Jig on Thursday September 18, 2014 @03:31PM (#8337129)
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.

Re:Go Is a Shop-Built Jig on Thursday September 18, 2014 @03:26PM (#8337104)
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).
Re:Go Is a Shop-Built Jig on Thursday September 18, 2014 @03:22PM (#8337078)
>> 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.

Re:Go Is a Shop-Built Jig on Thursday September 18, 2014 @03:14PM (#8337046)
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.

Re:Go Is a Shop-Built Jig on Wednesday September 17, 2014 @07:55PM (#8332962)
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.