Earlier quoted context omitted.
What do you mean by no consistency in formatting? go fmt is a solid formatter that does its job
Go fmt is pretty good, but it's not ideal. My biggest gripe is imports. Go fmt will just sort imports alphabetically in lists that aren't separated by a blank line. Goimports will separate out core from 3rd party imports, unless you run it with the local flag then it'll add a third block of "local" imports. But this spread means that it's not consistent across projects which style is preferred. Some examples, based o…
Go is my hammer, and everything is a nail
311–320 of 816 posts
Re: Go is my hammer, and everything is a nail
#312Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…
Re: Go is my hammer, and everything is a nail
#313Earlier quoted context omitted.
Hold on, did you just say Go doesn't have a Dictionary data type? I'm a Javascript, Lua, Python, and C# guy and Dict is my whole world.
Not a programmer, so this is every programmer's chance to hammer me on correctness. No, Go doesn't have a type named Dict, or Hash (my Perl is leaking), or whatever. It does have a map type[1], where you can define your keys as one type, and your values of another type, and that pretty closely approximates Dicts in other languages, I think. [1]: https://go.dev/blog/maps
https://en.wikipedia.org/wiki/Hash_table
They're a very common and useful idea from Computer Science so you will find them in pretty much any modern language, there are a lot of variations on this idea, but the core idea recurs everywhere.
Re: Go is my hammer, and everything is a nail
#314Re: Go is my hammer, and everything is a nail
#315Earlier quoted context omitted.
> The list comprehension is ever slightly more readable. I disagree - it's terse to the point of being hard to parse, particularly when you get smart ones like: [x for x in t if x not in s] > It is a bit faster to write the code for the Python variant. Code should be written to be read. Saving a few keystrokes vs time spent figuring out the `not in in not with` dance gives the the edge to Golang here. It's "high cont…
Luckily, we are writing Python, not Go, so we can use variable names with more than one letter: [word for word in sentence if word not in bannedWords] Suddenly, nothing is hard to parse.
let a = collect:
for word in wordList:
if word notin bannedWords:
word
let b = collect(for x in list: x)
It's still very terse, but, more importanly, it's the same syntax as a regular `for loop`. It has the structure, where in Python complex comprehensions look like a "keyword soup".Re: Go is my hammer, and everything is a nail
#316Earlier quoted context omitted.
> being pedantic about the definition of an enum to say "actually go has them" isn't helpful. Incorrect. The term "real enums", where used to imply that enums are something other than the basic element of the same name, encompasses a number of distinct features that are completely independent of each other. In order to meaningfully talk about "real enums", we need to break it down into the individual parts. If you're…
Dude. Everyone knew what "real enums" meant including you . Please stop. And yes popular languages do have real type safe enums. C++, Typescript, Rust, god even Python.
Right, as we already established, but which is only incredibly narrow support within the features in question. While you can find safety within the scope of enums and enums alone, it blows up as soon as you want the same safety applied to anything else. No popular language comes close to completing these features, doing it half-assed at most. We went over this several times now. Typescript goes a little further than most popular languages, but even it doesn't go very far, leaving all kinds of gaps where the type system does not provide the aforementioned safety.
You clearly know how to read, by your own admission, so why are you flailing around like one of those wacky blow up men at the used car lot? Are you just not familiar with programming?
Re: Go is my hammer, and everything is a nail
#317Earlier quoted context omitted.
I would rather go had real enums, and I would _prefer_ if there were sum types. I agree it's more verbose, but I don't find that that verbosity really bothers me most of the time. Is res= [x for x in foo if "banned" in x] really actually more readable than var result []string for _, x := range foo { if strings.Contains(x, "banned") { result = append(result, x) } } ? I know it's 6 lines vs 1, but in practice I look at…
I agree that list comprehensions aren't any easier to read. A proper streaming interface on the other hand lets you easily follow how the data is transformed: foo .stream() .filter(x -> x.contains("banned")) .collect(Collectors.toList()); As an aside, Go conflating lists and views irks me, in part due to what weird semantics it gives to append (e.g. if you have two disjunct slices and append an element to one slice,…
Re: Go is my hammer, and everything is a nail
#318People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…
One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust,…
I am extremely doubtful that this is true and would like evidence.
Re: Go is my hammer, and everything is a nail
#319Earlier quoted context omitted.
That's why I love Go so much. You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly…
For loops? Dang that’s some clever syntax you have there. Personally I prefer a big standard while loop. /s
Re: Go is my hammer, and everything is a nail
#320Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc. I’m sure these are the exact reasons why Go is good for enterprise software, but for per…
I feel like autocomplete has reduced the problem of verbosity for all languages. And if I am writing something that is going to have to be supported a lot I want something that is very explicit and easy to read. For me that is the "verbose" languages.