Hacker News Reader

Comment by Waterluvian | Hacker News Reader

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go.

There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven't felt so viscerally aggressive about software like that whole experience made me feel in a long time.

I hope Go2 makes something concrete from the start and sticks with it, for better or worse.

View on HN

Having used the new Go module system (introduced in Go 1.11 as an option, to be the default choice in 1.12) since August, it's my opinion that this is now a solved problem.

The biggest source of pain moving forward is going to be the projects that haven't transitioned, including the various command-line tools that work on parsing, generating and manipulating Go code (e.g. linters, code generators). Most of the important ones are already there, and I've transitioned several myself.

As an added bonus, word is that the Go team wants an official package repository system (similar to Cargo, RubyGems etc.). I wouldn't be surprised if this happens rather quickly.

> it's my opinion that this is now a solved problem.

It's starting to look like a viable solution, but it's not even close to actually solved yet. Why does `go mod why <module` make changes to your module? How do you run go get to install a remote package when modules are enabled (without explicitly running `GO11MODULE=off go get`)? Why isn't the module cache concurrency safe? Why does the module cache sometimes mysteriously cause compile errors until you `go clean -modcache`? There are so many little bugs and oddities.

And as you mentioned, a lot of things have side effects now that didn't use to, which has catastrophically broken a lot of the tooling surrounding the language. Autocomplete using gocode used to be nearly instant. Now it sometimes triggers downloads and takes 30+ seconds.

I'm hopeful that go 1.12 will be the first release where this problem is really solved.

There are bugs, but I was referring to the design of the whole thing.

By the way, your "go get" bug was fixed today [1], if I understand your complaint correctly: With the new modules turned on, you could no longer do "go get" globally.

(I would agree that it's a little weird that "go get" outside a module installs it globally, while inside a module it installs it locally; that's going to trip up scripts and Dockerfiles, and it should really be two separate commands. "go mod add" to add a new dependency, for example.)

[1] https://github.com/golang/go/issues/24250#event-1996119923

There are still some rough edges, but I agree that the new module system is very good. And it's given me the confidence in Go to start using it far more broadly than I had before, when every new project meant hang-wringing over how to handle dependencies. Now it Just Works well enough for 90+% of use cases, with no extra steps required. It just works.

I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at least, it has, so far, for me. Cargo is that answer for packages and for building, and it's pretty good, and there's no debate about how to install or build Rust tools and libraries.

I didn't really find that to be the case with Go, so even though Go is a simpler language, I have been more productive, much more quickly, in Rust. Within a couple of hours of starting my project (with only a cursory glance over the docs and tutorial) I had my project daemonized, had options parsing working, had system calls working, got logging working, etc. It was shocking how quickly I was up and running.

I'd been hesitant to try Rust, because it looks big, and I'm kinda tired of big languages. I just don't have enough time/motivation to study a bunch of nuanced syntax and such; I'll never be a great C++ programmer, though I can muddle through and usually understand other people's C++ code. But, so far, Rust is proving to be one of the easier languages I've learned lately, partly due to the holy path being well-defined, and partly due to strong libraries that overlap my particular project perfectly (being a systems language built by very smart people, it has some very good systems libraries).

I don't mean to imply Go is a hard language, it's not. I picked it up pretty quickly, too. Both are easier to learn than, say, JavaScript, because they're much smaller. But, I agree that there isn't a super clear path forward for a beginner with Go, including with installing and building. You just have to acquire more tribal knowledge to work in Go than in some other languages (but, much less than many others...older languages tend to have tons of that kind of thing).

Rust explicitly set out to have an excellent built-in package management solution. They tapped Yehuda Katz early on for this.

> They tapped Yehuda Katz early on for this.

After trying three or four times to build one on their own that is!

As a beginner, I really like rust.

It has excellent package management, robust compiler messages, pattern matching... etc. But once I start trying to build non trivial data structures it becomes a nightmare. For example, doubly linked list, any sort of graph is extremely hard for me to build in rust but extremely easy to build in golang.

I am still learning the full capability of rust, hopefully as I do more practice it gets easier. In the worst case I think I would still use it to build data pipelines since I really enjoyed the syntax and the safety check as long as I don't get into smart pointers or raw pointers.

Also another annoying point is that some libraries use nightly.

You're not the only one having trouble writing basic data structures in safe Rust: [1]

[1] https://rcoh.me/posts/rust-linked-list-basically-impossible/

Of course, if you're comparing with Go, you need to compare apples to apples - since Go doesn't have ownership tracking, the equivalent Rust would necessarily have to be unsafe.

Yeah but Go has garbage collection. Rust's ownership model makes up for not having GC.

I think that heap-allocating everything and using Rc<T> and Weak<T> would be a closer comparison to what Go does, than using idiomatic Rust with borrow-checked locals etc.

I have to ask why you're not using a data structure from a library, though.

