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

Six years of Go

blog.golang.org

Post reply on HN
Print view View original

201–210 of 327 posts

Re: Six years of Go

#201

Post by howeman »

biomcgary wrote: post #149
acomjean wrote: post #128

I've started working in Bioinformatics. The languages in use and libraries seem to by Perl/Python and some java. Except for the stuff that needs to be fast, then its C. Although I notice some movement to use Rust instead of C (having installed some C based tools having package management would be glorious). It would seem the concurency model of go would be a great fit for a lot of those existing python/perl tools. My…

I'm a computational biologist that recently ported our webserver (genestation.org) from Tripal (PHP/Drupal) to Go. The performance gains were huge, but the simplicity of development and deployment was even better. I'd strongly recommend Go for a biology web server. However, Biogo is not remotely as far along as Biopython or Bioperl. Also, Perl beats Go for ease of string handling. Unfortunately, there is no equivalen…

> Unfortunately, there is no equivalent to Numpy/Scipy in Go.

We're trying! https://groups.google.com/forum/#!forum/gonum-dev github.com/gonum . Bug reports and contributions encouraged.

Re: Six years of Go

#202

Post by vocatus_gate »

coldtea wrote: post #124
woah wrote: post #36

Earlier quoted context omitted.

It's true though. Go has a small number of language features, and they are only the simplest ones. It can be learned in a day. Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code.

> Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code. So, just like VB then?

Or .bat file master race.

Re: Six years of Go

#203

Post by lobster_johnson »

codygman wrote: post #63

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem. Back in 2009 #go-nuts seemed to be a much different place. I write Go at work, and I admire many of the same things in Go I admire about Python. I still wish generics were part of the language and will say their exc…

What I don't understand is the people who say Go doesn't need generics. Go already has generics: channels, maps, make(), len(), range, etc. are all generic.

Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that somehow Go's standard library needs to be special.

If you look at the standard library, its authors had to jump through some serious hoops in many cases. Packages like "reflect" (the megatype Value), "builtin" and "sort", to pick a few, are a graveyard of typing awkwardness. The sort package and its special function just for sorting strings is practically a written confession.

Generics being a speedbump is an argument I haven't heard before. Can anyone comment on what the performance challenge is? Nim instantiates unique concrete type instances based on their parameters, couldn't Go do the same?

Re: Six years of Go

#204

Post by howeman »

acomjean wrote: post #185
biomcgary wrote: post #149

Earlier quoted context omitted.

I'm a computational biologist that recently ported our webserver (genestation.org) from Tripal (PHP/Drupal) to Go. The performance gains were huge, but the simplicity of development and deployment was even better. I'd strongly recommend Go for a biology web server. However, Biogo is not remotely as far along as Biopython or Bioperl. Also, Perl beats Go for ease of string handling. Unfortunately, there is no equivalen…

Thanks. They new site is snappy. Tripal I had never heard of. It uses "Chado" db schema which I have heard of (though flybase) which while flexible isn't always performant. Performance gains and simplified development are so appealing (I have 12 tools to maintain in Java/perl/php).. Biogo is what I was looking for. https://github.com/biogo/biogo

You said above you 'may start rolling your own packages'. If you're interested in helping develop the numeric ecosystem, please come join us at gonum https://groups.google.com/forum/#!forum/gonum-dev github.com/gonum.

Dan (the lead developer of biogo) is very competent and I'm sure would love bug reports and PRs in biogo as well.

Re: Six years of Go

#205

Post by lobster_johnson »

codemac wrote: post #195
matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

> particularly high-performance small services that do things like fling JSON around :/ Their json system reflects and allocates like a mad-man. It's probably one of the slowest parts of the std library.

Do you know of a faster JSON library? I've been struggling with this. My particular use case is that I don't want any fancy struct unmarshaling; I just want the equivalent of map[string]interface{}.

Re: Six years of Go

#206

Post by vox_mollis »

nickbauman wrote: post #100
codygman wrote: post #63

I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem. Back in 2009 #go-nuts seemed to be a much different place. I write Go at work, and I admire many of the same things in Go I admire about Python. I still wish generics were part of the language and will say their exc…

Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.

This isn't remotely true.

CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.

Re: Six years of Go

#207

Post by plexicle »

lobster_johnson wrote: post #193
matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

I'm not an expert in Go, but can't you inline a statement before the conditional?

  value, err := bar(); err {
    // there was an error
  }
I like how that looks, personally. Obviously YMMV.

Re: Six years of Go

#208

Post by geodel »

coldtea wrote: post #132
vox_mollis wrote: post #127

Earlier quoted context omitted.

and whose majority of development depends on a handful of people Google pays their salaries As opposed to the brilliant stewardship of Larry Ellison?

Well, still not a handful of people, but a huge endeavour, and with a published roadmap for 2 versions ahead. Besides even if Larry said "kill it" tomorrow, Java would still survive -- so much that it's used in all kinds of enterprises.

I think even if Larry said "kill it" Go will also survive :-)

Re: Six years of Go

#209

Post by kornish »

plexicle wrote: post #207
lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

I'm not an expert in Go, but can't you inline a statement before the conditional? value, err := bar(); err { // there was an error } I like how that looks, personally. Obviously YMMV.

It does look better, but `value` will only be accessible inside the block. That's a no-go if you want to perform actions with `value` below.

Re: Six years of Go

#210

Post by vruiz »

lobster_johnson wrote: post #193
matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

> If you have "func bar() (MyStruct, error)", you cannot do "foo(bar())". You must always assign the result to an intermediate variable. You could embed the error in the MyStruct struct instead, but that goes against Go's grain.

Chaining does work, but obviously the function needs the same signature as the return values, which limits things since most APIs don't accept errors as input. But within your code you can structure it to get error values for things you know you will be chaining. Or create wrappers to make your types chainable.

http://play.golang.org/p/5LHXdJlfIM

Post reply on HN