Go 1.14 | Hacker News Reader

Go 1.14

blog.golang.org

84 pointstoothrot24 comments

dupe of https://news.ycombinator.com/item?id=22416067 ?

A rather nice ~10% speed boost for my tool scc from this just with a simple recompile against some input sets.

    $ hyperfine 'scc' './scc'
    Benchmark #1: scc
      Time (mean ± σ):      43.5 ms ±   1.7 ms    [User: 30.4 ms, System: 88.2 ms]
      Range (min … max):    40.5 ms …  48.9 ms

    Benchmark #2: ./scc
      Time (mean ± σ):      39.6 ms ±   1.3 ms    [User: 46.1 ms, System: 89.7 ms]
      Range (min … max):    35.9 ms …  42.5 ms

    Summary
      './scc' ran
        1.10 ± 0.06 times faster than 'scc'

Trying it on various other inputs it seems to be somewhere between 3% and 10%

I am surprised they are still getting these sort of gains to be honest. From memory 1.13 for the same workload came with a ~3% improvement over 1.12. This is purely in terms of wall clock time to run the same code over the same inputs. Have not had a look at the impact of a long running process or memory yet.

Thanks to the Go team for the great work!

The more I use it, the more I enjoy Go. Having grown up with the healthy dose of Pascal and later Modula 2, I appreciate many traits of Go which let me just focus on the tasks at hand. With very little "magic" going on, some parts of the code might be a bit tedious, but you also always have the feeling of being in control, as everything is very explicit. Add to that a few underapreciated dynamic features. I am first of all a professional Lisp/Scheme programmer and a lot of Scheme concepts translate surprisingly well into Go due to having first class functions and a garbage collector.

It is very nice to see how the Go releases are very careful to add new features while continuosly improve on the "quality" side. Enhancing the performance of "defer" is a great example. Like unwind-protect in Lisp, it is a very elegant way to ensure that cleanup code is run under any circumstance. Removing its overhead is a big thing.

I love Go. It’s too bad that go modules broke ide support and godocs. I miss the simplicity of gopath.

Edit:

Go modules were not welcomed and godep was supposed to be the official dep manager: https://twitter.com/_rsc/status/1022588289461743617

Godoc is broken because of it and Rob Pike doesn't like it: https://github.com/golang/go/issues/26827#issuecomment-51584...

VScode with gomodules is still bad even with gopls restarting every 20m: https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...

it made it painful for a while, but GoLand and VSCode both support modules at this point (though VSCode uses the gopls[1] (language server), that I've been having mixed results with).

[1] https://github.com/golang/tools/tree/master/gopls

I can't speak for GoLand but VSCode is totally borked. It is improving but we regressed a ton after Go modules were released.

Hello,

I'm new to go (and so far enjoying it). I haven't use modules yet. How do they break IDE support ? (using Goland here)

It doesn't. You just need to configure goland properly

I haven't used Goland but vscode is broken.

I constantly see this sentiment and don't get it. It's perfectly fine in GoLand, and has been for the year I've been using it. What's broken for you?

VScode:

* Function renames * Function references across packages * imports on save

Some of this can be fixed by restarting gopls (experimental) ever 20m: https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...

Are you using an old version of gopls?

From the v0.3.0 release notes[1]:

Workspace-scoped references, rename, and go to implementation. These features use your workspace root as the search scope, so behavior will vary based on the directory you open in your editor

[1] https://github.com/golang/go/issues/33030#issuecomment-51015...

Yup, v0.3.0 here (gopls version) and still broken.

If you haven't already, it sounds like it would probably be worth your time to open an issue. If things like workspace-scoped references and renaming aren't working for you when they are working for other people, perhaps you have a non-standard setting, or perhaps there is a need to adjust how you open vscode, or perhaps you are hitting bug(s). My experience has been the people working on gopls are very responsive.

VS Code is a text editor not an IDE, right? That's what its proponents always boasted in the beginning at least.

I just got work to pay for a GoLand licensed for me. The VSC experience was slower, more RAM hungry and not as full featured, so it didn't really make sense to stick with.

Lol there is nothing simple about gopath.

> Godoc is broken because of it

That was resolved a while ago. Godoc supports modules[1]:

For those who are following this issue because you are waiting for module support in the godoc command (golang.org/x/tools/cmd/godoc), please note that it has been implemented in the latest version. See issue #33655.

[1] https://github.com/golang/go/issues/26827#issuecomment-55194...

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try?

I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit"

I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right, but I haven't heard how converts from the Django/Rails world feel about the completeness of that "framework"

> ... Go standard library is fully-featured enough that it can be considered a framework in its own right...

Maybe compared to writing a server in C/C++... ORM doesn't exist in the standard library. Templating is okay. Auth doesn't exist.

People choose go to escape the world of bloated ORM tools.

SQL sprinkled with a little bit of prudent caching works pretty well in go.

I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla, and you'll probably pull in a library for auth.

For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate (or additional libraries) on top to make it work for anything beyond hello-world scale. Also you need libraries for all those secondary concerns that are usually handled on the framework level, like CSRF protection.

you might not need more advanced csrf protection than a cookie samesite policy.

Then throw a hidden input field with a CSRF token in your form and your done.

Not sure what the big deal is here.

There's revel, which is rails-inspired. And beego, and aah and buffalo. But after those I'm looking into stdlib + chi and libraries over frameworks.

Reply on news.ycombinator.com