23 ms·

Go 1.13 Release Notes

344 points by 0xmohit 7y ago

gameswithgo 7y ago
I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.
- leetrout 7y ago
  Russ Cox gave a talk at GopherCon 2019 and talked about the 4 R's of Simplifying: Reshaping Redefining Removing Restricting And he follows up with examples of how they applied those to the code base. If you've not seen it you might enjoy it. https://www.youtube.com/watch?v=kNHo788oO5Y https://www.youtube.com/watch?v=kNHo788oO5Y
  - ra7 7y ago
    Russ Cox also recently wrote a series of blog posts about Go proposal process, which is also interesting: https://research.swtch.com/proposals https://research.swtch.com/proposals
- ragona 7y ago
  Heh, I like the way Rust proceeds as a language, with regular releases and improvements. I hope Go can make quality of life improvements with similar speed.
- abtinf 7y ago
  I hadn’t thought of this before, but I think you are onto something critical about Go. In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff). I’ve been writing Go for 8 or 9 years now and I value the tool chain improvements far more than the language features. Race detection was a godsend. Indeed, even taking away capabilities (or just being more strict) has been valuable—like when multi-threaded access to slices became an error. In this release, I don’t much care about the new literal prefixes. But I’m excited about the improvement to defer performance and the improved range check panic messages. In a sense, other languages make it easier to to write new code with each release, but every iteration of Go makes my old code better too.
  - purple_ducks 7y ago
    > I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving > I value the tool chain improvements far more than the language features Java 6 may be right up your alley (https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history)
    - orhmeh09 7y ago
      What do you mean by this reference to an older Java version?
- rolleiflex 7y ago
  I think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up. At this point, I think we all have some JavaScript PTSD.
  - fourseventy 7y ago
    i feel the same way!
  - seabrookmx 7y ago
    C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.
  - Cthulhu_ 7y ago
    Yeah, for me the turnaround point for JS was when they added classes - JS is not an oop language and trying to make it look like one doesn't work. Worse, they didn't even implement it properly - no access modifiers. Call me a bit of a luddite but this is one of the reasons why I'm skeptical about generics in Go - it'll be another language construct to keep in mind. Mind you this opinion of mine is baseless because unfortunately I haven't had the opportunity to do any serious go development yet.
- pcwalton 7y ago
  Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.
  - asdkhadsj 7y ago
    Perhaps it's the number of things changing that leads to the feeling of rapid movement. After all, 60 1mph increases are all tiny by themselves. Not sure if that's true or not though. Rust is my daily driver for the last year and even coming from Go (after 6 years) I don't feel the pace is hard to keep up with, or that my code breaks frequently. In fact, I don't think my code has broke as a result of changes once since I switched to Rust. It has happened .. twice maybe, via dependencies, though.
  - burntsushi 7y ago
    Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable. This is why I've been bleating a bit more now than I have before about reducing churn. N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.
  - est31 7y ago
    One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap. * For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?). I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved. [1]: https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle [2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html [3]: https://github.com/golang/go/wiki/MinorReleases https://github.com/golang/go/wiki/MinorReleases [4]: https://golang.org/doc/install/source https://golang.org/doc/install/source
- derefr 7y ago
  I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)
  - remus 7y ago
    Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.
    - pcwalton 7y ago
      This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.
  - gameswithgo 7y ago
    Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.
- kzrdude 7y ago
  Rust has a focus - it is articulated through the roadmap. - 2018 roadmap https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html - 2019 roadmap https://blog.rust-lang.org/2019/04/23/roadmap.html https://blog.rust-lang.org/2019/04/23/roadmap.html It's a big community, and it has time for a lot of development
- bsaul 7y ago
  Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features. Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.
  - littlestymaar 7y ago
    > a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
    - root_axis 7y ago
      I think in practice it has become something closer to a better python than a better java.
      - earenndil 7y ago
        Personally, I don't think it's better than any of those languages.
      - meowface 7y ago
        More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
    - 7y ago
- JTenerife 7y ago
  Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12. Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."
cameronbrown 7y ago
I occasionally use Python for large-scale processing of structured data (XML, JSON) and the data's really messy as you'd expect (malformed responses, missing fields, normalisation, etc..). One of the things putting me off of Go for these kinds of projects is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent. I'm definitely going to see if Go is acceptable for my next project since I really need the performance for my workload, and I've wanted to put this great language to work in something that isn't a toy project.
- axaxs 7y ago
  > is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my workload Careful with that assumption. A pure Go application will in many cases be more performant than a pure Python one, but Python has a better C interop story. In the particular cases of parsing XML and JSON, I'd wager Python is much faster, actually.
  - cameronbrown 7y ago
    > This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Yep. Maybe I just suck at programming but I couldn't write enough tests to avoid not being fed up debugging stack traces in production. I started using Python's type hints, since this was the source of most of the bugs which helped but I'd rather just use a strongly typed language next time. > Careful with that assumption. A pure Go application will in many cases be more performant than a pure Python one, but Python has a better C interop story. In the particular cases of parsing XML and JSON, I'd wager Python is much faster, actually. I've got a few million records pulled from an API so I'm extremely I/O bound and goroutines are easier to work with than Python concurrency. I've also got reasonably complex data processing beyond just XML/JSON parsing. I think on the whole Go is still going to be faster, but thanks for the heads up.
