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

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

231–240 of 244 posts

Re: Twelve Years of Go

#231

Post by uncomputation »

amscanne wrote: post #209
uncomputation wrote: post #187

Earlier quoted context omitted.

Go’s package and dependency system is actually the only reason I have never started using it more. The lack of true versioning, unspoken assumption of GitHub, package system, and all of the confusion between god mod, go get, go install, etc. just hurts my brain. I think Rust actually has this perfect. It’s clear. You just specify the name and version and features in the Cargo.toml file and it is pulled from crates.io…

> The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.

There is versioning through Git tags, which I don’t consider true versioning because you can always edit those tags to point somewhere else or remove them entirely. This is breaking. I suppose there is not an assumption of GitHub, but rather Git. I probably got that impression from all of the Go documentation using GitHub as an example (perhaps to seem more familiar to readers).

No, I _like_ crates.io because Rust is very explicit that that is where the packages come from. We can get into the benefits and risks and whatever about centralized vs decentralized package managers, but that’s not what I’m talking about. I just want to know how Go does what it does so that I can code confidently in it. A lot of Go packages are specified like so:

go get -u github.com/username/repo/version

But this is not enforced (you don’t have to specify a version) and this is also not a valid Git repo path and where exactly is this dependency stored and I can go on and on. When you import this package it’s usually

import “github.com/user/repo/version/module”

But then there is not always a directory in the repo and… you get the idea. This sort of stuff hurts my head and I get it that Go is maybe trying to appear simple but this black box handwavey stuff can and will burn you (this very reason is why the Go community is generally against frameworks) so I just want to have a simple, clear answer and it seems no one else in the Go world has any of these questions. This turns me off.

I’m confused by your last bit. Neither Rust nor Go have installation time execution and this is good. I was referring to how you can’t just say “Oh Node has it and this is bad but Go doesn’t and this is good” because Rust doesn’t have it either.

Re: Twelve Years of Go

#232

Post by closeparen »

morelisp wrote: post #230
closeparen wrote: post #228

Earlier quoted context omitted.

I said 15 mock expectations, not cases.

If all five of those things also need to be independently mocked, you're mocking too much and your mocks suck.

If they're not mocked it's an integration test. Integration tests are welcome as a supplement to unit tests, but unit tests are table stakes.

Re: Twelve Years of Go

#233

Post by Zababa »

jerf wrote: post #227
kaba0 wrote: post #218

Earlier quoted context omitted.

Half-telling, half-asking: isn’t type-scripts structural typing the same as Go’s, but overall much more powerful?

TypeScript hasn't risen to the level of Go. If you live in the JS world that may not be obvious, but in the general landscape it's not as prominent. A lot of people make a lot of fuss over how fast the programming world moves, but I'm a bit of a contrarian on that. There's a huge amount of churn at the very small scale, but when you get to that top-level set of languages, we're actually very conservative. For pete's…

> TypeScript hasn't risen to the level of Go.

How do you evaluate that?

Re: Twelve Years of Go

#234

Post by morelisp »

closeparen wrote: post #232
morelisp wrote: post #230

Earlier quoted context omitted.

If all five of those things also need to be independently mocked, you're mocking too much and your mocks suck.

If they're not mocked it's an integration test. Integration tests are welcome as a supplement to unit tests, but unit tests are table stakes.

An automated test suite is table stables. If you can achieve correct, maintainable code better with functional or integration tests than unit tests, you should.

There is no hard technical line between "unit test" and "integration tests", it's a semantic question of how you define your units. Even if do you take a tiny, restrictive definition of your units, you could still use a fake or stub instead of a mock.

https://martinfowler.com/articles/mocksArentStubs.html

To get very specific for Go, we use testify suites, tend to set up fully functional stubs in `SetUp`, and then test cases either use them to verify happy paths, or `s.BreakStep1()` in one test, `s.BreakStep2()` in the next, etc. So in this case we would write a total of five extra lines for the five possible ways to break.

Re: Twelve Years of Go

#235

Post by FR10 »

Go is my go-to language when I can get away with it. (otherwise its RoR for me). The only thing I dont grok besides the aforementioned filter/map/reduce (probably coming soon) is the name itself. It is really hard to Google by itself, now I always default to "golang".

Re: Twelve Years of Go

#236

Post by closeparen »

morelisp wrote: post #234
closeparen wrote: post #232

Earlier quoted context omitted.

If they're not mocked it's an integration test. Integration tests are welcome as a supplement to unit tests, but unit tests are table stakes.

An automated test suite is table stables. If you can achieve correct, maintainable code better with functional or integration tests than unit tests, you should. There is no hard technical line between "unit test" and "integration tests", it's a semantic question of how you define your units. Even if do you take a tiny, restrictive definition of your units, you could still use a fake or stub instead of a mock. https:/…

I think that is a fair opinion and my life at work would be better if others shared that opinion. Go however does officially stake out the opposite position: coverage only "counts" if the test is in the same package as the unit under test.

Re: Twelve Years of Go

#237

Post by [deleted] »

closeparen wrote: post #236
morelisp wrote: post #234

Earlier quoted context omitted.

An automated test suite is table stables. If you can achieve correct, maintainable code better with functional or integration tests than unit tests, you should. There is no hard technical line between "unit test" and "integration tests", it's a semantic question of how you define your units. Even if do you take a tiny, restrictive definition of your units, you could still use a fake or stub instead of a mock. https:/…

I think that is a fair opinion and my life at work would be better if others shared that opinion. Go however does officially stake out the opposite position: coverage only "counts" if the test is in the same package as the unit under test.

[deleted]

Re: Twelve Years of Go

#238

Post by thatswrong0 »

pxue wrote: post #167
thatswrong0 wrote: post #134

Earlier quoted context omitted.

Seriously. I see so many functions in my code see that consist of 1 line of thing I actually care about followed by 3 lines of boilerplate if err not nil… over and over again. IMO if Go didn’t have its tooling, no one would care about it.

i have the completely opposite take. every if err != nil; return err let's me mentally draw a line in the sand and not worry about exception handling for code above that line. It lets me start fresh and restart my mental model with the line of codes below the error handling block. it doesn't take years of writing Go to understand this, all you need is a open mind to how Go does things.

> It lets me start fresh and restart my mental model with the line of codes below the error handling block.

My code is almost exactly:

err := doThing()

if err != nil {

  return err
}

err = doAnotherThing()

if err != nil {

  return err
}

etc.

There's no need for me to "start fresh". Each line of actual stuff doing might return an error which needs to be returned. That's it. It's a complete waste of space and inhibits readability to absolutely no benefit. And this is extremely common across our code base.

Re: Twelve Years of Go

#239

Post by grey-area »

ohCh6zos wrote: post #176
grey-area wrote: post #121

Earlier quoted context omitted.

I imagine they'll add map/filter/find after generics are in. It's pretty easy to define some slice types though which include those in the meantime, type Slice []string and add some functions then just use your new type for collections.

I suspect but do not know that multiple return values in a function combined with the inability to write functions against multiple return types like (T,error) will limit the usefulness of traditional iterators in Go. I'd love to be proved wrong as they'd really clean up my codebase though.

Depends what you're doing I guess, not everything needs to return an error, and errors can be accumulated and stored during certain operations and dealt with at the end.

Re: Twelve Years of Go

#240

Post by amscanne »

pjmlp wrote: post #224
amscanne wrote: post #209

Earlier quoted context omitted.

> The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.

Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings. As it should be.

I’m not sure I follow. I assume “as it should be” refers to crates, with no mechanism for name ownership other than first-come, first-served.

You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.

Post reply on HN