Whats the flagship application thats written in Go? Or the application that we're most likely to have used?
Docker and Kubernetes comes to mind.
Twelve Years of Go
221–230 of 244 posts
Re: Twelve Years of Go
#222Earlier quoted context omitted.
> Just software, running, forever. Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".
Ah, but what if the updated shared lib broke other apps depending on the old version? Pros and cons.
> Pros and cons
Exactly. Which is why I don't get the "static linking is the best solution for deploying applications". You need to be able to do both. For example when building a C/C++ application you can decide if you want shared libs or static builds.
Re: Twelve Years of Go
#223Earlier quoted context omitted.
I have some code where I use multierrors and collect everything into one big error (I highly recommend this for "validation"-type code, you should generally return all errors not merely the first), but what code are you writing where you're running 5 statements unconditionally but need to handle nearly-arbitrary combinations of them failing, and multierrors aren't what you need?
If you have 5 statements like "if err := doThing(); err != nil { return err }" then you need to simulate the success of all 5, success of the first 4 and failure of the last, success of the first 3 and failure of the 4th, success of the first 2 and failure of the 3rd, etc.
For a total of six cases to deal with. Not 15.
Re: Twelve Years of Go
#224Earlier 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.
Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings.
As it should be.
Re: Twelve Years of Go
#225Earlier quoted context omitted.
My non-Go code is starting to look more like my Go code. One of the things Go taught me is that I was not being as careful about my errors as I should be. It can be argued that exception-based handling provides you a nice baseline default, but it makes it way to easy when doing network or system-type programming to thoughtlessly default to that, when you need to be thoughtfully defaulting to that. With sufficient car…
Go’s error handling is a strange this to praise considering it is entirely possible to ignore it without warning and the way to check error kinds was bolted on through type assertions when errors are supposed to be values in Go. Error kinds are important especially in network programming when the error can be dozens of different things. Compare this to something like Rust or Haskell which force you to handle errors a…
Once again Rust does not force you to handle errors, you can ignore errors in Rust and it will compile. I can't say for Haskell but I doubt there is a language that forces you to handle error.
let _ = openFile()
Error ignored, it does compile, it will probably ends badly.
As for network error: https://pkg.go.dev/net#OpError
Re: Twelve Years of Go
#226Earlier quoted context omitted.
If you are or your coworkers are constantly copying and pasting code, stop, and think a bit more. I do a lot of Go development and almost never copy and paste anything anywhere. (And even in those cases it's usually justified. I just a few minutes ago copied and pasted a big struct... but it's because the first struct was defining a JSON message, and the second struct was defining a very similar, but not quite identi…
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 problem, they have learned to reach for the feature that solves it. In Go, you have fewer tools, but they are sharp, and generally well-chosen and work together well.
"Go doesn't have the feature I'm used to using to solve this problem" is not the same as "Go doesn't have a decent solution to this problem". If you are constantly copying and pasting or spreading things out in a way you don't think you should have to, run through the tools that Go does have again. There are several techniques that aren't going to be the first things you necessarily reach from from another language, but work just fine in Go. This is not a complete list but it gives several examples of such techniques: http://www.jerf.org/iri/post/2945
There are some things it really can't do. (Again, I just can't understand the people who are trying to jam their mathematical code into Go. It's just so bad at that.) But that set is smaller than the critics think, because they confuse missing features for missing solutions. It's just another variant of "don't write X in Y", which is never a good idea.
And again, I invite you to post any such issues you may have to /r/golang. If I happen to pick it up, I won't be afraid to tell you straight out there isn't a good Go solution to that. I've done it before. But that happens less often than you might think. I also remind you my goal will be to come up with a good Go solution to the core problem, not "the closest approximation to the feature I expected to use" or anything like that. Write Go in Go, not anything else.
Re: Twelve Years of Go
#227Earlier quoted context omitted.
"plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success." I struggle to think of one that has risen to the heights Go has risen. I'm a computer language polyglot and a bit of a language tourist, though not as much as some people. There's a huge churn of features out there in some language somewhere, that has never manifested in any top-level language like C++ or Jav…
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 sake, C is still a top-level language in 2021! It's finally on its way down, but it's got a long way to go to fall out of that criterion, unfortunately.
This is why I didn't even necessarily label Go as a "top-level" language. It's only 12 years old, after. It's a whippersnapper of a top-level langauge. 25 years old makes for a young top-level language!
Re: Twelve Years of Go
#228Earlier quoted context omitted.
If you have 5 statements like "if err := doThing(); err != nil { return err }" then you need to simulate the success of all 5, success of the first 4 and failure of the last, success of the first 3 and failure of the 4th, success of the first 2 and failure of the 3rd, etc.
For a total of six cases to deal with. Not 15.
I said 15 mock expectations, not cases.
Re: Twelve Years of Go
#229Earlier 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…
That’s something new handle as close as possible to the outbound client, which is several layers in from the inbound request. Much of it is in gRPC middlewares, so by the time a gRPC client returns an error to the gateway it’s already over.