tptacek 7y ago
Honestly, and I don't think I'm snarking (but would have to reflect a bit on it), "0b", "_", and signed shifts are probably going to make Go more pleasant for me than generics would have. This is my favorite release in years.
- leetrout 7y ago
  I was really looking forward to this as well because, at least with `0b`, I get to keep more of my Python muscle memory.
- skunkworker 7y ago
  It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.
  - paulddraper 7y ago
    Underscores are nice. 10 * 1000 * 1000 worked pretty well too.
    - derefr 7y ago
      Compile-time integer exponentiation in Go would be neat, e.g. 5 ＊ (1000＊＊4). I know we have scientific-notation integer literals, but it's not the same thing, especially when trying to calculate e.g. Mebibytes.
      - pkaye 7y ago
        In go you can use scientific notation for integers var x int = 1e9
      - big_chungus 7y ago
        Not sure about go, but you can do this in C as a compile-time constant: #define foo 1.34E8 Maybe go would benefit from a pre-processor? Though it can be somewhat byzantine in C (and result in very unpredictable final source, if abused), it's very helpful to have a complete functional language available for code transformation. It might help go in some cases, too.
DuskStar 7y ago
> The GO111MODULE environment variable continues to default to auto, but the auto setting now activates the module-aware mode of the go command whenever the current working directory contains, or is below a directory containing, a go.mod file — even if the current directory is within GOPATH/src. This change simplifies the migration of existing code within GOPATH/src and the ongoing maintenance of module-aware packages alongside non-module-aware importers. Oh wonderful! This makes switching back and forth between module projects and 'legacy' projects far easier. (Well, at least for me - since I tend to keep all cloned git repos inside the GOPATH. I don't have a problem, really!)
nemo1618 7y ago
Nice to see that out-of-bounds panics will now include the offending index. Was that difficult to implement, or just controversial? Seems like something that could have been added a long time ago and saved much frustration when debugging.
- typical182 7y ago
  I think the concern was that it would be too expensive, but then later they were able to figure out a way to do it. Some more details: https://github.com/golang/go/issues/30116 https://github.com/golang/go/issues/30116
sime2009 7y ago
How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?
- sjroot 7y ago
  “Go is to services what Rust is to systems.”
  - sime2009 7y ago
    Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.
    - pcwalton 7y ago
      Rust has broadly the same concurrency support, with a more powerful compile-time race detector (but one that also comes with a learning curve). The main difference is that Go uses M:N threading, while Rust uses 1:1 threading with optional explicit async/await constructs.
      - sime2009 7y ago
        For the threading difference, do you mean that Rust needs 'normal' threads plus async/await support, but Go can just lean on its built in concurrency support for both cases? i.e. Go threads instead of explicit async style code.
        littlestymaar 7y ago
        Your sentence implies that Go green threads can do both of what 1:1 threading and async/await can, but it's more complex than that: there's a tradeoff between the simplicity (only one concurrency primitive) and the capability of the said primitive: - with it's M:N model, Go cannot really do FFI efficiently, while both 1:1 async/await have no problem with that in Rust. - goroutines are cooperatively scheduled, while OS thread are preemptively scheduled. If you have hot loops, Go's model won't be able yo guarantee fairness between goroutines, which may be a problem depending on your usage. OS threads don't have this problem. - with goroutines you won't achieve the level of performance you can reach with async/await. Go and Rust fills a different niche of programming and take a different stand on this tradeoff: Rust gives you more power at a complexity cost. Go offers you more simplicity, with less power.
dahfizz 7y ago
> Go programs are now compatible with Android 10. That's pretty cool
zubspace 7y ago
I actually just started to use go on windows just to check it out. First impressions from a newbie: - Getting started with go and vscode is kinda bad right now. I installed go, set up GOPATH, installed all kinds of extensions in vscode and then, somewhere down the official tutorial I learn about GO111MODULES, go mod init, vendor folders and the language server... I was completely confused and still am. I removed all extensions except the main one from vscode and the language server was crashing like crazy until I unset GOPATH. Works now, mostly. Intellisense and code formatting seems to be still unstable now and then. But geez, that first experience was horrible. - The syntax is very weird after writing too much C#. Sometimes I have the feeling, that declarations are reversed just for the sake of it. - Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. - I love gofmt and format-on-save. But it was not the default setting. Still don't know if I should use another one. - I hate configuring vscode. After hearing only good things about it, the configurations and keybindings are horrible and that I need an extension for each and every small thing. Maybe I'm in the minority, but Visual Studio is miles ahead in this regard, I think. - Fast compilation times are awesome. I love, that I can create a simple exe without a framework dependency. - I can parse 2GB of simple JSON files in less than 20s. I'm awed. - I have no idea how to compile some modules like the sqlite one. Seems to need gcc..? Do I have to fully switch to Mingw/WSL? - I was losing my mind when I saw my program giving different results on each run... Until I found out about that randomized map iteration.. Funny. - Finding an item in a slice: Yeah, sometimes generics would be nice but let's not start a holy war... - Need to get used to error handling.. It can get really verbose and those scoping rules are strange.. I miss exceptions, but I can get used to the go way. - I love that I can use the official docs locally: godoc -http=localhost:6060 - I had to use google and stackoverflow more than I initially thought for a 'simple' language... But well, I guess that's normal? Sorry for the rambling. I love the simplicity of the language and hope to get into it more. But the initial experience is still, umm, not streamlined, it seems? But I hope that's just temporary.
- ra7 7y ago
  > Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. It's called a short variable declaration that can be used in place of `var` and the type is implicit. var s string s = "foo" vs s := "foo"
mfer 7y ago
I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/ https://codeengineered.com/blog/2019/go-mod-proxy-psa/
- onei 7y ago
  Why do you need a proxy to fetch the modules in the first place? It seems a little odd for a package manager.
  - mfer 7y ago
    The jFrog folks provided a good example with GoCenter. It was optimized for the performance use case. If you used their proxy, released at the end of last year I think, the time to pull a dependency was significantly less than to pull it from GitHub. This leads to things like faster CI builds.
    - onei 7y ago
      Ah, that makes more sense. I was imagining it as a routing thing rather than caching the packages.
      - DuskStar 7y ago
        Also, the dependency resolution really just relies on `go.mod` and `go.sum` - having to download the entire git tree just to access different versions of those files is a bit inefficient. (It also makes it harder for 3rd parties to serve different versions of a dependency to different people - and easier for Google to do the same)
  - matahwoosh 7y ago
    It's so that you can have a seamless module version checksum [1]. The checksum in proxy ensures that you don't "trust on first use" whenever you update a module. [1] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md https://go.googlesource.com/proposal/+/master/design/25530-s...
donatj 7y ago
Contrary to what someone else has said, this is my least favorite release of Go ever. I'm salty about how the proxy, which is enabled by default, makes it so much more difficult to pull private modules by having to set environment variables on everyone's individual machines. I've got an issue being discussed on GitHub about it https://github.com/golang/go/issues/33985 https://github.com/golang/go/issues/33985
- tapirl 7y ago
  go env -w GOPROXY=direct go env -w GOSUMDB=off
  - panpanna 7y ago
    This should be off by default and enabled manually for people who need it.
omaranto 7y ago
I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?
- ainar-g 7y ago
  I'm not sure what you're talking about. Map keys in Go can be strings, numbers, pointers, some structs, etc. And that was the case since at least Go 1.0.
  - omaranto 7y ago
    I always have trouble explaining this limitation of Go maps. First, a string can point to an unlimited amount of data (i.e., it can be of arbitrary length) and all of its characters are taken into account when deciding string equality. Now, an array type in Go is not like that: the length of the array is part of the type. There is (or at least there wasn't when I last checked) no type of all arrays of ints, say, but there is a type of array of 5 ints, a type of arrays of 8 ints, etc. Each of those is of limited size. A slice is like a string, it can point to an arbitrary amoun of data, but slices are not allowed as map keys. A struct has a fixed number of members and is only allowed as a map key if all of its members are of types allowed as maps keys. So a struct type that is allowed as a map key type can only point to unlimited data all used for equality if it contains directly or indirectly a string somewhere. Among types allowed as keys, the only source or arbitrary-sizedness are strings. For example, if you want to represent multivariate polynomials sparsely as a map from exponent vector to coefficients (i.e., the polynomial 3x^2y^3-7xy^4 corresponds to the map {(2,3)=>3, (1,4)=>-7}) you can only do it in Go with the built-in maps awkwardly. You could pick a maximum number of variables and use arrays of exponents as keys. You can leave the number of variables arbitrary and convert exponent vectors to strings (i.e., use {"2,3"=>3, "1,4"=>-7}). I find it frustrating that those are my options.
    - ainar-g 7y ago
      I see now, thanks. Existing maps will probably remain that way forever, but the new Generics Draft Design[1], if implemented, should allow people to easily write a wrapper that will work on anything. [1]: https://go.googlesource.com/proposal/+/58566e5309365c84587aedc5816344daad48ec27/design/go2draft-contracts.md https://go.googlesource.com/proposal/+/58566e5309365c84587ae...
w8rbt 7y ago
Awesome news. Go is C for the Cloud. Can I trademark that? ;)
zadokshi 7y ago
The documentation makes clear, if someone accidentally commits something they shouldn't (i.e. a file containing your users personal details, credentials, etc...) then it is stuck in their proxy forever. It is clear that google employees believe we live in a perfect world where all employees never make mistakes. https://proxy.golang.org https://proxy.golang.org : > "...the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository. We suggest creating a new version and encouraging people to use that one instead."
- xvector 7y ago
  If you commit and push your credentials, they have been compromised, full stop. This proxy should make no difference to how you handle such a compromise.
  - zadokshi 7y ago
    Actually it does make a difference. If an employee accidentally commits a CSV file with customer private data, are you actually suggesting that it should not be possible to remove it? I disagree. The quicker that the personal data can be taken down, the less chance there is for someone to discover that personal data. I can't imagine any large company being comfortable with developers choosing technology that makes this harder to deal with than it should be. (I am not at all suggesting this scenario is ok, simply asking how one would deal with it if the scenario should occur.)
    - xvector 7y ago
      Hmm, you definitely have a point. I was thinking more API tokens and private keys, but confidential data itself falls into a separate category, it cannot be revoked or rolled.
    - infogulch 7y ago
      The go checksum database / go sum / sum.golang.org appends your module name, version, and hash of it's contents into a permanent, immutable, public log as soon the first time it's seen. But sum.golang.org doesn't host any code. On the other hand, proxy.golang.org re-hosts your module, and you can know that the proxy isn't serving you maliciously or differently than anyone else by verifying it via the public checksum database at sum.golang.org. I don't believe proxy.golang.org, or any proxy for that matter, is required to host all of the modules and versions listed. It's a dumb caching proxy, and must deal with all of the real world complexities of hosting user content, including taking it down if deemed necessary. So if they need to take something down from the proxy they can, and the checksum database will only permanently retain the hash of the content that makes up the module.
jftuga 7y ago
I have noticed a slight slow down in my own programs - around 5% compared to 1.12. Has anyone else noticed this in with their programs?
- tomlu 7y ago
  File a bug with a repro? Chances are it'll get fixed if your benchmark is good.
sigjuice 7y ago
So GOPROXY is like AMP for my Golang codebase? Edit: :)
- seabrookmx 7y ago
  Not sure if you were trying to be funny.. but I find this hilarious :P
