A year with Go • Hacker News Board

Re: A year with Go

#81

Post by Dewie3 » Sat, Jun 06, 2015, 12:59 AM UTC

baudehlo wrote: post #29

dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

HN was the same about Node too. In a year we will see the same articles about Rust.

Are you bitter that people "don't like" Node any more?

Re: A year with Go

#82

Post by falcolas » Sat, Jun 06, 2015, 1:06 AM UTC

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

Re: A year with Go

#83

Post by artursapek » Sat, Jun 06, 2015, 1:15 AM UTC

rkapsoro wrote: post #58

Go is great and all, but I'm really only using it until Rust is ready.

Rust 1.0 came out recently. What are you waiting for?

Re: A year with Go

#84

Post by codygman » Sat, Jun 06, 2015, 1:17 AM UTC

eloff wrote: post #7

smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

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.

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.

Re: A year with Go

#85

Post by keslag » Sat, Jun 06, 2015, 1:20 AM UTC

lobster_johnson wrote: post #57

meowface wrote: post #39

Earlier quoted context omitted.

I wish there was a language somewhere in between Ruby/Python, Elixir, and Go.

Have you looked at Nim?

I like Nim a lot, though you still need to know C for edge case issues.

Re: A year with Go

#86

Post by pcwalton » Sat, Jun 06, 2015, 1:22 AM UTC

baudehlo wrote: post #63

sanderjd wrote: post #46

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…

The thing you want is called "getting old". You realize the benefits of certain things and know about the weaknesses before they are even brought up. Sadly this can't easily be taught - it is just slowly learned. And yet us old farts continue to be shunned in many parts of the industry (perhaps because we are grumpy old curmudgeons who have seen it all before).

I think programming languages can bring new things to the table. For Go that's M:N userspace threading combined with a shared-everything mutable memory model in a high level language. For Rust, it's memory safety without garbage collection. For JavaScript, it's the event loop model. Those crucial differences make languages usable for unique niches where you won't want to use anything else.

Unfortunately, most of the debate around languages involves "philosophy", where there's little objective measurement that can be done: composition vs. inheritance, the effect generics have on readability, whether immutability is a better way of reasoning about data, whether namespace syntax should use double-colons or periods, and so forth. These debates are endless but don't strike me as very useful: the exact issues that get brought up and argued on HN have been going back and forth largely since the '80s if not earlier, and they're neither interesting (because we've made little progress on consensus) nor relevant (since people who actually need to choose a language based on its merits will choose it because it helps their job, not because of philosophy).

Re: A year with Go

#87

Post by valertin75 » Sat, Jun 06, 2015, 1:25 AM UTC

falcolas wrote: post #82

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

Looks like you don't like working on projects beyond something that says "Hello World"

Re: A year with Go

#88

Post by woah » Sat, Jun 06, 2015, 1:26 AM UTC

threeseed wrote: post #56

nostrademons wrote: post #18

Earlier quoted context omitted.

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

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…

Some people like things that are minimal and good enough. Also, there is a huge swath of engineers who just really dislike writing Java.

Re: A year with Go

#89

Post by Alphasite_ » Sat, Jun 06, 2015, 1:26 AM UTC

falcolas wrote: post #82

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

Re: A year with Go

#90

Post by ascendantlogic » Sat, Jun 06, 2015, 1:28 AM UTC

threeseed wrote: post #56

nostrademons wrote: post #18

Earlier quoted context omitted.

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

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.