20 ms·

Go 1.17 Beta

118 points by 0xedb 5y ago

37ef_ced3 5y ago
As a developer I continue to be extremely happy with the Go language and the Go tools. Over the past 5 years Go has almost entirely replaced my use of C and C++. My Go programs (e.g., https://NN-512.com https://NN-512.com) are reliable, run fast, build fast, require no shared libraries, and have airtight error handling. Unfortunately, C++ is still necessary for my commercial work and I am amused daily by the absurd complexity and clumsiness of expression, slow builds, dynamic linkage problems across Linux releases, etc.
- pizza234 5y ago
  > require no shared libraries One amusing downside: the Golang hello world binary takes 2 MB; when compiled with gcc though (against libgo, therefore, dynamically linked), it takes an astonishing 60 KB - not even 64 KB!
  - brokencode 5y ago
    For some applications this matters, but for a typical web server or web architecture, which is what go is optimized for, rarely if ever would a couple MB of binary size make a difference.
    - taywrobel 5y ago
      Especially when tossed in a container for most workloads nowadays. You can have a full go binary statically linked and copied into a FROM SCRATCH docker image and it just works, and is miniscule. For example, that's all that the production image of NATS Streaming is - https://github.com/nats-io/nats-streaming-docker/blob/024b04f6c0d4658cf5751b21b48555bbe9280be5/0.22.0/scratch/Dockerfile https://github.com/nats-io/nats-streaming-docker/blob/024b04...
  - foobiekr 5y ago
    ... and then someone puts it in a container, probably sourced without any kind of tracking, and blows cross-app shared library page sharing and adds tons of other on-media bloat. It's so crazy where we are.
    - bitwize 5y ago
      RAM and storage are cheap. Their cost is a mere pittance for the benefits of containerization. It's like when people whinge about Electron. Electron gets you a runtime that's near identical across the major platforms, with a11y (something the Linux native toolkits still don't have their shit together on) essentially for free, plus you can use modern reactive component frameworks like React and Vue on the desktop. Yeah, I'll pay 300 MiB for that.
      - kaba0 5y ago
        I highly doubt that the optimal GUI development is at “modern reactive comp frameworks”, when decade old desktop frameworks had better tooling than that.
        EvilEy3 5y ago
        I seriously doubt that. Mobile platforms and web would be moving towards "decade old desktop frameworks" if those were superior.
        kaba0 5y ago
        Mobile platforms are most definitely not web technology, they are much closer to desktop frameworks. And the only reason the web is not doing so is (was) due to backwards compatibility and HTML being a bad target. But with WASM and canvas-based renderers, desktop frameworks sort of make an appearance on the web (though I personally dislike the canvas-oriented design, which basically throws away every accessibility)
    - pjmlp 5y ago
      I find it more ironic when monolithic kernels are argued for and then get placed in layers of abstraction to achieve what microkernels offer out of the box.
  - simias 5y ago
    That used to bother me with Rust as well, but frankly nowadays it's really hard to argue against it. Even in the embedded world you typically have enough flash these days that you're not counting a couple MBs, and as far as RAM is concerned you'd only save some memory if several binaries run simultaneously while linking to the same shared libs. And even then it's not a sure win, because LTO can remove a lot of useless code from dependencies, so if you only use a small part of a dependency you might still be better off with static linking regardless of other factors. It's pretty hard to justify the complexity and overhead of dynamic linking nowadays, IMO.
    - pjmlp 5y ago
      Depends, dynamic linking is great for plugins, on the other hand I guess we have learnt that IPC is a better option for security and overall application stability.
    - anderskaseorg 5y ago
      Although it used to be worse, these days a standard Rust “Hello, world!” compiles to just 277 KB on Linux with ‘cargo build --release’ and ‘strip’—5× smaller than the equivalent for Go (and there are games you can play to get it down further).
      - simias 5y ago
        Oh, that's very cool, I hadn't checked that in ages. Any idea on what Rust does better here? Better link time optimization? Or is the Go runtime just that heavier?
        colin_mccabe 5y ago
        Rust doesn't really have a "runtime" in the same sense that Go does. For example, Rust has no GC.
    - sitzkrieg 5y ago
      not counting MBs!? must be nice, havent developed on something with 1MB or more in years
  - slx26 5y ago
    No one is actively happy about it, but when you account for garbage collection and other runtime stuff that goes into a regular go program, plus no dynamic linking... you have to be happy with the trade-off. It's the right one for most programs we will ever make.
    - throwaway894345 5y ago
      > It's the right one for most programs we will ever make. Unless you’re in the lucrative hello world industry. Or at least I assume it’s lucrative since so many people come here posting about hello world binary sizes—it certainly seems to employ a lot of people.
  - deleted 5y ago
    [deleted]
- herpderperator 5y ago
  If you wanted to, couldn't you just compile your C/C++ program statically and then it would be comparable to a Go binary?
  - 37ef_ced3 5y ago
    As is true of many developers, I am part of a large team working inside an ecosystem of enormous C++ programs. These programs are written in a particular way (heavily templated) and built in a particular way (dynamic linkage, CMake) and it's neither feasible nor wise to change these foundations
    - herpderperator 5y ago
      I guess the point I am trying to make is if you had chosen to be statically-linked from the start, then it would be comparable to a Go binary of today. If Go had many dynamic dependencies and people became "stuck" with them, and Go later introduced statically-linked binaries, then it would be the same as your C/C++ example, wouldn't it? In other words, it's not a distinguishing factor because you can be fully statically-linked in C/C++ if starting today with a new project with that goal in mind.
      - 37ef_ced3 5y ago
        Sure. But here we have a typical situation where the Go tools get it right by default, and of course a sophisticated engineer can achieve the same effect with non-Go tools even though those tools get it wrong by default
  - deleted 5y ago
    [deleted]
- jsjsbdkj 5y ago
  Go is mostly very good, but the module ecosystem continues to be a nightmare, and having a deep dependency graph can make build times brutal. I work on a project which depends on k8s, which means a cold build take several minutes. Not to mention trying to update dependencies and figure out what versions are actually being built into the final binary.
  - 37ef_ced3 5y ago
    Anyone who works on large C++ projects will laugh at your "several minutes" comment. You may not realize how bad things are on the other side of the fence
    - pjmlp 5y ago
      Only if they insist in compiling the world from scratch, though. On the world of DLLs and COM, those compile times are relatively ok.
    - anthk 5y ago
      ccache
    - fpoling 5y ago
      Yep, without a build farm it takes 6-7 hours to do a full Chromium build...
  - beforeolives 5y ago
    Who is doing dependencies right in your opinion? Because it feels like it's a complaint I hear about every language.
    - coolreader18 5y ago
      Might be biased/stereotypical, but Rust's cargo does dependencies really well. It's as easy as npm to add new dependencies, but there aren't thousands needed to do anything, and if you take a look at your Cargo.lock/`cargo tree` you can really get to know each of them and what they do or why they're pulled in. I'm still bloat-wary, maybe as a leftover from doing webdev, but with less transitive dependencies in the first place you can actually go through and prune things that aren't needed, or open PRs to transitive deps to prune from their trees or update deps to the latest version to deduplicate your tree. (If there are multiple semver-incompatible versions in a dep tree, they just both get compiled in - for most apps though, you should be able to get the number of duplicates to 0 or almost that.)
- rejectedandsad 5y ago
  Calling out again, this is a fantastic program and it's remarkable that this is released pseudonymously (for whatever reason)
  - 37ef_ced3 5y ago
    Thanks man
- bitcharmer 5y ago
  For me the major remaining issue is a golang ide, or lack thereof. You only have 3 options: - Goland from Jetbrains; awesome but costly - Vscode with golang plugin; slow, brittle, little functionality -vim; yuck It'd help adoption greatly if there was a decent free option here.
  - ulzeraj 5y ago
    I love vim. =( Its there everywhere you need it. If I have to use these other fancy pants editors I always enable vim emulation when possible but its never the same.
    - gigatexal 5y ago
      Yeah vim plus govim amazing.
  - haolez 5y ago
    One of Go's creator did a lot of the initial coding in Acme[0] :D [0] https://en.wikipedia.org/wiki/Acme_(text_editor) https://en.wikipedia.org/wiki/Acme_(text_editor)
    - ainar-g 5y ago
      Something tells me that a person who reacts to Vim with a “yuck!” won't like Acme either. Also, I don't know how true this is, but I've read that Acme loses some of its advantages when it's run in e.g. X11 as opposed to its native rio[1] with plumber[2]. [1]: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) [2]: https://9fans.github.io/plan9port/man/man4/plumber.html https://9fans.github.io/plan9port/man/man4/plumber.html
      - haolez 5y ago
        I _think_ that Rob used Acme in OSX, but I can't find this source.
- libria 5y ago
  Off topic: this NN-512 site has good UX for having no CSS/JS (I know, many of you would claim it's because those are omitted...). Did you use some kind of site generator?
  - 37ef_ced3 5y ago
    The program generates the HTML for its own website (in DRAM) and serves that HTML over HTTPS. When you access that webpage, you are communicating with an NN-512 process that is running on a $5/month Linode cloud instance
    - libria 5y ago
      Ok ok I see it in e.g., https://nn-512.com/browse/NN-512#64 https://nn-512.com/browse/NN-512#64. The anchor tags for the listings go to top instead of being self-referencing. Is that a bug? Like format = `<h3 id="%d"><a href="#0">%s</a></h3>` + Should be format = `<h3 id="%d"><a href="#%d">%s</a></h3>` + And Fprintf should duplicate a parameter?
      - 37ef_ced3 5y ago
        No, that's intended. There's an index at the top of each page. You use the index links to jump down. And if you want to jump back up to the index, you use any of the header links. That makes sense to me. It seems useless for a link to point to itself
        libria 5y ago
        > It seems useless for a link to point to itself Hm. I guess the web has programmed me differently. Say I'm CTRL-F searching through the page and I notice an interesting bit of code and say "Hey I have a question about this". Then I start looking for a shortcut to that one file and assume that shortcut is the nearby <h3> header. I expect this because I've seen this pattern implemented a lot. You could have the <h3> be that local anchor and a short [top] link next to it.
tschellenbach 5y ago
Work I need to do to use 1.17: None Benefits: Improved performance and reduced hosting costs Go is so nice for getting stuff done.
svnpenn 5y ago
Random Go fact I learned recently: by default, HTTP requests automatically redirect. If you dont want that, you can do this instead: res, err := new(http.Transport).RoundTrip(req)
- mixedCase 5y ago
  Another fun one, in the masochistic sense, is that the default HTTP client has no timeout, and you can't forget to set it yourself if you don't want to potentially leak connections.
  - Groxx 5y ago
    The stdlib http client is a bit absurd in some areas, yeah. Timeouts in particular are so confusing and misleading that there are quite a few lengthy blog posts about them alone, e.g. https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... Granted, part of it is that it's too complex to be captured by one timeout, but everyone wants one timeout. kinda like string-sub-slicing and UTF-8 multi-byte characters - it's a Bad Idea™ because the over-simplified stuff is fundamentally wrong and will often cause problems. E.g. I routinely encounter tools with short timeouts that don't work on slow network connections (e.g. Bazel), despite actively downloading - what you generally want for user-use is a timeout that ensures the download does not hang forever doing nothing, not the download completes within a specific amount of time. ... but also it's just abnormally bad.
    - shabbyrobe 5y ago
      There are fragments of discussion about the download timeout throughout the issue tracker, which end up leading back to this still-open but seemingly forgotten issue about adding InactivityTimeout: https://github.com/golang/go/issues/22982 https://github.com/golang/go/issues/22982 I'd love to see this one addressed but it's not looking too hopeful at this stage.
  - Philip-J-Fry 5y ago
    No one in their right mind should be using the default HTTP client or server. They only exist to allow you to quick hack something together. For any serious application you should always define your own.
ru552 5y ago
Added a new testing flag -shuffle which controls the execution order of tests and benchmarks. That's a fun one
EFruit 5y ago
As someone who's been using Go for a long while now, I can't help but wonder if modules and other recent changes aren't a step backwards. Maybe I'm a change-averse geezer, but modules still seem like an overcomplicated solution for a solved problem. Needed a particular version of something? Great. It happens. Add a submodule and toss it in vendor/. Why in God's name do we need to proxy source code through Google-hosted services which they've been reluctant to even open source? And at the root of it all, the GOPATH model simply wasn't bad enough to be worth replacing! You have the full source repo right there, in a predictable, semantically-useful location. When you `go get` something, use `-u`. If a package fails to work with the current upstream, vendor an old version, _or update the depending package_! Ideally, I'd only ever have one copy of source code anywhere on my computer, preferably in the form of revisions in a source repo. Contrary to popular belief, disk space and bandwidth are neither free, nor infinite, and I'd like to make good use of mine. NPM and `node_modules` are NOT designs to aspire to! If the Go tooling insists on involving itself with versioning, dependencies, and source control, it should actually USE the source control tools to manage versioning and dependencies! It isn't rocket science to make a temp directory, clone from the local repo, check out a tag, and use that for building. Git even has facilities to check out the tree at a specific commit, no full clone required. (Granted, my view is Git-centric, but I believe that mercurial and svn also allow you to clone and check out labelled versions, especially considering those are _the basic requirements_ of an SCM.) And why do we need to verify cryptographic integrity of downloaded code bundles when the SCMs typically use cryptographic primitives to describe versions? Then to mandate a gatekeeping "sum database" on top of all that? Finally, it is depressing to me how shut-in and closed-off the core team seems. The designs for big language changes are rarely ever proposed by the community, only by people already in the team. While (I hope) the community's input helps inform their decisions, the final module design was rsc's. Before he drafted the design document, dep versioning was a user-space/community problem, but after it came from him, then—and only then—was dependency version management truly considered for the toolchain. The generics design came from, and was accepted by the core team. Rob Pike's recent d̶e̶̶c̶̶i̶̶s̶̶i̶̶o̶̶n̶ proposal to support taking the addresses of simple types is—as one might expect—unquestionably going to be added. The greatest thing that could happen to Go would be a community-organized and -centric fork, like Gitea was to Gogs. Even if they didn't maintain strict compatibility with each other, I know which one I'd use.
kubb 5y ago
I've been using go for years now at my work, and I have to say that it does have applications where it's a perfectly capable tool. The problems arise when you try to do something it's not good at and you start wrangling with the language. If your coworkers have strong opinions on how Go is supposed to be used, it can make matters worse. My biggest qualm by far is the limited type system, e.g. it has no concept of immutability or non-null pointers :( Also accomplishing simple things sometimes requires surprisingly weird techniques, e.g. cloning a slice. The lucky people can evaluate a problem and choosing the right tool for it. The unlucky bastards like me get handed a language and are expected to build everything in it. It can be rough sometimes.
- exacube 5y ago
  > e.g. cloning a slice. https://golang.org/pkg/builtin/#copy https://golang.org/pkg/builtin/#copy
  - kubb 5y ago
    I've been using Go for years, of course I know about copy. Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get: https://github.com/go101/go101/wiki/There-is-not-a-perfect-way-to-clone-slices-in-Go https://github.com/go101/go101/wiki/There-is-not-a-perfect-w...
    - exacube 5y ago
      Apologies for my tone, I didn't mean to insinuate you weren't experienced. I guess I was wondering what was wrong with copy(), thanks for the link! IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing. > Drawback 1: if s is nil, the result sClone is not nil. I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time. Sorry again for my tone, it's easy to appear rude on the internet on a late night.
exacube 5y ago
My favorite part: Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. This work is enabled for Linux, MacOS, and Windows on the 64-bit x86 architecture... For a representative set of Go packages and programs, benchmarking has shown performance improvements of about 5%, and a typical reduction in binary size of about 2%.
- nappy-doo 5y ago
  Just buried in the middle of the release notes: Oh, your code's 5% faster.
karmakaze 5y ago
> Conversions from slice to array pointer: An expression s of type []T may now be converted to array pointer type *[N]T. If a is the result of such a conversion, then corresponding indices that are in range refer to the same underlying elements: &a[i] == &s[i] for 0 <= i < N. The conversion panics if len(s) is less than N. > Note that the new conversion from slice to array pointer is the first case in which a type conversion can panic at run time. Analysis tools that assume type conversions can never panic should be updated to consider this possibility. WHY! So now we can't trust that the type *[N]T won't panic at runtime when accessed by in-range index values. This should be identified as an unsafe conversion.
- tapirl 5y ago
  Most of such conversions are safe and should not panic (just like the type assertions).
- icholy 5y ago
  The panic happens during conversion before you have a chance to index into it.
jftuga 5y ago
I really enjoy writing command-line utilities to make my system admin job more efficient: https://github.com/jftuga?tab=repositories&q=&type=public&language=go&sort=stargazers https://github.com/jftuga?tab=repositories&q=&type=public&la... Any feedback is most welcome!
exacube 5y ago
It's surpring that Go 1.17 discountined support for MacOS 10.12 (or older), which released only 4 years ago. Along with deprecating Intel support, it seems like Apple, their users and the ecosystem is totally fine not giving a shit about supporting aging software. It doesn't seem like anyone cares that much either. Even more impressive that on average, Macbooks have a much longer lifespan than other laptops, while the software they run is intolerant of old versions.

118 points by 0xedb 5y ago

As a developer I continue to be extremely happy with the Go language and the Go tools. Over the past 5 years Go has almost entirely replaced my use of C and C++. My Go programs (e.g., https://NN-512.com https://NN-512.com) are reliable, run fast, build fast, require no shared libraries, and have airtight error handling. Unfortunately, C++ is still necessary for my commercial work and I am amused daily by the absurd complexity and clumsiness of expression, slow builds, dynamic linkage problems across Linux releases, etc.

pizza234 5y ago
> require no shared libraries One amusing downside: the Golang hello world binary takes 2 MB; when compiled with gcc though (against libgo, therefore, dynamically linked), it takes an astonishing 60 KB - not even 64 KB!
- brokencode 5y ago
  For some applications this matters, but for a typical web server or web architecture, which is what go is optimized for, rarely if ever would a couple MB of binary size make a difference.
  - taywrobel 5y ago
    Especially when tossed in a container for most workloads nowadays. You can have a full go binary statically linked and copied into a FROM SCRATCH docker image and it just works, and is miniscule. For example, that's all that the production image of NATS Streaming is - https://github.com/nats-io/nats-streaming-docker/blob/024b04f6c0d4658cf5751b21b48555bbe9280be5/0.22.0/scratch/Dockerfile https://github.com/nats-io/nats-streaming-docker/blob/024b04...
- foobiekr 5y ago
  ... and then someone puts it in a container, probably sourced without any kind of tracking, and blows cross-app shared library page sharing and adds tons of other on-media bloat. It's so crazy where we are.
  - bitwize 5y ago
    RAM and storage are cheap. Their cost is a mere pittance for the benefits of containerization. It's like when people whinge about Electron. Electron gets you a runtime that's near identical across the major platforms, with a11y (something the Linux native toolkits still don't have their shit together on) essentially for free, plus you can use modern reactive component frameworks like React and Vue on the desktop. Yeah, I'll pay 300 MiB for that.
    - kaba0 5y ago
      I highly doubt that the optimal GUI development is at “modern reactive comp frameworks”, when decade old desktop frameworks had better tooling than that.
      - EvilEy3 5y ago
        I seriously doubt that. Mobile platforms and web would be moving towards "decade old desktop frameworks" if those were superior.
        kaba0 5y ago
        Mobile platforms are most definitely not web technology, they are much closer to desktop frameworks. And the only reason the web is not doing so is (was) due to backwards compatibility and HTML being a bad target. But with WASM and canvas-based renderers, desktop frameworks sort of make an appearance on the web (though I personally dislike the canvas-oriented design, which basically throws away every accessibility)
  - pjmlp 5y ago
    I find it more ironic when monolithic kernels are argued for and then get placed in layers of abstraction to achieve what microkernels offer out of the box.
- simias 5y ago
  That used to bother me with Rust as well, but frankly nowadays it's really hard to argue against it. Even in the embedded world you typically have enough flash these days that you're not counting a couple MBs, and as far as RAM is concerned you'd only save some memory if several binaries run simultaneously while linking to the same shared libs. And even then it's not a sure win, because LTO can remove a lot of useless code from dependencies, so if you only use a small part of a dependency you might still be better off with static linking regardless of other factors. It's pretty hard to justify the complexity and overhead of dynamic linking nowadays, IMO.
  - pjmlp 5y ago
    Depends, dynamic linking is great for plugins, on the other hand I guess we have learnt that IPC is a better option for security and overall application stability.
  - anderskaseorg 5y ago
    Although it used to be worse, these days a standard Rust “Hello, world!” compiles to just 277 KB on Linux with ‘cargo build --release’ and ‘strip’—5× smaller than the equivalent for Go (and there are games you can play to get it down further).
    - simias 5y ago
      Oh, that's very cool, I hadn't checked that in ages. Any idea on what Rust does better here? Better link time optimization? Or is the Go runtime just that heavier?
      - colin_mccabe 5y ago
        Rust doesn't really have a "runtime" in the same sense that Go does. For example, Rust has no GC.
  - sitzkrieg 5y ago
    not counting MBs!? must be nice, havent developed on something with 1MB or more in years
- slx26 5y ago
  No one is actively happy about it, but when you account for garbage collection and other runtime stuff that goes into a regular go program, plus no dynamic linking... you have to be happy with the trade-off. It's the right one for most programs we will ever make.
  - throwaway894345 5y ago
    > It's the right one for most programs we will ever make. Unless you’re in the lucrative hello world industry. Or at least I assume it’s lucrative since so many people come here posting about hello world binary sizes—it certainly seems to employ a lot of people.
- deleted 5y ago
  [deleted]
herpderperator 5y ago
If you wanted to, couldn't you just compile your C/C++ program statically and then it would be comparable to a Go binary?
- 37ef_ced3 5y ago
  As is true of many developers, I am part of a large team working inside an ecosystem of enormous C++ programs. These programs are written in a particular way (heavily templated) and built in a particular way (dynamic linkage, CMake) and it's neither feasible nor wise to change these foundations
  - herpderperator 5y ago
    I guess the point I am trying to make is if you had chosen to be statically-linked from the start, then it would be comparable to a Go binary of today. If Go had many dynamic dependencies and people became "stuck" with them, and Go later introduced statically-linked binaries, then it would be the same as your C/C++ example, wouldn't it? In other words, it's not a distinguishing factor because you can be fully statically-linked in C/C++ if starting today with a new project with that goal in mind.
    - 37ef_ced3 5y ago
      Sure. But here we have a typical situation where the Go tools get it right by default, and of course a sophisticated engineer can achieve the same effect with non-Go tools even though those tools get it wrong by default
- deleted 5y ago
  [deleted]
jsjsbdkj 5y ago
Go is mostly very good, but the module ecosystem continues to be a nightmare, and having a deep dependency graph can make build times brutal. I work on a project which depends on k8s, which means a cold build take several minutes. Not to mention trying to update dependencies and figure out what versions are actually being built into the final binary.
- 37ef_ced3 5y ago
  Anyone who works on large C++ projects will laugh at your "several minutes" comment. You may not realize how bad things are on the other side of the fence
  - pjmlp 5y ago
    Only if they insist in compiling the world from scratch, though. On the world of DLLs and COM, those compile times are relatively ok.
  - anthk 5y ago
    ccache
  - fpoling 5y ago
    Yep, without a build farm it takes 6-7 hours to do a full Chromium build...
- beforeolives 5y ago
  Who is doing dependencies right in your opinion? Because it feels like it's a complaint I hear about every language.
  - coolreader18 5y ago
    Might be biased/stereotypical, but Rust's cargo does dependencies really well. It's as easy as npm to add new dependencies, but there aren't thousands needed to do anything, and if you take a look at your Cargo.lock/`cargo tree` you can really get to know each of them and what they do or why they're pulled in. I'm still bloat-wary, maybe as a leftover from doing webdev, but with less transitive dependencies in the first place you can actually go through and prune things that aren't needed, or open PRs to transitive deps to prune from their trees or update deps to the latest version to deduplicate your tree. (If there are multiple semver-incompatible versions in a dep tree, they just both get compiled in - for most apps though, you should be able to get the number of duplicates to 0 or almost that.)
rejectedandsad 5y ago
Calling out again, this is a fantastic program and it's remarkable that this is released pseudonymously (for whatever reason)
- 37ef_ced3 5y ago
  Thanks man
bitcharmer 5y ago
For me the major remaining issue is a golang ide, or lack thereof. You only have 3 options: - Goland from Jetbrains; awesome but costly - Vscode with golang plugin; slow, brittle, little functionality -vim; yuck It'd help adoption greatly if there was a decent free option here.
- ulzeraj 5y ago
  I love vim. =( Its there everywhere you need it. If I have to use these other fancy pants editors I always enable vim emulation when possible but its never the same.
  - gigatexal 5y ago
    Yeah vim plus govim amazing.
- haolez 5y ago
  One of Go's creator did a lot of the initial coding in Acme[0] :D [0] https://en.wikipedia.org/wiki/Acme_(text_editor) https://en.wikipedia.org/wiki/Acme_(text_editor)
  - ainar-g 5y ago
    Something tells me that a person who reacts to Vim with a “yuck!” won't like Acme either. Also, I don't know how true this is, but I've read that Acme loses some of its advantages when it's run in e.g. X11 as opposed to its native rio[1] with plumber[2]. [1]: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system) [2]: https://9fans.github.io/plan9port/man/man4/plumber.html https://9fans.github.io/plan9port/man/man4/plumber.html
    - haolez 5y ago
      I _think_ that Rob used Acme in OSX, but I can't find this source.
libria 5y ago
Off topic: this NN-512 site has good UX for having no CSS/JS (I know, many of you would claim it's because those are omitted...). Did you use some kind of site generator?
- 37ef_ced3 5y ago
  The program generates the HTML for its own website (in DRAM) and serves that HTML over HTTPS. When you access that webpage, you are communicating with an NN-512 process that is running on a $5/month Linode cloud instance
  - libria 5y ago
    Ok ok I see it in e.g., https://nn-512.com/browse/NN-512#64 https://nn-512.com/browse/NN-512#64. The anchor tags for the listings go to top instead of being self-referencing. Is that a bug? Like format = `<h3 id="%d"><a href="#0">%s</a></h3>` + Should be format = `<h3 id="%d"><a href="#%d">%s</a></h3>` + And Fprintf should duplicate a parameter?
    - 37ef_ced3 5y ago
      No, that's intended. There's an index at the top of each page. You use the index links to jump down. And if you want to jump back up to the index, you use any of the header links. That makes sense to me. It seems useless for a link to point to itself
      - libria 5y ago
        > It seems useless for a link to point to itself Hm. I guess the web has programmed me differently. Say I'm CTRL-F searching through the page and I notice an interesting bit of code and say "Hey I have a question about this". Then I start looking for a shortcut to that one file and assume that shortcut is the nearby <h3> header. I expect this because I've seen this pattern implemented a lot. You could have the <h3> be that local anchor and a short [top] link next to it.

tschellenbach 5y ago

Work I need to do to use 1.17: None Benefits: Improved performance and reduced hosting costs Go is so nice for getting stuff done.

svnpenn 5y ago

Random Go fact I learned recently: by default, HTTP requests automatically redirect. If you dont want that, you can do this instead: res, err := new(http.Transport).RoundTrip(req)

mixedCase 5y ago
Another fun one, in the masochistic sense, is that the default HTTP client has no timeout, and you can't forget to set it yourself if you don't want to potentially leak connections.
- Groxx 5y ago
  The stdlib http client is a bit absurd in some areas, yeah. Timeouts in particular are so confusing and misleading that there are quite a few lengthy blog posts about them alone, e.g. https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... Granted, part of it is that it's too complex to be captured by one timeout, but everyone wants one timeout. kinda like string-sub-slicing and UTF-8 multi-byte characters - it's a Bad Idea™ because the over-simplified stuff is fundamentally wrong and will often cause problems. E.g. I routinely encounter tools with short timeouts that don't work on slow network connections (e.g. Bazel), despite actively downloading - what you generally want for user-use is a timeout that ensures the download does not hang forever doing nothing, not the download completes within a specific amount of time. ... but also it's just abnormally bad.
  - shabbyrobe 5y ago
    There are fragments of discussion about the download timeout throughout the issue tracker, which end up leading back to this still-open but seemingly forgotten issue about adding InactivityTimeout: https://github.com/golang/go/issues/22982 https://github.com/golang/go/issues/22982 I'd love to see this one addressed but it's not looking too hopeful at this stage.
- Philip-J-Fry 5y ago
  No one in their right mind should be using the default HTTP client or server. They only exist to allow you to quick hack something together. For any serious application you should always define your own.

ru552 5y ago

Added a new testing flag -shuffle which controls the execution order of tests and benchmarks. That's a fun one

EFruit 5y ago

As someone who's been using Go for a long while now, I can't help but wonder if modules and other recent changes aren't a step backwards. Maybe I'm a change-averse geezer, but modules still seem like an overcomplicated solution for a solved problem. Needed a particular version of something? Great. It happens. Add a submodule and toss it in vendor/. Why in God's name do we need to proxy source code through Google-hosted services which they've been reluctant to even open source? And at the root of it all, the GOPATH model simply wasn't bad enough to be worth replacing! You have the full source repo right there, in a predictable, semantically-useful location. When you `go get` something, use `-u`. If a package fails to work with the current upstream, vendor an old version, _or update the depending package_! Ideally, I'd only ever have one copy of source code anywhere on my computer, preferably in the form of revisions in a source repo. Contrary to popular belief, disk space and bandwidth are neither free, nor infinite, and I'd like to make good use of mine. NPM and `node_modules` are NOT designs to aspire to! If the Go tooling insists on involving itself with versioning, dependencies, and source control, it should actually USE the source control tools to manage versioning and dependencies! It isn't rocket science to make a temp directory, clone from the local repo, check out a tag, and use that for building. Git even has facilities to check out the tree at a specific commit, no full clone required. (Granted, my view is Git-centric, but I believe that mercurial and svn also allow you to clone and check out labelled versions, especially considering those are _the basic requirements_ of an SCM.) And why do we need to verify cryptographic integrity of downloaded code bundles when the SCMs typically use cryptographic primitives to describe versions? Then to mandate a gatekeeping "sum database" on top of all that? Finally, it is depressing to me how shut-in and closed-off the core team seems. The designs for big language changes are rarely ever proposed by the community, only by people already in the team. While (I hope) the community's input helps inform their decisions, the final module design was rsc's. Before he drafted the design document, dep versioning was a user-space/community problem, but after it came from him, then—and only then—was dependency version management truly considered for the toolchain. The generics design came from, and was accepted by the core team. Rob Pike's recent d̶e̶̶c̶̶i̶̶s̶̶i̶̶o̶̶n̶ proposal to support taking the addresses of simple types is—as one might expect—unquestionably going to be added. The greatest thing that could happen to Go would be a community-organized and -centric fork, like Gitea was to Gogs. Even if they didn't maintain strict compatibility with each other, I know which one I'd use.

kubb 5y ago

I've been using go for years now at my work, and I have to say that it does have applications where it's a perfectly capable tool. The problems arise when you try to do something it's not good at and you start wrangling with the language. If your coworkers have strong opinions on how Go is supposed to be used, it can make matters worse. My biggest qualm by far is the limited type system, e.g. it has no concept of immutability or non-null pointers :( Also accomplishing simple things sometimes requires surprisingly weird techniques, e.g. cloning a slice. The lucky people can evaluate a problem and choosing the right tool for it. The unlucky bastards like me get handed a language and are expected to build everything in it. It can be rough sometimes.

exacube 5y ago
> e.g. cloning a slice. https://golang.org/pkg/builtin/#copy https://golang.org/pkg/builtin/#copy
- kubb 5y ago
  I've been using Go for years, of course I know about copy. Someone did a writeup on this which is a perfect illustration of a general theme with Go: on the surface it looks fine, but the closer you look, the stranger things get: https://github.com/go101/go101/wiki/There-is-not-a-perfect-way-to-clone-slices-in-Go https://github.com/go101/go101/wiki/There-is-not-a-perfect-w...
  - exacube 5y ago
    Apologies for my tone, I didn't mean to insinuate you weren't experienced. I guess I was wondering what was wrong with copy(), thanks for the link! IMO, copy() is well-designed and the semantics are sensible. I think the other examples in that article are not clear, and the semantics have me second guessing what they're doing. > Drawback 1: if s is nil, the result sClone is not nil. I can see how this particular semantic seems an issue, but I think its sensible. If your copy() returned nil and you wanted to use it, then you'd have to check if sClone is not nil first, so that if statement is unavoidable. Instead, it's often safer in practice to check ahead of time. Sorry again for my tone, it's easy to appear rude on the internet on a late night.

exacube 5y ago

My favorite part: Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. This work is enabled for Linux, MacOS, and Windows on the 64-bit x86 architecture... For a representative set of Go packages and programs, benchmarking has shown performance improvements of about 5%, and a typical reduction in binary size of about 2%.

nappy-doo 5y ago
Just buried in the middle of the release notes: Oh, your code's 5% faster.

karmakaze 5y ago

> Conversions from slice to array pointer: An expression s of type []T may now be converted to array pointer type *[N]T. If a is the result of such a conversion, then corresponding indices that are in range refer to the same underlying elements: &a[i] == &s[i] for 0 <= i < N. The conversion panics if len(s) is less than N. > Note that the new conversion from slice to array pointer is the first case in which a type conversion can panic at run time. Analysis tools that assume type conversions can never panic should be updated to consider this possibility. WHY! So now we can't trust that the type *[N]T won't panic at runtime when accessed by in-range index values. This should be identified as an unsafe conversion.

tapirl 5y ago
Most of such conversions are safe and should not panic (just like the type assertions).
icholy 5y ago
The panic happens during conversion before you have a chance to index into it.

jftuga 5y ago

I really enjoy writing command-line utilities to make my system admin job more efficient: https://github.com/jftuga?tab=repositories&q=&type=public&language=go&sort=stargazers https://github.com/jftuga?tab=repositories&q=&type=public&la... Any feedback is most welcome!

exacube 5y ago

It's surpring that Go 1.17 discountined support for MacOS 10.12 (or older), which released only 4 years ago. Along with deprecating Intel support, it seems like Apple, their users and the ecosystem is totally fine not giving a shit about supporting aging software. It doesn't seem like anyone cares that much either. Even more impressive that on average, Macbooks have a much longer lifespan than other laptops, while the software they run is intolerant of old versions.