int_19h 7y ago
Looking at the release notes: > Go 1.13 now requires macOS 10.11 El Capitan or later; support for previous versions has been discontinued. > Go 1.13 now requires FreeBSD 11.2 or later; support for previous versions has been discontinued. FreeBSD 12.0 or later requires a kernel with the COMPAT_FREEBSD11 option set (this is the default). Sounds like they're still using syscalls directly on those platforms. Is Google ever going to admit that it's broken by design, because userspace apps on those platforms (outside of the base system, which is tightly coupled to the kernel) are not meant to be calling into the kernel directly directly, and should do everything via libc and other userspace libs that wrap syscalls?
- terinjokes 7y ago
  This has probably been the case since Go 1.11 (2018/08/24)[0] On macOS and iOS, the runtime now uses libSystem.dylib instead of calling the kernel directly. This should make Go binaries more compatible with future versions of macOS and iOS. The syscall package still makes direct system calls; fixing this is planned for a future release. I'm not an expert in Darwin, but looking at the implementation of the syscall and runtime packages in Go 1.13, and most seem to be via trampolines into libSystem.dylib FreeBSD looks deprecated not because of syscall difficulties, but because missing functionality and upstream EOL.[1] [0]: https://golang.org/doc/go1.11#runtime https://golang.org/doc/go1.11#runtime [1]: https://github.com/golang/go/issues/27619 https://github.com/golang/go/issues/27619
  - int_19h 7y ago
    Fair enough - so it's fixed on macOS, but not on FreeBSD. That they don't run into issues with this constantly on BSD is not surprising - it didn't always break in macOS, either. Syscalls just don't change that much, usually, so you can get away with it more often than not. The problem is that when they do change eventually, every precompiled Go app that used one stops working.
