Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keeping your Go modules compatible

blog.golang.org

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Keeping your Go modules compatible

#41

Post by anonymoushn »

poorman wrote: post #15

> When you run into a case where you want to add a method to an existing interface, you may be able to follow this strategy. Start by creating a new interface with your new method, or identify an existing interface with the new method. Next, identify the relevant functions that need to support it, type check for the second interface, and add code that uses it. I like this pattern, and I have used it. The issue I have…

It seems like this convention invites us to create this sort of issue more times: https://news.ycombinator.com/item?id=6060351

Re: Keeping your Go modules compatible

#43

Post by deathanatos »

m0th87 wrote: post #16
naringas wrote: post #12

there's something that I just don't get about golang modules, I don't know what it is but they don't click with me it might well be something tacit that golangers learn from each other directly? or otherwise it's so obvious and simple and I just haven't realized? it feels like it's the kind of thing that just clicks one day possibly after a few years

You're not alone. I've been writing go since before 1.0, and can handle modules/packages in _any other language_ fine, yet go's regularly leaves me stumped. A little while ago we were hitting yet another issue with dependencies related to version pinning at work. I tried to divine what the disparate versions mean, and came up with this flow chart from a legalistic reading of stack overflow issues [1] and the go modul…

I packaged a golang project once. I had to independently discover a lot of that.

I'll also add that fetching a golang package was complicated. As I remember, GitHub seemed to be special cased. Other URLs involved an HTTP request with a ?go-get=1 parameter, and then parsing the returned HTML for certain meta tags¹. (I thought only Python was guilty of that sin!) Some URLs I ended up just re-writing, because gopkg.in packages effectively redirect to GitHub in ways that, if abandoned, allow someone else to intercept[1].

And none of this is documented anywhere particularly coherent. Bits here and there, maybe.

(Why not use go itself? Because this platform's package manager wanted to verify that the software was being built from the correct source, by hashing the inputs. It also, then, fetched those inputs, so that there wasn't some form of bait & switch, and there is no network at build time to further prevent silliness. I considered vendoring, but it isn't clear to me how vendoring works with go modules, since it doesn't seem to take into account the module version? / the path layout only allows for a single version.)

[1]: https://github.com/go-fsnotify/fsnotify

¹some servers didn't even return the right Content-Type, either, but perhaps that's an implementation bug. But I didn't have a spec to know.

Re: Keeping your Go modules compatible

#44

Post by kitd »

apta wrote: post #39
enjoylife wrote: post #38

I use Go daily and one of the aspects which is always a challenge is equality checking. From the post, > There is one subtle way a new field can break user code unexpectedly. If all the field types in a struct are comparable—meaning values of those types can be compared with == and != and used as a map key—then the overall struct type is comparable too. In this case, adding a new field of uncomparable type will make…

Anyone who's worked on a large project and code base will appreciate the features proper mature languages like Java or C# offer. It's ironic that golang was supposedly designed for "programming in the large", but it's just a very bad experience for non-trivial code bases.

Java has an equals() method. What features are you thinking of?

Re: Keeping your Go modules compatible

#45

Post by kstenerud »

enjoylife wrote: post #38

I use Go daily and one of the aspects which is always a challenge is equality checking. From the post, > There is one subtle way a new field can break user code unexpectedly. If all the field types in a struct are comparable—meaning values of those types can be compared with == and != and used as a map key—then the overall struct type is comparable too. In this case, adding a new field of uncomparable type will make…

Testing for equality/equivalence is a huge challenge in a language like go. It's bitten me enough times (especially with recursive data) to write a library to tackle the complexity: https://github.com/kstenerud/go-equivalence

Re: Keeping your Go modules compatible

#46

Post by kstenerud »

What the go team fails to realize is that they haven't actually reduced complexity in their design of go; they've simply MOVED it. And it's been moved in unintuitive ways as they've painted themselves into corners that should have been avoidable with some careful planning.

We now have:

- magic file names

- magic directory names

- magic comments

- magic env vars

- API design requires gymnastics and juggling since recursive imports are disallowed

- A ton of useful code in the standard library remains unlayered and unexposed for no good reason (pprof, for example)

- Requiring full paths rather than relative imports complicates everything when you're fetching it from a different source location (replace directives and magic ENV vars).

- Slice implementation means that you need to do double pointer storage to keep track of the same slice from multiple places

- Creating arrays with a dynamically defined length is horribly overcomplicated

- Their policy on warnings and instead calling every little thing an error is terrible and wastes a ton of developer time.

- Lack of runtime const value support is just sloppy.

- Why do go source files even need a package declaration? It serves no useful purpose since the compiler already knows enough to spit out an error if you get it wrong.

