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

91–100 of 172 posts

Re: The State of Go

#91

Post by mkpankov »

microtonal wrote: post #59
chowells wrote: post #18

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.

Why Rust? It doesn't really compete with Go anywhere. I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition. Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch. I think your point needs to be re-iterated m…

> similar timeframes

I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012.

3 years is pretty big difference.

Re: The State of Go

#92

Post by rattray »

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…

> If you really want to install Go via your package manager,

Don't most people want to install X via their package manager?

> However, this package is naturally on an outdated version of Go

I can't tell if you're being sarcastic or not here - why would a package such as this be outdated?

Re: The State of Go

#93

Post by mkpankov »

nindalf wrote: post #81
mcgirr wrote: post #50

Earlier quoted context omitted.

Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.

This particular link has some info about that situation. GC pauses are deterministic starting Go1.5. Application code will run for at least 40ms out of every 50ms. The upper limit for the GC pause is 10ms and its typically lower.

It's not "deterministic". It has limits on time consumption of GC defined. But you still can't tell when, and if, at any given moment you'll have a pause.

Re: The State of Go

#94

Post by microtonal »

mkpankov wrote: post #91
microtonal wrote: post #59

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition. Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch. I think your point needs to be re-iterated m…

> similar timeframes I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012. 3 years is pretty big difference.

I hope you understand first stable release of Rust happened less

Of course, but Rust has been in tech news for a while already. E.g., the Rust 0.1 post garnered 82 comments[1], over 3 years ago. Rust seems to be first mentioned in a submission title 5 years ago.

Of course, their inception was not exactly at the same time. But if we look back in 20 years, it's the same timeframe. Just like e.g. Python and Ruby, despite being 4 years apart. Or C and Pascal.

[1] https://news.ycombinator.com/item?id=3501980

Re: The State of Go

#95

Post by Kurtz79 »

acomjean wrote: post #5

Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain or runtime.", go shared libraries interoperable with c. I'm really a go tinkerer, but I like the langauge. I didn't realize Garbage Collection was so expensive that the goal is to only have it run 20% of the time. But its a good goal. "Run Go application code for at least 40ms out of every 50ms."

I actually was expecting it to have a greater hit on performance.

After all, a go executable can be 2x - 8x slower than a C one (which is still good enough for many uses).

Re: The State of Go

#96

Post by pjmlp »

_ak wrote: post #87
olavk wrote: post #75

Earlier quoted context omitted.

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

The "systems" in "systems programming" can also be interpreted to refer to Google's systems. After all, Go was designed to solve Google problems in a Google environment. That's how I always understood it.

In CS speak that is actually known as "distributed systems", not "systems programming".

Re: The State of Go

#97

Post by sacado2 »

seanmcdirmid wrote: post #72
AYBABTME wrote: post #71

Earlier quoted context omitted.

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.

The thing is, Go is particularly not interesting for PL researchers and geeks seeking novelty. It's more of a boring, pragmatic language. Elixir, rust et al. are much more funny, IMHO. That might be the explanation.

Re: The State of Go

#98

Post by sacado2 »

pjmlp wrote: post #63
vezzy-fnord wrote: post #4

Earlier quoted context omitted.

I was surprised too given the Plan 9 culture's rejection of dynamic linking. However, this will probably deprecate or diminish the RPC and code generation techniques for implementing plugin architectures.

Yet Limbo uses it everywhere.

Yet Limbo is used nowhere. Now that's a paradox ! ;)

Re: The State of Go

#99

Post by wtf_is_up »

rattray wrote: post #92
insertnickname wrote: post #73

Earlier quoted context omitted.

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…

> If you really want to install Go via your package manager, Don't most people want to install X via their package manager? > However, this package is naturally on an outdated version of Go I can't tell if you're being sarcastic or not here - why would a package such as this be outdated?

The Ubuntu 14.04 package ships Go1.2

http://packages.ubuntu.com/trusty/devel/golang-go

Re: The State of Go

#100

Post by sacado2 »

NateDad wrote: post #37
giaour wrote: post #3

Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.

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…

> Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compilation took a long time.

OTOH, it does well with the culture of making a lot of small, specialized executables rather than a single, monolithic application.

Post reply on HN