Gibbon1 7y ago
> The existing octal notation indicated by a leading 0 followed by octal digits remains valid. Oh my god why?
- ptman 7y ago
  To not break go1 backwards compat?
  - Gibbon1 7y ago
    Compatible with what exactly. No one uses octal. Here is a link to Pike fucking it up 10 years ago. https://github.com/golang/go/issues/151#issuecomment-66048306 https://github.com/golang/go/issues/151#issuecomment-6604830...
    - psanford 7y ago
      Lots of code uses octal. Its still the standard way of notating file permission bits on unix: os.Chmod(filename, 0777). You would break so much code if you just threw that away.
      - Gibbon1 7y ago
        > Chmod(filename, 0777) Nice example of something else that should have been depreciated about 35 years ago.
      - tandr 7y ago
        > standard way of notating file permission bits on unix: os.Chmod(filename, 0777) ... and honestly, is the ONLY place where I have ever seen octal been used.
- enneff 7y ago
  Compatibility. https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- ithkuil 7y ago
dfgbnjhjjj 7y ago
Pech gehabt
arez 7y ago
Great so now we have a language that leaks my data to a proprietary service and I can't even see what they're doing with that data. Somehow Google becomes more and more like Microsoft was in the old days. Why is it so hard to not be evil? Why is it so hard for devs working at Google to use open-source paradigms and be careful with anything involving corporations? https://github.com/golang/go/issues/34029 https://github.com/golang/go/issues/34029
6ue7nNMEEbHcM 7y ago
Is there some information about how to set-up your own proxy/checksum DB? EDIT: I understand that there are environment variables you can set, but how do I go about deploying my own proxy/checksum server? Is the source code behind https://sum.golang.org/ https://sum.golang.org/ published somewhere?

