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

241–244 of 244 posts

Re: Twelve Years of Go

#241

Post by amscanne »

uncomputation wrote: post #231
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.

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…

Re: tags, that’s true but builds will detect this and break (since the hash is encoded in the sum file). No one should move tags, ever (for many reasons), and Go is simply requiring this.

Re: git, there is no assumption of git. Go also natively supports svn, hg, bzr and fossil. You also have the option to vendor things.

It’s fine to favor crates because it’s closer to what you’re used to, but I think you’re just complaining about ergonomics. They both have semver and implement satisfiability in similar ways (AFAIK).

It seems like the source control mixin is what’s causing the most frustration, and I get it — that’s where you have ergonomics you’re not used to — however, this is also where Go shines since it essentially gives you supply chain integrity without the need to trust any users uploading code (module owners) or third party vendors (crates).

What is the question for which you are looking for a simple, clear answer? Honestly, the documentation is quite excellent [1], but I’m happy to do my best to point to the best place for answers.

[1] https://golang.org/ref/mod

Re: Twelve Years of Go

#242

Post by azth »

jerf wrote: post #226
azth wrote: post #207

Earlier quoted context omitted.

I agree with the poster you're replying to. The large golang projects I've been involved with have been extremely tedious to work on, even on projects started from scratch. The language is extremely weak (it's not expressive), which translates to overly verbose code that is difficult to traverse. Logic that can be expressed in a couple of lines in Java becomes 10+ lines in golang, with code scattered everywhere. Not…

I work in Go all the time. While there are occasionally things that come out a bit more verbose, and they may stand out in your mind, if you are always writing things that much more verbose, stop, think, and make sure that there isn't some way to do it in Go correctly. Because there usually is. The problem is, a lot of people are used to working in languages which have an abundance of features, so when they have a pr…

Sum types with exhaustive checking, and records are two extremely serious omissions in golang. Several times now we've run into issues because of this in the current project I'm working on.

Re: Twelve Years of Go

#243

Post by merb »

Karrot_Kream wrote: post #200
merb wrote: post #151

Earlier quoted context omitted.

and most of the time you can't handle it anyway. I mean consider you are having a database query and it fails because the connection error'd (network split). what to do know? restart the network switches and wait? of course not in http you will just print a 5xx err and hope it comes back. in go you need to bubble up these errors to your middleware and handle it there.

If this is seriously what you do when something underneath you fails, then you aren't writing in the domain of software where errors really matter, and you're probably better off in a language that has a gigantic try/catch handler around everything. In that case you may as well just log (or not) and ignore the error in Go as well then. At high scale, you want to perhaps try your query a few more times, backing off ex…

> At high scale

so basically you mean that this only applies to like 0.001% of all websites/apps.

thus it's stupid to do it. I mean even than you would have an error that you need to bubble up or circuit break it somwhere but probably not at this layer.

also KISS and MVP, never ever overcomplicate something when you do not know anything yet, so most people don't need to built for scale at day 1 and it also is stupid to do it.

Re: Twelve Years of Go

#244

Post by Karrot_Kream »

merb wrote: post #243
Karrot_Kream wrote: post #200

Earlier quoted context omitted.

If this is seriously what you do when something underneath you fails, then you aren't writing in the domain of software where errors really matter, and you're probably better off in a language that has a gigantic try/catch handler around everything. In that case you may as well just log (or not) and ignore the error in Go as well then. At high scale, you want to perhaps try your query a few more times, backing off ex…

> At high scale so basically you mean that this only applies to like 0.001% of all websites/apps. thus it's stupid to do it. I mean even than you would have an error that you need to bubble up or circuit break it somwhere but probably not at this layer. also KISS and MVP, never ever overcomplicate something when you do not know anything yet, so most people don't need to built for scale at day 1 and it also is stupid…

You can get off-the-shelf libraries that do this for you with zero-effort sane defaults. Most of them let you tweak the settings. I'm talking about Python's `requests` and Rust's `reqwest` here btw, two of the most popular HTTP client libraries out there. Python's `urlopen3`, which `requests` uses, exposes options for backoff strategies. `aiohttp` has a lot of these parameters as well. Unfortunately Rust's equivalent, `hyper`, isn't nearly as ergonomic/easy to use.
Post reply on HN