Go 1.11 Beta 2 is Released(groups.google.com)
groups.google.com
Go 1.11 Beta 2 is Released
https://groups.google.com/forum/m/#!msg/golang-announce/RVR0FzIKBsU/PAxl4-ZVCAAJ
74 comments
Go binaries not running any more on Windows < 7 is going to be a serious issue.
People still running Windows <7 is the real serious issue though. According to http://gs.statcounter.com/windows-version-market-share/deskt..., about 3% are still on XP and 0.65 on Vista. How long would you expect them to support a small unsafe minority that is probably running an illegal version anyway?
I wouldn't trust these numbers too much. Pretty sure Windows XP usage remains far more than 3% in India and China.
When Firefox dropped support for Windows XP and Vista last year, about 10% of all Firefox users were still running XP or Vista. In China, I think XP was almost 20%. You can see the big shift of Windows version share on this Firefox telemetry graph after dropping XP support:
https://hardware.metrics.mozilla.com/#goto-os-and-architectu...
To be clear, Mozilla dropped support for XP and Vista in Firefox's regular "rapid release" channel; XP and Vista users were migrated to the Firefox ESR channel in March 2017 and will continue to receive ESR security updates until this September. Microsoft ended support for XP in 2014 and support for Vista in 2017. Chrome dropped support in 2016.
https://support.mozilla.org/en-US/kb/end-support-windows-xp-...
https://hardware.metrics.mozilla.com/#goto-os-and-architectu...
To be clear, Mozilla dropped support for XP and Vista in Firefox's regular "rapid release" channel; XP and Vista users were migrated to the Firefox ESR channel in March 2017 and will continue to receive ESR security updates until this September. Microsoft ended support for XP in 2014 and support for Vista in 2017. Chrome dropped support in 2016.
https://support.mozilla.org/en-US/kb/end-support-windows-xp-...
And those Indians and Chinese running XP rely on Go apps on their desktop OS?
You make it sound like it's crazy to want to run a Golang application on your desktop. Do you actually believe it's far-fetched for a user to have an app that's written in Go?
It's not far-fetched, but I'd hate for the tools that I use to be anchored on such old/outed systems.
I'm sure ie6/8 is still used somewhat in those countries as well. Should jQuery/React support them?
You have to move on at some point. I'm sure India and China deal with issues similar to this across the board. They are used to it. They've coped. For example, there is a React clone that supports ie8 (forgot the name). Let them do what they do.
I'm sure ie6/8 is still used somewhat in those countries as well. Should jQuery/React support them?
You have to move on at some point. I'm sure India and China deal with issues similar to this across the board. They are used to it. They've coped. For example, there is a React clone that supports ie8 (forgot the name). Let them do what they do.
People don’t do it atm and there’s an argument to be made that supporting legacy OSes in future version of your language is a folly. If there was a huge base of go apps for legacy OSes then I’d see your point but there isn’t.
[deleted]
Pretty sure the vast majority of those are illegal copies of Windows as well.
[deleted]
>Windows < 7 is going to be a serious issue
Because people deploy Go on Windows? And what's more, on Windows < 7?
(And they also need to be able to recompile with the very latest Go?)
Because people deploy Go on Windows? And what's more, on Windows < 7?
(And they also need to be able to recompile with the very latest Go?)
I personally think Go binaries not being supported on macOS 10.9 and earlier is a bigger issue, though the absolute market size is definitely smaller.
bradfitz of the Go team did mention in an earlier thread [1] that this mainly means that they won't be testing on those older OSes.
[1] https://news.ycombinator.com/item?id=16395242
bradfitz of the Go team did mention in an earlier thread [1] that this mainly means that they won't be testing on those older OSes.
[1] https://news.ycombinator.com/item?id=16395242
People still stupid enough to run Windows XP are the real issue here, not Go. Those people need to be quickly isolated on their own little island of stupidity and cordoned/blocked off from the rest of the human population on Earth, ASAP.
No it isn't...
As far as I know, not even Microsoft supports Windows versions below 7 anymore. Vista support has ended, and XP support ended long ago.
How so?
You can still compile with go 1.10
Only for as long as his dependencies can compile with Go 1.10. In my experience it's pretty common for the Go community to rapidly adopt features found in new releases, making it impossible to support old Go versions.
I've seen guys commit code requiring a new Go version the day it was released! My own preference is to wait a few months, but I'm naturally conservative.
I've seen guys commit code requiring a new Go version the day it was released! My own preference is to wait a few months, but I'm naturally conservative.
> I've seen guys commit code requiring a new Go version the day it was released!
I will be that guy once Go 1.11 releases. The reason being, Golang finally added feature [1] we were asking for since Jan 2015, it allows us to replace about 3k LOC of platform specific, low level (syscall) and error-prone code with 10 lines.
[1]: https://github.com/golang/go/issues/9661
I will be that guy once Go 1.11 releases. The reason being, Golang finally added feature [1] we were asking for since Jan 2015, it allows us to replace about 3k LOC of platform specific, low level (syscall) and error-prone code with 10 lines.
[1]: https://github.com/golang/go/issues/9661
This is a no-problem when you vendor your dependencies.
Don't look at it as a burden: look at it as a gift.
When you're born, you have no claim on anyone in the world other than your parents. You can't demand protection from the Singapore police; you can't demand that the consumer protections of Zaire be imposed on your diapers; you are alien to every state on earth. Every state, that is, but yours. At birth, you get the right to make demands of all these other people, and (under rules you'll get to contribute to) they'll answer those demands! You get welfare, healthcare, education — all because of your nation-state.
That's pretty awesome!
When you're born, you have no claim on anyone in the world other than your parents. You can't demand protection from the Singapore police; you can't demand that the consumer protections of Zaire be imposed on your diapers; you are alien to every state on earth. Every state, that is, but yours. At birth, you get the right to make demands of all these other people, and (under rules you'll get to contribute to) they'll answer those demands! You get welfare, healthcare, education — all because of your nation-state.
That's pretty awesome!
[deleted]
I am disappointed every time I see a new Go release and go to check the release notes. The language is still lacking features like generics, sane concurrency primitives and even performance in some cases. Of course the WebAssembly port in 1.11 is an impressive feat of engineering, but I can't see myself replacing core components at my company with Go yet. Fingers crossed.
Generics are very unlikely to happen before Go 2
https://dave.cheney.net/2017/07/22/should-go-2-0-support-gen...
https://dave.cheney.net/2017/07/22/should-go-2-0-support-gen...
>sane concurrency primitives
Could you elaborate on this? Are you perhaps talking about STM? I can't think of anything else that is really missing.
Could you elaborate on this? Are you perhaps talking about STM? I can't think of anything else that is really missing.
If you check each Go release notes for generics you're doing it wrong. If generics will come one day you will have heard about it long before any release notes.
Literally years before.
If you think Go will ever get generics you are fooling yourself.
Google too hard these days?
https://github.com/golang/go/issues/15292
https://github.com/golang/go/issues/15292
The Go team's stance on generics, summarized:
For us to consider generics, show us an implementation, that:
1. Doesn't hurt compile times too much. 2. Doesn't bloat the binary too much. 3. Doesn't hurt run-time performance too much. 4. Doesn't fundamentally change the language syntax too much. 5. Doesn't complicate the type system too much. 6. (My personal fav) - Plays nicely with Go interfaces. (Seriously, good luck with that one!)
Show us that and no problem - you'll get generics!
Now before you go off and waste months doing that, realize that it's them basically politely telling the community to piss off with these generics proposals. But they're free to write comments in a dozen or so Github issues if it makes them feel better, why not.
If you've been following the language since 2010 or so, like I have, you'd know by now that roughly 4 well-thought generics proposals have been shot down by the core team.
Programmers are really horrible with emotional intelligence and reading between the lines, it seems.
For us to consider generics, show us an implementation, that:
1. Doesn't hurt compile times too much. 2. Doesn't bloat the binary too much. 3. Doesn't hurt run-time performance too much. 4. Doesn't fundamentally change the language syntax too much. 5. Doesn't complicate the type system too much. 6. (My personal fav) - Plays nicely with Go interfaces. (Seriously, good luck with that one!)
Show us that and no problem - you'll get generics!
Now before you go off and waste months doing that, realize that it's them basically politely telling the community to piss off with these generics proposals. But they're free to write comments in a dozen or so Github issues if it makes them feel better, why not.
If you've been following the language since 2010 or so, like I have, you'd know by now that roughly 4 well-thought generics proposals have been shot down by the core team.
Programmers are really horrible with emotional intelligence and reading between the lines, it seems.
> The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like.
Yeah, that's there specifically to be pointed to for all the people that say "generics would be easy to add to the language, just do it"
Yeah, that's there specifically to be pointed to for all the people that say "generics would be easy to add to the language, just do it"
"Issue opened two years ago".
Visible work done on generics, beyond go generate, zero.
Unless you also want to teach me how to check Go's source code for the pull request related to that issue.
Until then it is all just smoke and mirrors.
Visible work done on generics, beyond go generate, zero.
Unless you also want to teach me how to check Go's source code for the pull request related to that issue.
Until then it is all just smoke and mirrors.
There is no work done by anyone on the core Go team on generics, you are correct. An open github issue means diddly squat.
It's tagged as "language change" and "Go 2".
There is no Go 2 being planned/worked on - it's just a bucket of thoughts.
It's tagged as "language change" and "Go 2".
There is no Go 2 being planned/worked on - it's just a bucket of thoughts.
There is this https://blog.golang.org/toward-go2
A blog post dated from 13 July 2017, one year later hardly anything changed.
It sounds like other languages fill your needs better. That's okay, different languages target different philosophies and needs.
Which ones? Need compile to executable, no separate runtime/fat jar, non-system language (C, C++, D, Rust, etc.) with garbage collection and is production ready (not pre 1.0).
Release notes: https://tip.golang.org/doc/go1.11
I wonder, is there a chance for go to ever become a paid language?
I get paid for writing Go at my job.
As in ... pay to use it? That concept seems like a relic at this point, no?
He is presumably making reference to the Java[1] situation.
[1] https://dev.karakun.com/java/2018/06/25/java-releases.html
[1] https://dev.karakun.com/java/2018/06/25/java-releases.html
This, exactly.
Such as?
It will come with generics
This beta includes experimental support for modules (also known as vgo)
if you're interested, there's a series of articles explaining how modules work here: https://research.swtch.com/vgo
if you're interested, there's a series of articles explaining how modules work here: https://research.swtch.com/vgo
And here's someone's experiences with it: https://github.com/Vandebron/Vandebron/pull/2532
Getting started with a Go project is now easier and faster - install go runtime, clone, run a command to install dependencies, build & run. No more need for a go specific file structure (although I guess it'll still help if you're doing professional development)
Getting started with a Go project is now easier and faster - install go runtime, clone, run a command to install dependencies, build & run. No more need for a go specific file structure (although I guess it'll still help if you're doing professional development)
Your link is dead, looks like it's a private project?
WebAssembly is a really interesting feature for me.
I'll be interested to find out more about interactivity with the rest of the javascript world via syscall/js.
I'll be interested to find out more about interactivity with the rest of the javascript world via syscall/js.
I'm also excited to see where this leads.
From the release notes:
> Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the resulting size is at minimum around 2 MB, or 500 KB compressed.
The minimum size is a bit unfortunate, but after all it is still just experimental.
From the release notes:
> Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the resulting size is at minimum around 2 MB, or 500 KB compressed.
The minimum size is a bit unfortunate, but after all it is still just experimental.
I imagine it would be possible to do some dead code elimination in the future to get the size down. Still, 500KB is roughly the size of a lot of the real world apps[0]. I'd imagine an equivalent app, written in Go would be around double, given this baseline number. Double isn't soo bad, but it would be nice to get this number down.
[0] https://github.com/gothinkster/realworld
[0] https://github.com/gothinkster/realworld
The Go linker does dead code elimination already.
Dead code elimination can happen in many places. In Go, for instance, an obvious one would be to eliminate most type info for types which will never be queried for introspection.
No linker will ever do that.
No linker will ever do that.
> 500 KB compressed.
WASM has significantly less parse penalty than javascript. A larger bundle size than your accustomed to with pure js is not necessarily a problem.
https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...
https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
WASM has significantly less parse penalty than javascript. A larger bundle size than your accustomed to with pure js is not necessarily a problem.
https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...
https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
The minimum is large, but if you compare it to mainstream js frameworks, it doesn't look that large. (Source: https://gist.github.com/Restuta/cda69e50a853aa64912d). There are several frameworks with size over 100K compressed.
I would say being 20x larger than the largest JS framework is pretty significant. There's a lot of use-cases that are simply not plausible if you need to wait for 2mb to download.
Maybe they can use some DCE to get it smaller, idk. Go binaries have never been that small so I have my doubts, but hopefully!
EDIT: I see the release notes now that says 500k compressed. That's much better. I didn't realize webassembly could be compressed, is this just gzip?
Maybe they can use some DCE to get it smaller, idk. Go binaries have never been that small so I have my doubts, but hopefully!
EDIT: I see the release notes now that says 500k compressed. That's much better. I didn't realize webassembly could be compressed, is this just gzip?
But that's the minimum, i.e. a Hello World. A Go framework that actually has the same level of functionality would surely be much larger. And besides, JS libraries of that size are a bad thing - JS developers have spent a long time working on things like code splitting to get page load times as low as possible. It'll be a huge shame if we throw all that out with WebAssembly.
I mean, this is a limitation of Go. With JS, the "runtime" is in your browser, you've got a beautiful JS engine already. With Go, it would need that runtime bundled. Similar to shipping the JVM with your JAR.
This isn't a limitation we'd see with something like Rust.
This isn't a limitation we'd see with something like Rust.
> Similar to shipping the JVM with your JAR.
The size of the Java Runtime Environment is around 80 MB (compressed). Even with Jigsaw and just the "java.base" module its still 13 MB (compressed).
The size of the Java Runtime Environment is around 80 MB (compressed). Even with Jigsaw and just the "java.base" module its still 13 MB (compressed).
You'd add size when you include whatever DOM abstraction you wind up going with, but at the same time you wouldn't need to add much else because the Go stdlib is pretty complete. On the other hand JS developers are adding Lodash and other utility things that Go already comes with.
Well these days people are using tree-shaking and ES6 imports to only include the lodash functions they actually need.
My point isn't that Go should be banned from WASM or something, but that "5x increase in library size for zero functionality sounds fine" is a disappointing view to see given how hard the JS community has worked on bundle sizes.
My point isn't that Go should be banned from WASM or something, but that "5x increase in library size for zero functionality sounds fine" is a disappointing view to see given how hard the JS community has worked on bundle sizes.
You are comparing some MVC frameworks that brings a lot of functionalities with basically a runtime that does nothing on its own. Compare functionalities AND weight instead, otherwise it makes little sense.
You could argue that you should add the JS / browser runtime to those libraries too, then.
> You could argue that you should add the JS / browser runtime to those libraries too, then.
No, since they are already in the browser at first place. That's the point. I don't need any extra runtime to run JS in the browser.
No, since they are already in the browser at first place. That's the point. I don't need any extra runtime to run JS in the browser.
I don’t understand why you would in this comparison, as it’s the same for both WebAssembly and <js framework here>
Would it be possible to make use of the built in JavaScript garbage collector (I'm assuming not) and/or separate to the Go runtime into some kind of shared linked lib so that at least you only pay the download cost once?
(Of course that would open up all the sorts of issues that static compiles get rid of.)
(Of course that would open up all the sorts of issues that static compiles get rid of.)
The JS garbage collector would be unlikely to work for Go since Go allows pointers into the middle of an object and JS doesn't.
“Make use of the JS GC” is a feature planned for, but not yet accepted or implemented in webassembly.
yes but Go doesn't plan to do that, they feel their GC is better.
You can also use C or Rust and avoid GC altogether. Rust produces very small WASMs
You can also use C or Rust and avoid GC altogether. Rust produces very small WASMs
Yeah it does seem an unlikely fit for go.
I imagine that go to wasm would likely be used for situations where size won't matter too much and will be an acceptable trade off for familiarity or code reuse.
I imagine that go to wasm would likely be used for situations where size won't matter too much and will be an acceptable trade off for familiarity or code reuse.
Can we use XML with multiple namespaces now? I find it weird that 3 years later working with xml namespaces is still troublesome - https://github.com/golang/go/issues/13400#issuecomment-16245...