344 points by 0xmohit 7y ago

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

leetrout 7y ago
Russ Cox gave a talk at GopherCon 2019 and talked about the 4 R's of Simplifying: Reshaping Redefining Removing Restricting And he follows up with examples of how they applied those to the code base. If you've not seen it you might enjoy it. https://www.youtube.com/watch?v=kNHo788oO5Y https://www.youtube.com/watch?v=kNHo788oO5Y
- ra7 7y ago
  Russ Cox also recently wrote a series of blog posts about Go proposal process, which is also interesting: https://research.swtch.com/proposals https://research.swtch.com/proposals
ragona 7y ago
Heh, I like the way Rust proceeds as a language, with regular releases and improvements. I hope Go can make quality of life improvements with similar speed.
abtinf 7y ago
I hadn’t thought of this before, but I think you are onto something critical about Go. In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff). I’ve been writing Go for 8 or 9 years now and I value the tool chain improvements far more than the language features. Race detection was a godsend. Indeed, even taking away capabilities (or just being more strict) has been valuable—like when multi-threaded access to slices became an error. In this release, I don’t much care about the new literal prefixes. But I’m excited about the improvement to defer performance and the improved range check panic messages. In a sense, other languages make it easier to to write new code with each release, but every iteration of Go makes my old code better too.
- purple_ducks 7y ago
  > I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving > I value the tool chain improvements far more than the language features Java 6 may be right up your alley (https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history)
  - orhmeh09 7y ago
    What do you mean by this reference to an older Java version?
rolleiflex 7y ago
I think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up. At this point, I think we all have some JavaScript PTSD.
- fourseventy 7y ago
  i feel the same way!
- seabrookmx 7y ago
  C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.
- Cthulhu_ 7y ago
  Yeah, for me the turnaround point for JS was when they added classes - JS is not an oop language and trying to make it look like one doesn't work. Worse, they didn't even implement it properly - no access modifiers. Call me a bit of a luddite but this is one of the reasons why I'm skeptical about generics in Go - it'll be another language construct to keep in mind. Mind you this opinion of mine is baseless because unfortunately I haven't had the opportunity to do any serious go development yet.
pcwalton 7y ago
Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.
- asdkhadsj 7y ago
  Perhaps it's the number of things changing that leads to the feeling of rapid movement. After all, 60 1mph increases are all tiny by themselves. Not sure if that's true or not though. Rust is my daily driver for the last year and even coming from Go (after 6 years) I don't feel the pace is hard to keep up with, or that my code breaks frequently. In fact, I don't think my code has broke as a result of changes once since I switched to Rust. It has happened .. twice maybe, via dependencies, though.
- burntsushi 7y ago
  Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable. This is why I've been bleating a bit more now than I have before about reducing churn. N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.
- est31 7y ago
  One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap. * For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?). I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved. [1]: https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle [2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html [3]: https://github.com/golang/go/wiki/MinorReleases https://github.com/golang/go/wiki/MinorReleases [4]: https://golang.org/doc/install/source https://golang.org/doc/install/source
derefr 7y ago
I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)
- remus 7y ago
  Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.
  - pcwalton 7y ago
    This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.
- gameswithgo 7y ago
  Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.
kzrdude 7y ago
Rust has a focus - it is articulated through the roadmap. - 2018 roadmap https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html - 2019 roadmap https://blog.rust-lang.org/2019/04/23/roadmap.html https://blog.rust-lang.org/2019/04/23/roadmap.html It's a big community, and it has time for a lot of development
bsaul 7y ago
Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features. Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.
- littlestymaar 7y ago
  > a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
  - root_axis 7y ago
    I think in practice it has become something closer to a better python than a better java.
    - earenndil 7y ago
      Personally, I don't think it's better than any of those languages.
    - meowface 7y ago
      More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
  - 7y ago
JTenerife 7y ago
Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12. Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."

cameronbrown 7y ago

I occasionally use Python for large-scale processing of structured data (XML, JSON) and the data's really messy as you'd expect (malformed responses, missing fields, normalisation, etc..). One of the things putting me off of Go for these kinds of projects is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent. I'm definitely going to see if Go is acceptable for my next project since I really need the performance for my workload, and I've wanted to put this great language to work in something that isn't a toy project.

axaxs 7y ago
> is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my workload Careful with that assumption. A pure Go application will in many cases be more performant than a pure Python one, but Python has a better C interop story. In the particular cases of parsing XML and JSON, I'd wager Python is much faster, actually.
- cameronbrown 7y ago
  > This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Yep. Maybe I just suck at programming but I couldn't write enough tests to avoid not being fed up debugging stack traces in production. I started using Python's type hints, since this was the source of most of the bugs which helped but I'd rather just use a strongly typed language next time. > Careful with that assumption. A pure Go application will in many cases be more performant than a pure Python one, but Python has a better C interop story. In the particular cases of parsing XML and JSON, I'd wager Python is much faster, actually. I've got a few million records pulled from an API so I'm extremely I/O bound and goroutines are easier to work with than Python concurrency. I've also got reasonably complex data processing beyond just XML/JSON parsing. I think on the whole Go is still going to be faster, but thanks for the heads up.