- Refactoring across packages is nearly impossible to automate because there's no way to declare adherence to an interface.

- No importing of test code from other test code (which means that the import code in the compiler has increased complexity to enforce this silly rule).

- Stack overflows are STILL impossible to track down (after a DECADE!) because it only prints the top of the stack, which is useless in such a case.

- Linting is too opinionated and is all-or-nothing.

------------------

I could go on. I really wanted to like go, and many parts of it do actually feel nice. But even after a decade it's a huge mess. I've spent more time writing workarounds for go than for any other language in my 25 year career. Hell, I even modified the damn compiler out of frustration! [1]

[1] https://github.com/kstenerud/go#the-go-programming-language

Re: Keeping your Go modules compatible

#47

Post by pjmlp »

kitd wrote: post #44
apta wrote: post #39

Earlier quoted context omitted.

Anyone who's worked on a large project and code base will appreciate the features proper mature languages like Java or C# offer. It's ironic that golang was supposedly designed for "programming in the large", but it's just a very bad experience for non-trivial code bases.

Java has an equals() method. What features are you thinking of?

- Type safe enumerations

- Generics (lets see if flyweight design actually makes it)

- package names that don't depend on source locations

- binary packages for proper encapsulation and even faster builds

- both points together allow for components eco-system to thrive

- more knobs to turn on when performance matters

- a proper graphical debugging experience

Re: Keeping your Go modules compatible

#48

Post by kitd »

pjmlp wrote: post #47
kitd wrote: post #44

Earlier quoted context omitted.

Java has an equals() method. What features are you thinking of?

- Type safe enumerations - Generics (lets see if flyweight design actually makes it) - package names that don't depend on source locations - binary packages for proper encapsulation and even faster builds - both points together allow for components eco-system to thrive - more knobs to turn on when performance matters - a proper graphical debugging experience

I was really thinking about the problem described by GP. But in any case:

- Type safe enumerations - Generics (lets see if flyweight design actually makes it)

I'll give you both those. Generics would be the killer feature for me.

- package names that don't depend on source locations

Java package structure mirrors the file system, no?

- binary packages for proper encapsulation and even faster builds

Go package binaries are cached after build. In any case, build speed is rarely an issue for Go.

- both points together allow for components eco-system to thrive

One of the most impressive thing about Go IMO is the speed at which the ecosystem has grown and is growing.

- more knobs to turn on when performance matters

I have found it takes a lot longer to reach the need for performance knobs in Go than in Java.

- a proper graphical debugging experience

Not sure what you mean by "proper" and why it has to be graphical, but VSCode + Golang extension gives me enough insight into what's going on under the covers at debug time, equivalent to eg Eclipse + Java debugger.

Just for the record, I love Java and have been programming in it for over 20 years. It has many great features and the ecosystem is unsurpassed.

Go is a much more practical language though IMHO. The time to value is much shorter. Setting up a module project is one command. Writing & running tests, complete with coverage and performance, is supported out of the box by the basic "go" command. The standard lib is broad and deep. And as mentioned the ecosystem is growing fast.

Re: Keeping your Go modules compatible

#49

Post by entha_saava »

jacques_chester wrote: post #17
mseepgood wrote: post #6

Earlier quoted context omitted.

> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo

Go mod is a gigantic pig's breakfast. It would work OK if everyone was on it already, but everyone is not on it already. If I took a survey of every go.mod file and looked at the versions, more than half would still be that absurd, un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version string that the "insane amount of thought" landed on because it assumes everyone is a…

> The "insane amount of thought", as is the norm for the Golang team, involved a gymnastic demonstration to evade (1) any serious consideration of prior art in use whatsoever

"We never do what those Java 1xers do, because we are blue collar 0.01xers furiously copy pasting code"

Re: Keeping your Go modules compatible

#50

Post by pjmlp »

kitd wrote: post #48
pjmlp wrote: post #47

Earlier quoted context omitted.

- Type safe enumerations - Generics (lets see if flyweight design actually makes it) - package names that don't depend on source locations - binary packages for proper encapsulation and even faster builds - both points together allow for components eco-system to thrive - more knobs to turn on when performance matters - a proper graphical debugging experience

I was really thinking about the problem described by GP. But in any case: - Type safe enumerations - Generics (lets see if flyweight design actually makes it) I'll give you both those. Generics would be the killer feature for me. - package names that don't depend on source locations Java package structure mirrors the file system, no? - binary packages for proper encapsulation and even faster builds Go package binarie…

> Java package structure mirrors the file system, no?

No, it mirrors the directory structure, from import location, without any reference to DNS servers or source code repositories.

All in all Go is a Java 1.0, with all plus and minus that it entails.

Post reply on HN