21–30 of 297 posts
Most of the items explained are non-issues and part of why Golang is how it is today. Lets hope we can keep the language as-is and don't go back to old decisions and remove features like Scala have been doing the last years...
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think t…
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
Not every line of code is life or death.
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think t…
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
Earlier quoted context omitted.
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think t…
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like la…
It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical.
> That's horrifying.
append() doesn't operate on arrays, it operates on slices. Arrays are fixed-length, contiguous blocks of memory that can't be appended to. Slices are backed by arrays, and if you append to a slice whose backing array is full, it will "grow" by allocating a bigger array elsewhere and copying the original data into it. This is a pretty standard data structure in most languages.
Earlier quoted context omitted.
My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
Earlier quoted context omitted.
My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
Earlier quoted context omitted.
My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
most of these seems reasonable, but they are not big enough for me to actively dislike the language. The capitalisation is maybe the most annoying for me, I think it was designed with an IDE in mind (which would be able to automatic update all references), but I still find it a flawed design to have to touch potentially a lot of files, many places to change something from private to not private. The problem with err…
Golint can enforce the "don't ignore errors" rule. I think it comes that way out of the box?