8 ms·
Go 1.11 Beta 1 is released
- bigato 8y agoGo 1.11 Release Notes: https://tip.golang.org/doc/go1.11 https://tip.golang.org/doc/go1.11 - Go 1.11 adds experimental, integrated support for package versioning (vgo). - Go 1.11 adds an experimental port to WebAssembly (js/wasm).
- ssutch3 8y agoOfficial vgo proposal: https://github.com/golang/proposal/blob/master/design/24301-versioned-go.md https://github.com/golang/proposal/blob/master/design/24301-... Github tracking issue: https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301 Official wasm design doc: https://docs.google.com/document/u/1/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/edit https://docs.google.com/document/u/1/d/131vjr4DH6JFnb-blm_uR...
- rlbaker 8y agoImportant to note about `vgo` for beta1 though: > NOTE: This is not present in go1.11beta1 but will be available in future betas and subsequent releases.
- shabbyrobe 8y agoOk, ninja edit, this whole comment was based on a misunderstanding and adds no value to the discussion. I've been corrected below, the rest does not need to be preserved. Downvote it to the bottom for me please; I can't seem to delete it.
- Thaxll 8y agoThey never said vgo would be production ready for 1.11, they said experimental until 1.12: https://github.com/GoogleCloudPlatform/runtimes-common/issues/683 https://github.com/GoogleCloudPlatform/runtimes-common/issue...
- shabbyrobe 8y agoThanks for pointing that out, I've been trying very hard to keep up but somehow missed that detail. Perhaps it should be in the release notes!
- schrodinger 8y agoI would have found it useful if you left your original comment below the edited disclaimer :)
- rlbaker 8y agoI'm not fully versed in the what the transition to the `vgo` proposal will look like, so pardon my ignorance. Will it be available behind an environmental variable like the vendor experiment was?
- justinclift 8y agoOh, it's looking like the ground work for future RISC-V support is happening too. https://go-review.googlesource.com/c/go/+/106256 https://go-review.googlesource.com/c/go/+/106256 That's really good news. :)
- hugelgupf 8y agoAlmost complete, but stalled, and based on Go 1.8: https://github.com/riscv/riscv-go https://github.com/riscv/riscv-go
- stcredzero 8y agoI think I just realized something about golang as I was walking down the hall. This is something which confuses many people in a way which many respond to with unwarranted emotion, since they are unable to make this connection. Since Go uses Duck Typing, having certain methods is effectively a Type Annotation for a given type implementing an Interface. Many programmers, failing to realize this, become outraged at "boilerplate." It is a design trade-off forcing the programmer to specify all cases when implementing an interface, in much the same way that golang's exception handling eschews tools that let you create clever catch-alls and requires you to specify everything. It's just the "no magic" tradeoff.
- jfoutz 8y ago> requires you to specify everything That's not my experience. checking for errors is completely optional. I'm probably just a bad lazy programmer that leans to hard on the compiler. I like the catch everything and then refine error handling as i get more understanding of failure modes (i'm from java, i avoid runtimeexception). Go makes me feel like i need to understand all possible error cases for every line as i type it. I feel like i have to handle it right now, forever, or i'll forget that line can have an error. I really miss being able to gradually refine error handling, because i can rely on the compiler to remind me about all the stuff that can go wrong.
- mdanger007 8y agoYou can throw away errors, by assigning errors or panic with Must. But a goru said, Why not log everything? Must(func()(val, err)) -> LogIf(func()(val, err))
- dagss 8y ago...that would be nice except you need to reimplement LogIf or Must again for every single function signature due to lack of metaprogramming..
- sagichmal 8y agoIndeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you type it, rather than afterwards.
- wiremine 8y agoWhat are some good use cases for compiling Golang code to wasm?
- pietroglyph 8y agoWriting most of your front/backend business logic in Go is one possibility, but I think that easily moving complex logic to the web as a platform (especially for web demos, see these[0] example with gopherjs) is the most compelling possibility. Generally, I'm excited that this democratizes the web programming space, because the best use cases are often the ones no one has thought of yet. [0]: https://hajimehoshi.github.io/ebiten/ https://hajimehoshi.github.io/ebiten/
- chillydawg 8y agoEven just boring stuff like being able to have one object definition somewhere shared between client and server is useful.
- tbrock 8y agoAnyone ever notice that the assignment + declaration syntax looks like a sideways gopher? :=
- deleted 8y ago[deleted]
- Twisol 8y agoI've seen it called the Zoidberg operator, too -- but I can see the gopher now that you mention it!
- rqs 8y ago- := + Ɛ:= Add the missing ears It actually works as long as no `gofmt` applied. Code: https://play.golang.org/p/bMDxAq_l6F0 https://play.golang.org/p/bMDxAq_l6F0
- reificator 8y agoAll these wholesome ideas make me feel bad because the name that came naturally to me is crass.
- drakonka 8y agoThat's what I'll be calling it from now on.
- bigato 8y ago"The gopher operator"
- cpeterso 8y agoThis change is interesting: crypto: randomly read an extra byte of randomness in some places. https://go-review.googlesource.com/c/go/+/64451 https://go-review.googlesource.com/c/go/+/64451 Firefox has a similar testing feature called "chaos mode" that tries to shake out bugs by doing things like randomly forcing short file or socket reads or changing hashtable iteration order. Due to the increased chance of buggy behavior or performance issues, this isn't the sort of thing you would do in production (unless you're on Netflix's chaos engineering team. :)
- omarforgotpwd 8y agoI don't think this is to shake out bugs. This is just to have a more random pseudo-random number generator so that applications using the crypto package for encryption will be more secure.
- staticassertion 8y agoWhy would it do it randomly then? Just read in the extra byte if you want extra entropy.
- rsc 8y agoStarting at the link above, click on the #21915 in the commit message, which takes you to https://golang.org/issue/21915 https://golang.org/issue/21915.
- staticassertion 8y agoSo for no reason, it is about forcing code not to rely on the behavior.
- baq 8y agoThere's a reason given.
- stephen 8y agoWow, vgo seems pretty reasonable. ...I have to take one of my "damn it, go" complaints back. Interesting to see their critique of bundler/et el...AFAICT isn't this vgo min version just old-school Maven resolution + semver major version in the import path? Tools to auto-bump semver by examining the code's own public API would be nice.
- Sajmani 8y agoThe "go release" command is intended to support selecting the right version for a new package release. The golang.org/cmd/api command detects incompatible API changes and so can serve as the basis for an auto-bump feature. I'd also like to see a command to generate a new major version as a wrapper of the previous major version (or vice versa), to simplify creating major versions that can coexist within the same program.
- dis-sys 8y agoFree lunch is over for me. For the past 4 releases, each delivered 3-5% performance boost to my Go application. Go 1.11beta1 marks the end of that, it is sadly 1-2% slower than Go 1.10. Not complaining, just trying to hear numbers from other developers using their production software...
- chewxy 8y agoI think the next release will have the midstack inlining feature (which has been previewed since Go 1.9)
- pulkitsh1234 8y agoseriously ? Look at this: https://news.ycombinator.com/item?id=17373220 https://news.ycombinator.com/item?id=17373220
- bradfitz 8y agoIf something got slower, file a bug with details. We look into all such reports.
- rurounijones 8y ago[EDIT] Will leave the questions up have delved deeper into this myself and the above questions I have are basically answered but I am surprised at the route taken. Seems like everyone should be including the major version in their import path from the very beginning and every subsequence version which seems... ehhhhh. ------------------ Not a Go dev: Is the mantra of "the new package must be backwards compatible with the old package.", which is an underlying requirement for vgo to work, actually followed in the Go ecosystem? It seems crazy to me that a package would have to change its name if it wants to introduce a backwards incompatible change. Has this happened in practice? How does it work? Are people going to suffix packages with "Really major major" version numbers separately from the actual version number? The criticisms of bundler in the proposal seem to be be a bit wierd when the solution is to force a new paradigm on developers to make vgo's job easier. Why even use Semantic versioning at that point since a major version can never be incremented.
- sacado2 8y agoIn all big packages I use: yes, it is. This is actually a must given there was no (standard) version management system. If you have no versioning system and don't make your code backwards compatible, you break someone else's code. So, either you make a new repository, or you make a subpackage in your current repository with the new, breaking version.
- pjmlp 8y agoI the context of versions I think Rickey puts it best, actually there are no guarantees of compatibility. Even a minor update can eventually break someone's code that relied on the bug. "Spec-ulation – Rich Hickey" https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk