Hacker News Reader

Comment by asien | Hacker News Reader

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.

Haven’t tried it since.

Hope lots of this change to make the language more welcoming for Newcomers to the language.

View on HN

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).

Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project.

[1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"

That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.

That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project.

Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.

> there's an experimental feature

That's not a feature but a fix for a design problem, and currently the only fix is an experimental one.

For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

> they're as un-risky as anything labelled "experimental" could be.

Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

A ton of projects have upgraded to work well with modules already. Seriously, it's set and forget in your zshrc / bashrc / whathaveyou.

> Seriously, it's set and forget

If that was true they would not be euphemistically labelled as experimental.

I don't understand what you mean, sorry

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

> a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

The Go devs have been extremely clear that Go modules is THE solution to Go packages.

If they do mean what they say then they will release a version of Go where the GOPAH nonsense is over and a fix for that design problem is not euphemistically described as experimental.

Until then, no LTS means not ready for production.

GOPATH is still being used internally by Go modules, but it's set up automatically and you never have to even know it's there. It will probably remain an option to use it as a user for a while due to backward compatibility.

I don't see how that prevents you from using Go modules.

> a fix for that design problem is not euphemistically described as experimental

The simple reason for it being "experimental" is because Go 1.11 is the first release to include it, not because of some inherent instability. Wait till February for Go 1.12 if you're so worried.

> no LTS means not ready for production

I don't know what you mean by LTS here, since every Go release as of 1.0 has been backwards compatible.

Learning Go modules is a minimal investment. It is rather hours than days.

Its not like there is much of a barrier there.

For some people and organizations "as un-risky as anything labelled "experimental" could be" is risky enough to be automatically being disqualified from even being considered. There's the label 'experimental', so it can't be used anywhere touching the production codebase regardless of any other arguments.

Experimental and production are two words that should be used together.

Same here. I've been using them in production with no issues.

"All that is excessive is insignificant.", said Talleyrand.

By your standards c and c++ are not professional tools.

Not the OP, but uh, no neither of those are "professional" in the sense that professional should use them, regardless of the plain fact that "professionals" do use them.

Those are both garbage languages, despite their utility.

I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?

> should we only use languages that were perfectly designed to start?

If there are a myriad of languages and we do have limited time to invest mastering a language, we better use our time wisely and not waste it with those with severe design problems and designers who have refused to face those issues for years.

Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."

It's a bit Pascale-y, which may be a turn off to some.

I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?

Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++.

Haskell, I feel, needs no explanation.

Rust syntax being busy is something I've heard, but people point to things like lifetime annotations, which sort of make Rust what it is so...

Also, lifetime annotations are not required on the overwhelming majority of functions. If you have, say,

  fn substr(text: &str, start: usize, length: usize) -> &str;

the compiler will infer automatically that the return value inherits the lifetime of the `text` argument. I don't find that line up there particularly busy.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.

My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

Not saying that features like byebug have no use at all, of course.

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

You know well that it is. Add /s or /rhetoric to your question next time :)

Languages can be pretty useful even if they are imperfect, as others have said. And Go is plenty useful. The Stroustrup quote about C++ comes to mind ...

Here you go:

https://en.wikiquote.org/wiki/Bjarne_Stroustrup

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

And here's a good set of Q&A from his FAQ; it includes the above quote too:

"Did you really say that?":

http://www.stroustrup.com/bs_faq.html#really-say-that

Everyone's aware of the lack of generics, it's been rehashed to death. This is a discussion on Go 2, which will add them.

The current type system is poor, but still better than dynamic languages.

> which will add them.

"Generics" can be a lot of things in a lot of ways. AFAIK there is no official Go design for generics, or a list of the deficiencies they will have, so a blanket "this particular problem will of course be solved well" is speculative.

Elixir's IEx.pry/0 function, that opens a REPL at a particular point of execution, is probably the stdlib function I call the most while developing. In a compiled language, to boot.

Wow, that's cool. Wonder how it works. Does it spawn an instance of the REPL with your app and its current state?

>This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

>Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

I definitely liked the type system of Go and the compile time errors it found. It gives you a lot of peace of mind and reduces some errors. However, those errors aren't the things I use byebug for. Byebug is for things like figuring out why your code went down Path A when you expected it to go down Path B. Or if you don't know how to do something it's a sandbox to try a few different things until you get the output you were looking for.

>Byebug is for things like figuring out why your code went down Path A when you expected it to go down Path B.

Got you now. The classic use case(s) of an REPL. I may have misunderstood your earlier comment, which is why in my own earlier on, I had said "seems".

Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases.

Compilation is not a magic bullet. Although, to be fair, I pushed Golang at work precisely because you have to compile it first. Not everyone is diligently testing their code...

>Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases.

True about the semantic and testcases parts. Not clear how it helps with architecture.

There's gomacro, which is a Go REPL with debugging:

https://github.com/cosmos72/gomacro