tptacek 7y ago

Honestly, and I don't think I'm snarking (but would have to reflect a bit on it), "0b", "_", and signed shifts are probably going to make Go more pleasant for me than generics would have. This is my favorite release in years.

leetrout 7y ago
I was really looking forward to this as well because, at least with `0b`, I get to keep more of my Python muscle memory.
skunkworker 7y ago
It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.
- paulddraper 7y ago
  Underscores are nice. 10 * 1000 * 1000 worked pretty well too.
  - derefr 7y ago
    Compile-time integer exponentiation in Go would be neat, e.g. 5 ＊ (1000＊＊4). I know we have scientific-notation integer literals, but it's not the same thing, especially when trying to calculate e.g. Mebibytes.
    - pkaye 7y ago
      In go you can use scientific notation for integers var x int = 1e9
    - big_chungus 7y ago
      Not sure about go, but you can do this in C as a compile-time constant: #define foo 1.34E8 Maybe go would benefit from a pre-processor? Though it can be somewhat byzantine in C (and result in very unpredictable final source, if abused), it's very helpful to have a complete functional language available for code transformation. It might help go in some cases, too.

DuskStar 7y ago

> The GO111MODULE environment variable continues to default to auto, but the auto setting now activates the module-aware mode of the go command whenever the current working directory contains, or is below a directory containing, a go.mod file — even if the current directory is within GOPATH/src. This change simplifies the migration of existing code within GOPATH/src and the ongoing maintenance of module-aware packages alongside non-module-aware importers. Oh wonderful! This makes switching back and forth between module projects and 'legacy' projects far easier. (Well, at least for me - since I tend to keep all cloned git repos inside the GOPATH. I don't have a problem, really!)

nemo1618 7y ago

Nice to see that out-of-bounds panics will now include the offending index. Was that difficult to implement, or just controversial? Seems like something that could have been added a long time ago and saved much frustration when debugging.

typical182 7y ago
I think the concern was that it would be too expensive, but then later they were able to figure out a way to do it. Some more details: https://github.com/golang/go/issues/30116 https://github.com/golang/go/issues/30116

sime2009 7y ago

How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?

sjroot 7y ago
“Go is to services what Rust is to systems.”
- sime2009 7y ago
  Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.
  - pcwalton 7y ago
    Rust has broadly the same concurrency support, with a more powerful compile-time race detector (but one that also comes with a learning curve). The main difference is that Go uses M:N threading, while Rust uses 1:1 threading with optional explicit async/await constructs.
    - sime2009 7y ago
      For the threading difference, do you mean that Rust needs 'normal' threads plus async/await support, but Go can just lean on its built in concurrency support for both cases? i.e. Go threads instead of explicit async style code.
      - littlestymaar 7y ago
        Your sentence implies that Go green threads can do both of what 1:1 threading and async/await can, but it's more complex than that: there's a tradeoff between the simplicity (only one concurrency primitive) and the capability of the said primitive: - with it's M:N model, Go cannot really do FFI efficiently, while both 1:1 async/await have no problem with that in Rust. - goroutines are cooperatively scheduled, while OS thread are preemptively scheduled. If you have hot loops, Go's model won't be able yo guarantee fairness between goroutines, which may be a problem depending on your usage. OS threads don't have this problem. - with goroutines you won't achieve the level of performance you can reach with async/await. Go and Rust fills a different niche of programming and take a different stand on this tradeoff: Rust gives you more power at a complexity cost. Go offers you more simplicity, with less power.

dahfizz 7y ago

> Go programs are now compatible with Android 10. That's pretty cool

zubspace 7y ago

I actually just started to use go on windows just to check it out. First impressions from a newbie: - Getting started with go and vscode is kinda bad right now. I installed go, set up GOPATH, installed all kinds of extensions in vscode and then, somewhere down the official tutorial I learn about GO111MODULES, go mod init, vendor folders and the language server... I was completely confused and still am. I removed all extensions except the main one from vscode and the language server was crashing like crazy until I unset GOPATH. Works now, mostly. Intellisense and code formatting seems to be still unstable now and then. But geez, that first experience was horrible. - The syntax is very weird after writing too much C#. Sometimes I have the feeling, that declarations are reversed just for the sake of it. - Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. - I love gofmt and format-on-save. But it was not the default setting. Still don't know if I should use another one. - I hate configuring vscode. After hearing only good things about it, the configurations and keybindings are horrible and that I need an extension for each and every small thing. Maybe I'm in the minority, but Visual Studio is miles ahead in this regard, I think. - Fast compilation times are awesome. I love, that I can create a simple exe without a framework dependency. - I can parse 2GB of simple JSON files in less than 20s. I'm awed. - I have no idea how to compile some modules like the sqlite one. Seems to need gcc..? Do I have to fully switch to Mingw/WSL? - I was losing my mind when I saw my program giving different results on each run... Until I found out about that randomized map iteration.. Funny. - Finding an item in a slice: Yeah, sometimes generics would be nice but let's not start a holy war... - Need to get used to error handling.. It can get really verbose and those scoping rules are strange.. I miss exceptions, but I can get used to the go way. - I love that I can use the official docs locally: godoc -http=localhost:6060 - I had to use google and stackoverflow more than I initially thought for a 'simple' language... But well, I guess that's normal? Sorry for the rambling. I love the simplicity of the language and hope to get into it more. But the initial experience is still, umm, not streamlined, it seems? But I hope that's just temporary.

ra7 7y ago
> Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird.. It's called a short variable declaration that can be used in place of `var` and the type is implicit. var s string s = "foo" vs s := "foo"

mfer 7y ago

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/ https://codeengineered.com/blog/2019/go-mod-proxy-psa/

onei 7y ago
Why do you need a proxy to fetch the modules in the first place? It seems a little odd for a package manager.
- mfer 7y ago
  The jFrog folks provided a good example with GoCenter. It was optimized for the performance use case. If you used their proxy, released at the end of last year I think, the time to pull a dependency was significantly less than to pull it from GitHub. This leads to things like faster CI builds.
  - onei 7y ago
    Ah, that makes more sense. I was imagining it as a routing thing rather than caching the packages.
    - DuskStar 7y ago
      Also, the dependency resolution really just relies on `go.mod` and `go.sum` - having to download the entire git tree just to access different versions of those files is a bit inefficient. (It also makes it harder for 3rd parties to serve different versions of a dependency to different people - and easier for Google to do the same)
- matahwoosh 7y ago
  It's so that you can have a seamless module version checksum [1]. The checksum in proxy ensures that you don't "trust on first use" whenever you update a module. [1] https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md https://go.googlesource.com/proposal/+/master/design/25530-s...

donatj 7y ago

Contrary to what someone else has said, this is my least favorite release of Go ever. I'm salty about how the proxy, which is enabled by default, makes it so much more difficult to pull private modules by having to set environment variables on everyone's individual machines. I've got an issue being discussed on GitHub about it https://github.com/golang/go/issues/33985 https://github.com/golang/go/issues/33985

tapirl 7y ago
go env -w GOPROXY=direct go env -w GOSUMDB=off
- panpanna 7y ago
  This should be off by default and enabled manually for people who need it.

omaranto 7y ago

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

ainar-g 7y ago
I'm not sure what you're talking about. Map keys in Go can be strings, numbers, pointers, some structs, etc. And that was the case since at least Go 1.0.
- omaranto 7y ago
  I always have trouble explaining this limitation of Go maps. First, a string can point to an unlimited amount of data (i.e., it can be of arbitrary length) and all of its characters are taken into account when deciding string equality. Now, an array type in Go is not like that: the length of the array is part of the type. There is (or at least there wasn't when I last checked) no type of all arrays of ints, say, but there is a type of array of 5 ints, a type of arrays of 8 ints, etc. Each of those is of limited size. A slice is like a string, it can point to an arbitrary amoun of data, but slices are not allowed as map keys. A struct has a fixed number of members and is only allowed as a map key if all of its members are of types allowed as maps keys. So a struct type that is allowed as a map key type can only point to unlimited data all used for equality if it contains directly or indirectly a string somewhere. Among types allowed as keys, the only source or arbitrary-sizedness are strings. For example, if you want to represent multivariate polynomials sparsely as a map from exponent vector to coefficients (i.e., the polynomial 3x^2y^3-7xy^4 corresponds to the map {(2,3)=>3, (1,4)=>-7}) you can only do it in Go with the built-in maps awkwardly. You could pick a maximum number of variables and use arrays of exponents as keys. You can leave the number of variables arbitrary and convert exponent vectors to strings (i.e., use {"2,3"=>3, "1,4"=>-7}). I find it frustrating that those are my options.
  - ainar-g 7y ago
    I see now, thanks. Existing maps will probably remain that way forever, but the new Generics Draft Design[1], if implemented, should allow people to easily write a wrapper that will work on anything. [1]: https://go.googlesource.com/proposal/+/58566e5309365c84587aedc5816344daad48ec27/design/go2draft-contracts.md https://go.googlesource.com/proposal/+/58566e5309365c84587ae...

w8rbt 7y ago

Awesome news. Go is C for the Cloud. Can I trademark that? ;)

zadokshi 7y ago

The documentation makes clear, if someone accidentally commits something they shouldn't (i.e. a file containing your users personal details, credentials, etc...) then it is stuck in their proxy forever. It is clear that google employees believe we live in a perfect world where all employees never make mistakes. https://proxy.golang.org https://proxy.golang.org : > "...the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository. We suggest creating a new version and encouraging people to use that one instead."

xvector 7y ago
If you commit and push your credentials, they have been compromised, full stop. This proxy should make no difference to how you handle such a compromise.
- zadokshi 7y ago
  Actually it does make a difference. If an employee accidentally commits a CSV file with customer private data, are you actually suggesting that it should not be possible to remove it? I disagree. The quicker that the personal data can be taken down, the less chance there is for someone to discover that personal data. I can't imagine any large company being comfortable with developers choosing technology that makes this harder to deal with than it should be. (I am not at all suggesting this scenario is ok, simply asking how one would deal with it if the scenario should occur.)
  - xvector 7y ago
    Hmm, you definitely have a point. I was thinking more API tokens and private keys, but confidential data itself falls into a separate category, it cannot be revoked or rolled.
  - infogulch 7y ago
    The go checksum database / go sum / sum.golang.org appends your module name, version, and hash of it's contents into a permanent, immutable, public log as soon the first time it's seen. But sum.golang.org doesn't host any code. On the other hand, proxy.golang.org re-hosts your module, and you can know that the proxy isn't serving you maliciously or differently than anyone else by verifying it via the public checksum database at sum.golang.org. I don't believe proxy.golang.org, or any proxy for that matter, is required to host all of the modules and versions listed. It's a dumb caching proxy, and must deal with all of the real world complexities of hosting user content, including taking it down if deemed necessary. So if they need to take something down from the proxy they can, and the checksum database will only permanently retain the hash of the content that makes up the module.

jftuga 7y ago

I have noticed a slight slow down in my own programs - around 5% compared to 1.12. Has anyone else noticed this in with their programs?

tomlu 7y ago
File a bug with a repro? Chances are it'll get fixed if your benchmark is good.

sigjuice 7y ago

So GOPROXY is like AMP for my Golang codebase? Edit: :)