I have heard this is a really good resource for understanding this exact aspect of Rust

http://cglab.ca/~abeinges/blah/too-many-lists/book/

Rust easier to learn than JS lol... In Rust you have issues that will or will not overcome easily, nothing like that happen in Go. And seriously getting starting in Go takes less than an hour:

- Install Go

- Install VSCode + Go plugin

- Start working

I explicitly said above that Go is an easy language to learn. But, I found Rust easier.

And, yes, I'm finding Rust easier to learn than JavaScript. Without question. It is a much, much, smaller and more cohesive language. It has some new concepts (features or techniques that I have never used in any other language), but so does modern JavaScript, and with JavaScript there's usually five ways to do it, and half of them are really poorly thought out. I don't dislike JavaScript. I'm not saying one shouldn't learn some; one definitely should. But, it's definitely going to be "some", for most people, because there's just too much of it to learn it all, unless you can devote yourself full-time to being a JavaScript expert. I aint got time for that.

As I mentioned, I've built a (toy) project in Go. I've spent more time with it than Rust at this point. I know how it works, and what getting started looks like. And, though Go was pretty easy with few pain points, I've found Rust to be easier and to provide a more clear path for a beginner to follow, so far.

Everyone is different, and we're all coming from different places. No one has exactly the same set of starting conditions for learning a new language as I do. For some, Go may be easier than Rust (I expected it would be, which is why I started with Go and avoided Rust for so long). For me, I am finding Rust easier. I haven't done much with it, but I was surprisingly productive surprisingly fast.

I for one totally agree on rust being easier to learn than Javascript. I suspect it is because of the explicitness of rust vs the flexibility of javascript where you can do literally anything you wish without any sort of guard rails, then there's the ecosytem with like a gazillion tools in your build pipeline. I really admire front end devs because they do what I cannot, I guess i'm not as clever a programmer, I need the compiler to hold my hand , lead the way, and yell at me when I am going astray, rust does that for me , and when I'm done obiding by the rules, cargo is there to take over the rest of the process.

I don't really care about the guard rails. I grew up in Perl (pre-strictures and warnings), and BASIC was the first language I ever built something in, so I'm not too fussed about things always feeling a bit loose, and having to defend yourself with tests and imposing some rules on yourself by convention.

While I think it's likely that having a stricter language is more likely to produce better software, especially as complexity grows, I don't think it has a huge impact on whether the language is "easy to learn" for me. Python is very lax (contrary to popular belief, Perl with strict/warnings is stricter than Python, and protects you against a wide variety of scope-related bugs, in particular) but I consider it an easy language, too, because it is consistent and small(ish). There's some kind of balance to be struck between elegance and simplicity, and between explicitness and concision, and Rust feels very good, so far. I don't think that balance will be the same for everyone.

JavaScript, to me, is hard just because it's so damned big and incoherent. It's been pulled in twelve directions at once for its entire life, and it shows. JavaScript is like a buffet that has Chinese food, Indian food, pizza, sushi, and tacos. Most of the food isn't very good, but there's a lot to choose from. It doesn't help that learning JavaScript also entails trying to make sense of the maelstrom of tooling that's available. While Rust has one clear path for beginners, JavaScript has a haunted corn maze.

Coincidentally, here's Rust's getting started workflow:

- Install Rust

- Install VSCode + Rust plugin

- Start working

Coincidentally, here's JavaScript's getting started workflow:

- Command + Option + J (on Mac+Chrome)

- Start writing JavaScript

For an apples-to-apples comparison, you would have to compare this to https://play.rust-lang.org and https://play.golang.org

My only experience with Go was around 2012-2013. It was fun, but I did not bother sticking with it. The forced directory structure was a little bit annoying and I found myself writing interfaces for everything. I'm sure people will say it's my fault as a programmer, but it turned me off from the language.

The new module system removes $GOPATH and the forced directory structure.

Go modules are available in go 1.11 today. If you're envisioning another new pkg management solution besides that, I don't think that's going to happen.

The fact that it didn't have an official package manager from day 1 is a big issue to me. All other new languages have an officiel package manager - elixir, rust, ... https://github.com/golang/go/wiki/PackageManagementTools

go1.11 pretty much solved this, though there are still many dependency managers out there and projects which rely on them that should be upgraded to support the New Way.

"package" in Go has always referred to a folder. Or in other words, a shared namespace for every entity exported by every file in that folder. "module" refers to a package which has a go.mod file in it; that module package + all of its children become versioned via that go.mod file and are distributed as one unit.

It operates identically to npm; npm packages are folders, and there's a special package with a package.json which versions that folder and all of its children. Then, that "package.json package" is what is distributed.

It's ironic from a language that invented gofmt...

I'm curious what language you come from that has much better package management than Go. I'm guessing not JavaScript, or C++, or Java, or Python, or...

Reply on news.ycombinator.com