I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
The State of Go
101–110 of 172 posts
Re: The State of Go
#102Earlier 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? Whenever Go is mentioned, Rust has to be mentioned somewhere in that same thread. And vice versa. It's practically law. Perhaps a good indication that the debates tend to be more fashion-driven then about technical points (when the discussion is about new languages itself, that is of course reasonable though).
Right. I think the closest languages to Go, regarding respective niches or overall philosophies, are Java and Oberon. Yet nobody ever compares them.
Re: The State of Go
#103Re: The State of Go
#104Earlier 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?
>I can't tell if you're being sarcastic or not here - why would a package such as this be outdated?
Because of the way software is packaged in most Linux distributions. The upstream version is frozen in that particular release.
Re: The State of Go
#105I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
Go uses ports of the Plan 9 system libraries extensively, so Plan 9 support is probably a freebie, or implicit.
Re: The State of Go
#106Earlier quoted context omitted.
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.
Yea, but isn't Go supposed to be a systems language? You might expect it to pop up more with systems candidates.
Re: The State of Go
#107Earlier 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.
As soon as you put limits like that you have to compensate by risking that you run out of memory -- if you can't meet the deadline, you can't fully scan the heap[1], free, and so on. Or is that wrong?
That seems like another variable to consider if you're in an environment where you have to somewhat control how much memory you use. But I don't know really know anything about the details of garbage collection, I just figured that that would be one of the trade-offs. So correct me if I'm wrong.
[1] Or whatever technique is used
Re: The State of Go
#108I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
Rob Pike, maybe?
Re: The State of Go
#109I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
Rob Pike, maybe?
I take that back: http://rob.pike.usesthis.com/
Re: The State of Go
#110Earlier 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…
> extract it somewhere and set some environment variables That's exactly the problems package would solve, well, plus easy update capabilities.
To install simply download the tarball, extract it to /usr/local/ and add /usr/local/go/bin to your $PATH. If you want to install it to a different location (I like to keep it in my home directory), you just to set $GOROOT to that path and set your $PATH accordingly. To update, just remove the old go dir and extract the new tarball in the same place. I'm ok with it.