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)
> 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.
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?
Yeah, not sure if you caught this before my edit, but I didn't see the release notes that said 500k at first. I didn't realize that webassembly could be gzipped and get that much savings.
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.
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.
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.
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.
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.
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.)
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 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.
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.
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.
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).
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!
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.
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.
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?
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?
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.
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.
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:
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.
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.
74 comments
[ 2.8 ms ] story [ 151 ms ] thread[1] https://dev.karakun.com/java/2018/06/25/java-releases.html
if you're interested, there's a series of articles explaining how modules work here: https://research.swtch.com/vgo
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)
I'll be interested to find out more about interactivity with the rest of the javascript world via syscall/js.
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.
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?
This isn't a limitation we'd see with something like Rust.
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).
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.
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.
[0] https://github.com/gothinkster/realworld
No linker will ever do that.
(Of course that would open up all the sorts of issues that static compiles get rid of.)
You can also use C or Rust and avoid GC altogether. Rust produces very small WASMs
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.
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...
Could you elaborate on this? Are you perhaps talking about STM? I can't think of anything else that is really missing.
https://github.com/golang/go/issues/15292
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.
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.
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"
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.
https://dave.cheney.net/2017/07/22/should-go-2-0-support-gen...
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 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
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!
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.
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-...
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?)
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