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

181–190 of 327 posts

Re: Six years of Go

#181

Post by alienrobotarmy »

Lambdanaut wrote: post #119
skrebbel wrote: post #115

Earlier quoted context omitted.

Best reason ever! Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun. If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides the…

Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.

All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. I think the blame would logically reside with you.

Re: Six years of Go

#182

Post by [deleted] »

coldtea wrote: post #102
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

> It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 yea…

[deleted]

Re: Six years of Go

#183

Post by sinatra »

dragonwriter wrote: post #177
sinatra wrote: post #173

Earlier quoted context omitted.

> Go supports green threads (goroutines) As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.

> Go produces native code (no VM) Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads. > the goroutines can be multiplexed (depending on implementation) to OS level threads. Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you nee…

I see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.

Re: Six years of Go

#184

Post by dilap »

benreic wrote: post #148
dilap wrote: post #136

Earlier quoted context omitted.

I was confused by that. Is this going to be any different than GO15VENDOREXPERIMENT which we have now?

I guess I was hoping for a composer-like versioning system, but I suppose that's not a given?

It would be a surprise to me, but we'll see. I haven't seen much discussion since the vendor experiment, weirdly. (But I haven't been looking, either.)

Re: Six years of Go

#185

Post by acomjean »

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…

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

Re: Six years of Go

#186

Post by dragonwriter »

sinatra wrote: post #183
dragonwriter wrote: post #177

Earlier quoted context omitted.

> Go produces native code (no VM) Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads. > the goroutines can be multiplexed (depending on implementation) to OS level threads. Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you nee…

I see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.

> So goroutines are just green threads with a nicer name?

I don't know that I'd say "just": like Erlang processes, goroutines have some special features not shared by all other green threads, even with a similar M:N threading model. I'd say that Erlang processes and goroutines are each specific kinds of M:N green threads with unique features and distinct names. So, its useful to distinguish them within the broader category, they just shouldn't be distinguished from the category.

Re: Six years of Go

#187

Post by ASinclair »

tptacek wrote: post #58
jgrahamc wrote: post #55

Earlier quoted context omitted.

Having said that Rob Pike told me that Go is now one of Google's "official languages".

... which just means developers at Go now have permission to use it, along with Python, Java, and C++, to build things, right?

Not so much permission as support. Being an official language means that the core internal libraries have Go bindings.

Re: Six years of Go

#188

Post by k__ »

arxpoetica wrote: post #180
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…

CoffeeScript for Go? ;)

After using LiveScript I wished there was a transpiler for every language to get LiveScript syntax in there...

Re: Six years of Go

#189

Post by beering »

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…

Agreed. All of Go's deficiencies are not deal breakers when it is so well suited to network services that shuffle data around. I wouldn't build lots of business logic in Go, but often I just need to proxy data from point A to point B with some data massaging.

Re: Six years of Go

#190

Post by xenihn »

Anyone happen to have a link to a good guide/tutorial for building a mobile backend in Go with gin? Or know of a public github repository with a good sample project. I've never done any backend work, and I'd like to build a backend for a simple iOS app to start.
Post reply on HN