Hacker News Reader

> 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.

Rob Pike explains the reasons behind Go's deceleration syntax in this blog post: https://blog.golang.org/gos-declaration-syntax

Wow, this is really mind-opening. Everything makes sense now. Thank you.

It's also funny, that they stuck to the * pointer notation which led to the problem, where they could not tell apart a pointer from a multiplication, so they put it to the left of the variable name. It's the small things...

But I guess * is just too convenient and ingrained.

> 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"

I know. The question is, why does it need a colon? It seems completely superfluous, from a syntax perspective.

I think the point is to make sure you know what you are doing. That declaring a new variable should always be an intentional act, and this makes assignments to typoed variable names error rather than just creating a new variable.

It catches some coding errors due to mispelling. Did you mispell an existing variable or wanted to declare a new one.

it's not. Go has block-level scoping. = means "assign the existing identifier to this value". := means "create a new identifier".

https://play.golang.org/p/Irqxm0okfkt

Thanks for the example. In all my life I never actually wanted to do something like this, but well... It's neat that go allows this.

You will if you ever do concurrency stuff in go. The way goroutines capture their working variables in a closure make things like `x := x` useful and clear (once you know why you do it in the first place )

that's likely not true. Every time you do this:

    if err := fn(); err != nil {
    }
    // the result of fn does not affect the identifier err
    // in the enclosing scope

you're scoping err just to that if block. that's ... just about the most common phrase in all of Go. it won't affect any err defined prior and it won't exist outside of the if block.

You'd have to do this to make the value stick around or affect the enclosing block:

    var err error
    if err = fn(); err != nil {
    }
    // err has the result of fn here

It's to avoid typos. Imagine there is no colon. When you type

    foo = 3
    fooo = foo + 1

Did you mean to create a new variable called `fooo` or was it a typo? Did you mean this:

    foo := 3
    fooo = foo + 1 // oops, typo found at compile-time

or that:

    foo := 3
    fooo := foo + 1 // Yep, new var, everything is ok

Why not just have

var foo = 1

That works actually.

The weirdness is that ":=" allows redeclaration (within a scope) but only partial, whereas `var` completely forbids redeclaration.

That is:

    var a, b = f()
    var a, b = f() // NO

    var a, b = f()
    a, b := f() // NO

    
    // note that the second declaration only partially overlaps with the first
    var a, b = f()
    var a, c = f() // NO

    var a, b = f()
    a, c := f() // yes

I am trying to help a Windows-using team ramp-up on Go dev, and it's pretty rough.

Currently my advice to them is ditch VS Code and download GoLand, the editor change is jarring but the experience is much more fluid on Windows overall. Also transparent support for modules, per project.

For compiling when your code (or a package you're using, e.g. sqlite) has a cgo dependency - afaik YES you will need to go down the dark road of cygwin/Mingw, if you want your development cycle to be at all normal... and even then, my observation is compilation times are an order of magnitude slower on Windows :(

At GopherCon I met folks who worked for huge, "old guard" Windows companies who said "just run a linux VM" to develop in Go.

If you just need to compile for windows once and a while (e.g. for releases only, not as part of your normal dev cycle), check out xgo [1], which uses docker to deal with all the cgo mess. No cygwin/Mingw to install/worry about.

Best of luck! If anyone else has tips for working in Windows, I'd also love to hear them.

[1] https://github.com/karalabe/xgo

Personal recommendation, if you need to stay on windows and don't want GoLand - set it up to use wsl 'remotely' [0]. All the offline ability of a local environment, but with the software compatibility (and ecosystem) of linux. (That being said, GoLand has been great on both Windows and Mac for me - the only thing VSCode does that GoLand doesn't is remote dev, and that's supposedly coming soon™ [1])

0: https://code.visualstudio.com/docs/remote/wsl

1: https://blog.jetbrains.com/go/2019/08/15/2019-3-roadmap/

Thanks for your feedback. GoLand looks really nice (like everything from JetBrains), but the price is a bit steep for just playing around once in a while. But I'll keep it in mind.

I'll try the WSL Route and see how it goes. (VSCode already made me install that extension.)

> - 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.

It's really C and languages directly derived from it which are the odd ones out. "postfix type" ordering dates back to at least Pascal, and is very common especially but not solely amongst languages with type inference.

Just look at what more direct C derivatives have to do to back-fill type inference: invent some weird-ass pseudo-type to take the type's place. I also think it maps better to how I read / write / think. "f is an integer", the definition of f is more relevant than its type.

> - I can parse 2GB of simple JSON files in less than 20s. I'm awed.

100MB/s doesn't seem that impressive? rapidjson or serde can do several times that, simdjson reaches 2GB/s.

> - 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..

Without the : it means every assignment might be a declaration so you need a "declaration inference" system, and every language which does declaration inference has odd tradeoffs and corner cases e.g. implicit declaration in the local-most scope (Python), implicit method-wise non-local (ruby), implicit global (javascript), …

Explicit declaration is a very good decision I think. As far as I'm concerned it's one of Python's big annoyances (and javascript but there it's easy to lint away as you also have explicit declarations, you can just ban implicit ones).

Your explanation makes sense. It would complicate the compiler in this regard.

It's funny, how many different answers I got. I guess, all those reasons combined justify :=

- Complicates compiler

- Prevents Typos

- Works well with err (also because of partial declarations)

- Variables can be shadowed inside a closure

> Your explanation makes sense. It would complicate the compiler in this regard.

The compiler part's easy, it's the meatpiler which gets into an odd funk when implicit declarations don't do the expected thing (which will eventually happen). Not having implicit declarations is much simpler and more straightforward for everyone involved.

I used to find implicit declarations NBD, but I've slowly soured on them (starting with CoffeeScript: I found its declaration inference decisions absolutely awful and that started me really thinking about implicit declarations, see http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffe... for more on the subject, or https://donatstudios.com/CoffeeScript-Madness for a more brutal take).

> - 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..

With ":=" will declare with implicit type and then assign. The type will be that of the right hand side.

> 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 remember Rob Pike ever said that one if the reasons of needing := is to avoid declaring many error variables in a function, such as err0, err1, err2, ..., and at the same time we don't need declare then as uninitialized variables.

With :=, they can be all called "err".

Personally, I do prefer to try to avoid using :=.

> 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.

Yeah, there are a lot of reasons for this. Things used to be easy when it was just GOPATH, but that didn't support every use case, so modules were added. Now the advice beginners get is fragmented and confusing to navigate. Also, the error messages for modules are terrible. These are tractable problems, but it's definitely a rough time to be a beginner (which is unfortunate because Go is otherwise very beginner-friendly).

VS Code is a different product altogether and its Go integration is pretty buggy in my experience, especially its handling of modules. Go really needs a bullet-proof (free) editor story. If you want a premium IDE (a la Visual Studio), I've heard good things about Goland.

> 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.

The scoping rules are pretty straightforward and standard. I'm guessing "shadowing" is tripping you up. Error handling is verbose, but this is a good thing IMO; it's really clear what is happening and there is no special control flow for certain data that is arbitrarily classified as an error. The real issues with errors are the lack of stack traces and other standard structures for programmatically inspecting / manipulating errors. Some of these issues are being addressed in go1.13 but it will take a while for the best practices to be established and propagated through the community.

> 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.

I think it will be. You're entering at a time when there's some churn in the best practices and it makes for a confusing time to be a newbie. Hang in there!

Thank you for your elaborate perspective. I initially thought that I'm just dumb, but I guess there are really alot of new things coming around lately, so I'm ok with some minor problems.

Really hope to use GO more and that those rough edges will be gone after a while.