Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

131–140 of 235 posts

Re: A year with Go

#131

Post by politician »

twic wrote: post #72
mikeokner wrote: post #11

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. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

> You install a JRE on the machine. You deploy.

That's two steps. The first one can ruin your day.

Re: A year with Go

#132

Post by mbernstein »

twic wrote: post #77
xrstf wrote: 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?

Are you seriously suggesting language designers should care about every sort of markdown syntax that exists when determining how a language looks syntactically?

Take a step back and think about your statement...

Re: A year with Go

#133

Post by threeseed »

fixxer wrote: post #108

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…

I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

Re: A year with Go

#134

Post by threeseed »

ascendantlogic wrote: post #90
threeseed wrote: post #56

Earlier quoted context omitted.

Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes se…

"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.

Not the best but the Techempower one is one example:

https://www.techempower.com/benchmarks/#section=data-r9

And arguably more real world than microbenchmarks.

Re: A year with Go

#135

Post by threeseed »

Alphasite_ wrote: post #89
falcolas wrote: post #82

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.

Yeah. But you don't have to, you're literally complaint that the user has options. It's not like Go doesn't have a GC either.

And the biggest joke is that when you tweak the default settings you often end up making it worse.

The JVM has generally excellent performance with the defaults.

Re: A year with Go

#136

Post by eoi »

SiVal wrote: post #71
skymt wrote: post #36

Earlier quoted context omitted.

It's typically not a good idea to choose technology based on fashion. If you like what Go has to offer, it's there for you to use, and don't let the hype backlash get you down. Maybe start with a small personal project, if you don't want to commit to working with it "in production."

The problem is that trying a language isn't like trying a new restaurant. At a new restaurant, I'll know within an hour almost all I would know after a year, and my chances of misjudging the restaurant that first hour are both low ("Hmm, none of these dishes taste very good to me, and I'm not wrong about that") and of minimal consequence (maybe there are better dishes I missed, or not, but I can just try a different…

I agree with you that there is value in these varied opinions. I think it's part of why this sort of post tends to get upvoted regardless of whether it is positive or negative about the technology.

In his blog post written roughly a year ago about his first week using Go he says this:

> gonna be dealing with Go for a while and will have to make the best of it.

I could be wrong, but I get the impression that if it were solely up to him the project might have been written in Erlang either from the start or after trying Go for that first week.

Re: A year with Go

#137

Post by threeseed »

politician wrote: post #131
twic wrote: post #72

Earlier quoted context omitted.

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

> You install a JRE on the machine. You deploy. That's two steps. The first one can ruin your day.

How so ? It takes minutes to install it.

Just download it, copy it and set JAVA_HOME to make it easier for other applications.

I've done this on hundreds of servers during my lifetime and never once had an issue.

Re: A year with Go

#138

Post by TheDong »

nkozyra wrote: post #105
ascendantlogic wrote: post #90

Earlier quoted context omitted.

"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.

As always, it depends on what you're measuring. I find it to be largely a wash http://benchmarksgame.alioth.debian.org/u64q/go.html Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.

You say that, but because 1.5 is written in Go, it actually does significantly worse on some benchmarks and actual programs.

See: https://talks.golang.org/2015/state-of-go-may.slide#11

Re: A year with Go

#139

Post by NateDad »

chc wrote: post #92
neoyagami wrote: post #68

Earlier quoted context omitted.

Like gosublime?

Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).

Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up.

I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I have better things to do than install editor plugins.

Re: A year with Go

#140

Post by fixxer »

threeseed wrote: post #133
fixxer wrote: post #108

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…

I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

What was your takeaway from the blog post?
Post reply on HN