Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
Go 1.5 Release Notes
61–66 of 66 posts
Re: Go 1.5 Release Notes
#62Earlier quoted context omitted.
They've been solved for many other languages but not for Go. The lessons learned don't necessarily translate well between languages, because different problems need to be solved. Each language is a bag of features that need to work well with all the other features included in the language.
Do you find Go imposing any special set of contraints? If anything is far less featureful and Algol-like than most of the other languages that have found a way to fit Generics.
As far as I know it's not that something couldn't be shoehorned in, but rather that the language designers' tastes result in additional technical constraints.
Apparently they don't want to support only boxed types (like Java), and they also don't want to generate multiple implementations of each generic function for each size, resulting in code bloat (like C++), or to generate code at runtime (like, say, Julia).
You could argue that they should just make a choice and go with it because generics are so important, and some language designers would do that, but then these differences in design goals are why we have different languages in the first place.
This is based on an early article by Russ Cox [1]; I don't know how the teams' position has evolved since then.
Re: Go 1.5 Release Notes
#63Earlier quoted context omitted.
Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody…
You certainly can implement Go-like interfaces alongside generics. There's nothing inconsistent about them.
Yes, but the typical consequences that arise out of that do not fit with design goals of Go.
Just off the top of my head - boxed types, for example lead to Java-style inheritance patterns. This sits awfully with composability and readability of Go code. You read Go code like a tree. You read Java code as multiply linked list.
Re: Go 1.5 Release Notes
#64The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. ...and all of a sudden, GC becomes a non-issue for all but the most highly performing software.
10ms is still a gargantuan amount of time for any type of application that must present a smoothly animated UI (not just games), about 60% of the per-frame budget. Every frame where the GC decides to kick in would result in a skipped frame, which is very noticeable. The only acceptable type of garbage collector for this type of application (and I wouldn't call an animated UI application a "most highly performing soft…
Did you read ? With 1 Gig of Heap that's less than 1ms, and if you're creating a UI or a gaming engine there are ways to recycle objects in order to prevent GCs from working on useless object groups
Re: Go 1.5 Release Notes
#65Mine "go" experience comes with the latest docker 1.7. Ok okay. it comsumes 37% of 512 MB memory. That's fine. I will shutdown all of my apps for you. :P
Re: Go 1.5 Release Notes
#66Good to momentum is still growing with the arm64 port, I remember a year ago it was looking like it may never happen. https://twitter.com/maver/status/496376555237806080 but in Feb the story changed and with this release it's well on it's way to a full port. https://twitter.com/davecheney/status/567621293109821440
And by the time it's stable, it will be useless for official iOS development, since Apple will require developers to submit apps in LLVM bytecode (they nicknamed it "Bitcode"). For Apple Watch apps, this is already mandatory.
For Apple this makes sense if they want to switch architectures or add additional extensions to their CPU's and not require all developers to re-submit their apps, but it sucks a bit for the darwin/arm64 port of Go. Maybe we'll see an LLVM bytecode target in a few years? Then Go applications could also benefit from LLVM optimizations.