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

211–220 of 235 posts

Re: A year with Go

#211

Post by igouy »

pcwalton wrote: post #203
nkozyra wrote: post #105

Earlier quoted context omitted.

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.

Note that the benchmarks game is going to count compile time against Java, but not against Go, since Go is AOT compiled and Java is JIT'd. If your app is a long-running server, you should take the benchmarks game numbers with a grain of salt.

JVM start-up, JIT, OSR etc take very little time relative to most of the workloads shown on the benchmarks game.

http://benchmarksgame.alioth.debian.org/play.html#java

The notable exception (not included in summary measurements) is the few tenths of a second run-time for meteor-contest. Of that few tenths of a second: JVM startup takes 95%, JIT and OSR another 4.9%.

Whatever kind-of app you have, you should take general statements about program performance with a grain of salt, there's even a page for that --

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

Re: A year with Go

#212

Post by eloff »

wyager wrote: post #49
eloff wrote: 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.

>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 for implementation means more focus on the problem and less on the infinite number of ways to solve the problem "elegantly". But there are a lot of other factors too. Static typing helps once the code base gets above 5000 lines, for example. Fast iteration from making a change to running the tests again also helps.

Re: A year with Go

#213

Post by eloff »

codygman wrote: post #84
eloff wrote: 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.

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.

Re: A year with Go

#214

Post by eloff »

solarexplorer wrote: post #17
eloff wrote: 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.

Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.

Python is my longest standing favorite language. But after working on a large python project I am cured for life of dynamic languages. I would not use them for anything over ten thousand lines of code ever again if I can help it. Go is now my favorite language.

Re: A year with Go

#215

Post by codygman »

eloff wrote: post #213
codygman wrote: post #84

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.

I work on rest APIs mostly and the Internet of things.

Re: A year with Go

#216

Post by [deleted] »

eloff wrote: post #213
codygman wrote: post #84

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.

[deleted]

Re: A year with Go

#217

Post by k_bx »

f0nd004u wrote: post #205
k_bx wrote: post #198

Earlier quoted context omitted.

It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!

Try building a package with Haskell dependencies for a linux distribution sometime. It is horrifying.

It's not with stackage. You just do pre-setup:

cabal update && cabal install stackage

Building project:

1. clone a project, cd into it

2. stackage sandbox init

3. cabal install --only-dependencies

4. cabal configure && cabal build

If you already used some "lts version", you can put "stackage sandbox init lts-2.4" to second command and it will re-use existing lts-2.4 sandbox without a need to reinstall anything.

That's it. It takes a very long time first time you build with this with some version of lts stackage, and there is some movements towards binary package sets, but I'm not sure on status of that.

Re: A year with Go

#218

Post by twic »

sleepydog wrote: post #130
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…

As someone else who has been deploying Java applications for years, I'm not saying it's hard, but you have to take care when upgrading the JRE on a server, because with most setups (such as the default Sun JDK RHEL packages) it's a shared resource. You can go ahead and bundle a JRE with your jars. With Go this specific problem doesn't exist.

Fair point. I've always used the approach of dedicating a machine to one particular application (using virtual machines once those became available), so the impact of upgrading the a global JRE is limited.

I did once work on a system where we installed two JREs in parallel, and selected which one to use for the app based on an entry in the manifest file. That let us upgrade Java versions under application control, without requiring sysadmin intervention. Took a couple of lines of shell script.

Re: A year with Go

#219

Post by twic »

mbernstein wrote: post #132
twic wrote: post #77

Earlier quoted context omitted.

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

For the avoidance of doubt, my comment was intended as a humorous way to point out to the parent that they had got their code snippets mangled, and i am not seriously advocating Markdown-compatibility as a language feature.

I'm curious, though, as to how you could possibly think i was being serious. Do you spend a lot of time interacting with people with insane ideas?

Re: A year with Go

#220

Post by twic »

sagichmal wrote: post #148
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. 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.
Post reply on HN