seabrookmx 7y ago
Not sure if you were trying to be funny.. but I find this hilarious :P

int_19h 7y ago

Looking at the release notes: > Go 1.13 now requires macOS 10.11 El Capitan or later; support for previous versions has been discontinued. > Go 1.13 now requires FreeBSD 11.2 or later; support for previous versions has been discontinued. FreeBSD 12.0 or later requires a kernel with the COMPAT_FREEBSD11 option set (this is the default). Sounds like they're still using syscalls directly on those platforms. Is Google ever going to admit that it's broken by design, because userspace apps on those platforms (outside of the base system, which is tightly coupled to the kernel) are not meant to be calling into the kernel directly directly, and should do everything via libc and other userspace libs that wrap syscalls?

terinjokes 7y ago
This has probably been the case since Go 1.11 (2018/08/24)[0] On macOS and iOS, the runtime now uses libSystem.dylib instead of calling the kernel directly. This should make Go binaries more compatible with future versions of macOS and iOS. The syscall package still makes direct system calls; fixing this is planned for a future release. I'm not an expert in Darwin, but looking at the implementation of the syscall and runtime packages in Go 1.13, and most seem to be via trampolines into libSystem.dylib FreeBSD looks deprecated not because of syscall difficulties, but because missing functionality and upstream EOL.[1] [0]: https://golang.org/doc/go1.11#runtime https://golang.org/doc/go1.11#runtime [1]: https://github.com/golang/go/issues/27619 https://github.com/golang/go/issues/27619
- int_19h 7y ago
  Fair enough - so it's fixed on macOS, but not on FreeBSD. That they don't run into issues with this constantly on BSD is not surprising - it didn't always break in macOS, either. Syscalls just don't change that much, usually, so you can get away with it more often than not. The problem is that when they do change eventually, every precompiled Go app that used one stops working.