It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack: even Java now provides one (JShell).

>There's gomacro, which is a Go REPL with debugging: https://github.com/cosmos72/gomacro

Will check it out, thanks. Had just been thinking whether there is any Go interpreter some time ago. I remember C having at least one, back in the day.

>It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack

Agreed. And it should be more like IPython (command-line version) than like the stock Python shell.

>even Java now provides one (JShell).

Good to know.

I think the closet Go equivalent of 'byebug' would be delve[0].

It's got more of a learning curve than a REPL, but very powerful. Editor plugins for Go also tend to have good convenience support for delve, making using it less painful. For example, vim-go[1].

[0]: https://github.com/derekparker/delve/blob/master/Documentati...

[1]: https://github.com/fatih/vim-go/blob/master/doc/vim-go.txt#L...

> For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

Isn't that what a normal debugger does? Or am I simply just living in lala-land because of C#.NET/Visual Studios terrific debugging experience?

I remember php and the hell that was xdebug. It was much easier and more efficient to simply to a `var_dump` whenever you needed to debug.

You might like Rust. It has a much better story in these areas.

Weird syntax? I’m sorry this doesn’t look like your favorite language.

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo.

I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

> direct usage of syscalls instead of libc

But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?

No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.

Same for me. I moved all my code into the GOPATH pattern after finding that I had 3 separate clones of the Linux kernel in separate places. (And not just for development, just for reading and grepping.) I made myself a helper tool for navigating the GOPATH:

  $ cg gh:torvalds/linux # cg = cd to git repo
  $ pwd
  .../src/github.com/torvalds/linux

The code is at https://github.com/majewsky/gofu#rtree if anyone's interested.

> direct usage of syscalls instead of libc

Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?

It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard.

MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries:

https://github.com/golang/go/issues/16570

Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue.

On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.

> It is very common for language runtimes to link and depend on libc on Unix

It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it.

> MacOS doesn't guarantee backward compatibility for direct syscalls.

Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it.

But if we're talking about Linux libc, there's no reason for Go to use it.

> POSIX is defined in terms of a C standard library

Specifically POSIX.1 (not POSIX.2).

Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.

It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.

On glibc-based Linux you generally need to compile on a system running the oldest (or close to) version of glibc you want to support. I suspect this was the singlehanded reason for Go being built that way.

That said, on macOS it makes a lot less sense because libSystem's compatibility guarantees work a lot like those of Win32, where you can safely compile on newer versions of the OS as long as you don't actually use features that are newer than your deployment target.

Windows syscalls are exposed via User32.dll, Kernel32.dll and friends, not MSVCRT.dll.

Actually, the issues you mention are already fixed by Go modules.

EDIT: Removed a parenthetical that was based on a misreading of the parent.

I believe they’re saying that vendor support is a good thing in Golang.

Thanks; I definitely misread. I deleted the relevant bit from my post.

No oxford comma:

the performance, the community around it, and vendors support

FWIW GOPATH has not been required since 1.8. It now defaults to $HOME/go if not set.

Go is pretty easy to get up and running in Windows. There's an installer for the compiler and you can install vscode and the Go extension pretty quickly.

Windows is an afterthought for most programming languages (ever try ruby or c++?) and Go's cross-platform capabilities were a breath of fresh air.

I agree with the package management system and $GOPATH. I would add that is awkward that most of the libraries are not thread safe when go routines are core to the language.

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain.

Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho.

But call me crazy when I say that I like C++ and can read it effortlessly :)

Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt).

It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.

I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.

Yeah I completely agree. Though I think when you really get used to a language and understand it deeper, you tend to understand the trade-offs that were made, if the language is well designed. Then you can still think that the trade-off don't match your requirements.

"you'll get used to it" is a bad measure of usability.

But so is "I am already used to it," and so how do you find an objective, non-biased, measure of what is usable?

C++ is definitely something to behold in terms of syntax. It's hard to justify much of the type-system syntax (meta-templates, `sizeof...(Args)`, and `std::forward<Args>(args)...` come to mind). I'm picking on argument-packs here and ignoring the beauty of initializer-lists, operator-overloading and user-defined literals (which allow great syntax in user-code but their own syntax is haunting in library-code). I doubt that C++ would look the same if the syntax were created from scratch with the current set of features.

So it's fair to say Go's syntax is unfortunately limited in expressiveness (and I too find myself mystified by how to express ideas neatly with go), but I have a hard time imagining C++ is something worth emulating without adding a whole bunch of subjective caveats to what "should" be avoided.

If you like c++ then you just haven't given Go enough time to sink in.

It reads more left to right then right left like c++.

I've given go plenty of time to sink in, and I still prefer c++. Things like not allowing implicit type conversions on things that clearly are not a problem (int16->int32) are just annoying.

Call me crazy but deep inside I'm a toaster.

Reply on news.ycombinator.com