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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

71–80 of 172 posts

Re: The State of Go

#71

Post by AYBABTME »

seanmcdirmid wrote: post #68
castell wrote: post #66

Earlier quoted context omitted.

The same was true during the Microsoft Build event, the difference was that a lot of Microsoft employees registered a new (green) HN account. Not that I'm complaining but it looked more like a coordinated effort than Go language which has minimal PR from Google but is used by many devs around the world and is very big in Asia.

There are a lot of MS employees on HN normally, no need for green accounts. Also, where is Go popular in Asia? I haven't heard much about it in China (it isn't a resume point yet).

That's odd, from within the Go community it's understood that there's a rather large followership in China. At least, speaking for myself.

Re: The State of Go

#72

Post by seanmcdirmid »

AYBABTME wrote: post #71
seanmcdirmid wrote: post #68

Earlier quoted context omitted.

There are a lot of MS employees on HN normally, no need for green accounts. Also, where is Go popular in Asia? I haven't heard much about it in China (it isn't a resume point yet).

That's odd, from within the Go community it's understood that there's a rather large followership in China. At least, speaking for myself.

I've heard this to, but haven't observed it in my part of the industry (systems/PL research with lots of undergrad and grad interns from top ranked schools, who are usually the PL early adopters). Scala has been getting more interest lately, and there is growing interest in Rust.

Re: The State of Go

#73

Post by insertnickname »

est wrote: post #52

I always have this question: Since a large project like Golang has so many auto-build tools and test OSes, how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You know, not tarballs, but actual static binaries as deb packages installable via apt-get. Good examples: http://wiki.nginx.org/Install https://www.percona.com/doc/percona-server/5.6/installation/... I root for open source movement, but to i…

golang.org offers two types of downloads for Linux: a source tarball and a pre-compiled tarball. If you download the pre-compiled tarball, you just have to extract it somewhere and set some environment variables (all explained in detail on golang.org).

If you really want to install Go via your package manager, you can install the golang package from the Ubuntu repositories. However, this package is naturally on an outdated version of Go. Also worth mentioning is godeb[1] which can generate and install a .deb of any version of Go for you.

[1]: http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-g...

Re: The State of Go

#74

Post by est »

insertnickname wrote: post #73
est wrote: post #52

I always have this question: Since a large project like Golang has so many auto-build tools and test OSes, how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You know, not tarballs, but actual static binaries as deb packages installable via apt-get. Good examples: http://wiki.nginx.org/Install https://www.percona.com/doc/percona-server/5.6/installation/... I root for open source movement, but to i…

golang.org offers two types of downloads for Linux: a source tarball and a pre-compiled tarball. If you download the pre-compiled tarball, you just have to extract it somewhere and set some environment variables (all explained in detail on golang.org). If you really want to install Go via your package manager, you can install the golang package from the Ubuntu repositories. However, this package is naturally on an ou…

> extract it somewhere and set some environment variables

That's exactly the problems package would solve, well, plus easy update capabilities.

Re: The State of Go

#75

Post by olavk »

learc83 wrote: post #32
aplummer wrote: post #20

Earlier quoted context omitted.

Doesn't it? Why do people seem to compare them all the time...

Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attractin…

Can you elaborate on the different meanings of 'systems programming'? I just thought it meant OS development.

Re: The State of Go

#76

Post by dvirsky »

Oh man, dynamic loading of Go libraries is going to be awesome. I'm in the process of developing an http API framework/server (yes, yet another one, but why is a different topic). This will allow me to compile the actual APIs running on the server (multiple APIs can run on one server) as shared libraries and have the server automatically start them.

Re: The State of Go

#77

Post by 4ad »

groks wrote: post #44
NateDad wrote: post #37

Earlier quoted context omitted.

There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compi…

> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter... The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly. Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly…

This has NOTHING to do with shared libraries vs. statically-linked code.

The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.

Re: The State of Go

#78

Post by 4ad »

mappu wrote: post #46
NateDad wrote: post #37

Earlier quoted context omitted.

There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compi…

The debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).

I'm not sure if you're complaining about disk space or time spend compiling, but if you're complaining about time spent compiling, the complaint is not valid. Dynamically linked Go programs build just as fast, to a first approximation, as statically-linked counterparts.

That's not at all surprising considering that with static linking, each package is also built only once.

Re: The State of Go

#79

Post by 4ad »

jdoliner wrote: post #38
sanderjd wrote: post #17

The analysis and tracing tools look really wonderful. Have those been in the works / maturing for awhile, or is that all new tooling for 1.5?

I think the tracing tool [0] isn't go specific but rather just a general tracing tool that's been maturing for a while. The support for outputting compatible traces is new to 1.5 AFAIK but that would explain how they have such a nice looking interface already :) [0] https://github.com/google/trace-viewer

The trace viewer is not Go specific, it comes from the chrome browser, but of course the technology that makes it possible to trace Go is very Go-specific.

Re: The State of Go

#80

Post by 4ad »

melling wrote: post #2

Nice little change in syntax. m := map[Point]string{ Point{29.935523, 52.891566}: "Persepolis", Point{-25.352594, 131.034361}: "Uluru", Point{37.422455, -122.084306}: "Googleplex", } may now be written as: m := map[Point]string{ {29.935523, 52.891566}: "Persepolis", {-25.352594, 131.034361}: "Uluru", {37.422455, -122.084306}: "Googleplex", }

This worked for structs since a very long time, the change makes maps consistent too.
Post reply on HN