Gibbon1 7y ago

> The existing octal notation indicated by a leading 0 followed by octal digits remains valid. Oh my god why?

ptman 7y ago
To not break go1 backwards compat?
- Gibbon1 7y ago
  Compatible with what exactly. No one uses octal. Here is a link to Pike fucking it up 10 years ago. https://github.com/golang/go/issues/151#issuecomment-66048306 https://github.com/golang/go/issues/151#issuecomment-6604830...
  - psanford 7y ago
    Lots of code uses octal. Its still the standard way of notating file permission bits on unix: os.Chmod(filename, 0777). You would break so much code if you just threw that away.
    - Gibbon1 7y ago
      > Chmod(filename, 0777) Nice example of something else that should have been depreciated about 35 years ago.
    - tandr 7y ago
      > standard way of notating file permission bits on unix: os.Chmod(filename, 0777) ... and honestly, is the ONLY place where I have ever seen octal been used.
enneff 7y ago
Compatibility. https://golang.org/doc/go1compat https://golang.org/doc/go1compat
ithkuil 7y ago

dfgbnjhjjj 7y ago

Pech gehabt

arez 7y ago

Great so now we have a language that leaks my data to a proprietary service and I can't even see what they're doing with that data. Somehow Google becomes more and more like Microsoft was in the old days. Why is it so hard to not be evil? Why is it so hard for devs working at Google to use open-source paradigms and be careful with anything involving corporations? https://github.com/golang/go/issues/34029 https://github.com/golang/go/issues/34029

6ue7nNMEEbHcM 7y ago

Is there some information about how to set-up your own proxy/checksum DB? EDIT: I understand that there are environment variables you can set, but how do I go about deploying my own proxy/checksum server? Is the source code behind https://sum.golang.org/ https://sum.golang.org/ published somewhere?