Live data from Hacker News

A year with Go

vagabond.github.io

221–230 of 235 posts

Re: A year with Go

#221
post #77
post #70

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?

I'm on hacker news, so I can't actually tell if you're making a joke or not.

Re: A year with Go

#222
post #220

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

I'm perfectly capable, I just don't see the reason. Why should I install a JRE to run your program? The JRE has nothing to do with your program; it's incidental complexity. Go gives us a way to eliminate that incidental complexity and so is a step forward.

Re: A year with Go

#223

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

One option with C# Windows Store apps is that they can generate native code using something called ".NET Native". https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

Re: A year with Go

#224
post #7

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

It might not be common knowledge yet, but C#, F#, and .NET are fully open source and cross-platform. Development is done in public on GitHub (https://github.com/dotnet), and pull requests are accepted from the community. You can even get a support contract from Microsoft and call them up to troubleshoot your .NET project on Linux. No Windows required.

Re: A year with Go

#225
post #212
post #49

Earlier 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…

Maybe you should write a blog post and list those reasons and post it here. Would probably create interesting discussion.

Re: A year with Go

#226
I've had a keen interest in go but haven't used it for anything serious. My impression of it is that its a great replacement for languages like Python and is great at getting things running fast but I have to agree that it doesn't feel like the kind language I wouldn't want to write a large code base in. My huge interest in it is around the single binary deployment and its concurrency model. The language itself I find a bit quirky in some places (some data structures are passed by ref while other by value) and I like my languages concise and elegant.

This 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

#227
post #79

Earlier 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

Thanks for the link – an enlightening read.

Re: A year with Go

#228
post #213

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

> 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

#229

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

The JRE is platform specific, the JAR isn't. Bundling them makes little sense.

Re: A year with Go

#230

Earlier 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…

And this is something that never gets discussed by the hipsters -- the solidity built into the very foundations of the JVM platform.

No, they just wanna write quick Fibonnaci generators in Node and put it up as a Gist.

Post reply on HN