Earlier quoted context omitted.
Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better. But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)…
One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?
A year with Go
221–230 of 235 posts
Re: A year with Go
#222Earlier quoted context omitted.
> You install a JRE on the machine. Whoops. That's where you lost me.
Fair enough. I certainly agree that Go is an excellent language for people incapable of doing basic stuff like this.
Re: A year with Go
#223I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. Java has multiple native code compilers, how is it a benefit when Java can do the exact same thing ? (FWIW I learned recently that C# also has at least one native code compiler).
Re: A year with Go
#224Earlier quoted context omitted.
Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.
C# has had excellent concurrency support for quite some time, and is most definitely a utilitarian language. Of course, the elephant in the room is needing a windows-based infrastructure ... but if that's not a huge barrier, it's not an unreasonable choice.
Re: A year with Go
#225Earlier quoted context omitted.
>But Go is still a much better choice for getting things done. What makes you say this?
Experience. I still don't quite understand it fully, but I'm much more productive in Go than any other language I've used, and I have deep experience in about 8 popular languages and passing experience with another 12. I can list things that contribute to that, but a list of ingredients does not equate to a culinary masterpiece. Other people's experience may vary. Being a "boring" simple language with limited options…
Re: A year with Go
#226This post got me to have a second look at Elixir and I spent the whole day going though its documentation and prototyping an idea I wanted to implement in go, specifically because of go's concurrency model. And frankly ELixir is exactly the right fit for me, not only for this case but generally as a language with the kind of elegance and expressiveness I'm drawn to.
Re: A year with Go
#227Earlier quoted context omitted.
See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pa…
There's an entire Wikipedia article on this concept, in fact: http://en.wikipedia.org/wiki/Hype_cycle
Re: A year with Go
#228Earlier quoted context omitted.
As someone who used Go in the past for work and now uses Haskell, I can say that the advantages of Haskell over Go are more than "just theoretical". In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell. The ease of refactoring creates an incentive to improve code.
My experience is the exact opposite. Maybe we work on very different kinds of problems, or maybe it's just because we're different people.
In the interest in figuring out which, what problems do you work with and what are your principles/beliefs/guiding principles in software? :P
Re: A year with Go
#229Earlier quoted context omitted.
For the same reason you don't deploy Windows, BSD and Mac OS X binaries of your Go program to a Linux server.
Yeah I use the Linux binary, I'm not sure what you're saying here.
Re: A year with Go
#230Earlier quoted context omitted.
> You deploy. You're done. Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then... Yeah.
The ability to tune GC and availability of monitoring solutions are things I consider as big pluses for deploying on the JVM. I would love to have a GC which tunes itself to accommodate the workload. On the JVM, G1 is a step in the right direction. How does Go's GC work in this regard - does it auto-tune itself? Also, how are Go programs monitored in production? Are there tools like AppDynamics, NewRelic, JConsole or…
No, they just wanna write quick Fibonnaci generators in Node and put it up as a Gist.