421–430 of 559 posts
Earlier quoted context omitted.
Can someone help me understand why enums are needed? They only seem like sugar for reducing a few lines while writing. What cannot be achieved without them or what is really a pain point they solve? Maybe it is hard to have a constant with type information?
The original enum are just enumerated integer constants. What people want "the ability to express enums with an associated value", I think we should invent a new term.
Earlier quoted context omitted.
Nor yours.
This kind of pandering horseshit from throwaway accounts add no value and should be downvoted on sight. Especially if you bake self-deprecation into it, "uwu I'm... I'm not sure if a-anybody is going to like my comment..." Just let the good conversation unfold without patronizing meta-commentary. This isn't Reddit.
Earlier quoted context omitted.
Nor yours.
This kind of pandering horseshit from throwaway accounts add no value and should be downvoted on sight. Especially if you bake self-deprecation into it, "uwu I'm... I'm not sure if a-anybody is going to like my comment..." Just let the good conversation unfold without patronizing meta-commentary. This isn't Reddit.
Earlier quoted context omitted.
> but all the information you need to perform such analysis is there. No, it isn't, unlike C, in which it is. The C compiler can actually differentiate between an enum with one name and an enum with a different name. There's no real reason the compiler vendor can't add in warnings when you pass in `myenum_one_t` instead of `myenum_two_t`. They may not be detecting it now, but it's possible to do so because nothing in…
> No, it isn't, unlike C, in which it is. Go on. Given: type E int const ( A E = iota B C ) enum E { A, B, C } What is missing in the first case that wouldn't allow you to perform such static analysis? It has a keyword to identify initialization of an enumerated set (iota), it has an associated type (E) to identify what the enum values are applied to, and it has rules for defining the remaining items in the enumerate…
Type information. The only type info the compiler has is "integer".
> It has a keyword to identify initialization of an enumerated set (iota),
That's not a type.
> it has an associated type (E)
It still only has the one piece of type information, namely "integer".
> and it has rules for defining the remaining items in the enumerated set
That's not type information
> That's all C gives you.
No. C enums have additional information, namely, which other integers that type is compatible with. The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.
Go doesn't store this difference - `Monday` is no different in type than `January`.
> Warnings are not fatal.
Maybe, but the warning tells you that they types are not compatible. The fact that the compiler tells you that the types are not compatible means that the compiler knows that the types are not compatible, which means that the compiler regards each of those types as separate types.
Of course you can redirect the warning to /dev/null with a flag, but that doesn't make the fact that the compiler considers them to be different types go away.
Whether you like it or not, C compilers can tell the difference between `Monday` and `January` enums. Go can't tell the difference between `Monday` and `January` constants. How can it?
This addresses pretty much all of my least favorite things with writing Go code at work, and I hope--at the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias!) of the responses inspires Go maintainers to consider/prioritize some of these features, or renews the authors interest in working on the project (as some have commented, it seems to have gone without activity fo…
I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from…
Go was designed to be simple enough that developers can’t write code too complicated for others to read, with a particular eye towards junior devs (and ops/infra people, I think).
This usage of sigils for error handling and union return types is very cool and very expressive, but also going to confuse the shit out of your new devs or infra people. It’s just not a good fit for what Go wants to be.
I’m even sympathetic to the idea that generics are similar, though personally I think the alternative to generics is code generators, which are worse.
Anecdotally, I recently wrote some Go code at work (infra team) that used generics, and I had to look outside my team to even find someone that felt comfortable reviewing generic Go code. I see a fair bit of code using interface{} or any that would be much simpler and better with generics.
Earlier quoted context omitted.
Yes, because there is no one in the room able to configure the formating tool for the whole SCM. A simple settings file set in stone by the CTO, such a hard task to do. The fact that is even a novelty unaware of, only confirms the target group for the language.
> A simple settings file set in stone by the CTO, such a hard task to do. And then you have a 100 companies with 100 CTOs resulting in 100 different styles. With Go there is only one style everywhere.
Earlier quoted context omitted.
Yes, because there is no one in the room able to configure the formating tool for the whole SCM. A simple settings file set in stone by the CTO, such a hard task to do. The fact that is even a novelty unaware of, only confirms the target group for the language.
> A simple settings file set in stone by the CTO, such a hard task to do. It does seem hard thing to do. Working over dozens of enterprise shops in last 15 years I have not see such setting done or dictated at all. So whole codebase used to be mishmash of person styles.
Earlier quoted context omitted.
Yes, because there is no one in the room able to configure the formating tool for the whole SCM. A simple settings file set in stone by the CTO, such a hard task to do. The fact that is even a novelty unaware of, only confirms the target group for the language.
IMHO it's not about the standards in your company, it's more about being able to parse any random library on GitHub etc with your eyeballs.
Earlier quoted context omitted.
> No, it isn't, unlike C, in which it is. Go on. Given: type E int const ( A E = iota B C ) enum E { A, B, C } What is missing in the first case that wouldn't allow you to perform such static analysis? It has a keyword to identify initialization of an enumerated set (iota), it has an associated type (E) to identify what the enum values are applied to, and it has rules for defining the remaining items in the enumerate…
> What is missing in the first case that wouldn't allow you to perform such static analysis? Type information. The only type info the compiler has is "integer". > It has a keyword to identify initialization of an enumerated set (iota), That's not a type. > it has an associated type (E) It still only has the one piece of type information, namely "integer". > and it has rules for defining the remaining items in the enu…
Nobody said it was. Reaching already? As before, enums are not a type, they are a numbering mechanism. Literally. There is an associated type in which to hold the numbers, but that's not the enum itself. This is true in both C and Go, along with every other language with enums under the sun.
> The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.
Sure, just as in Go:
type Day int
const (
Monday Day = iota
Tuesday
// ...
)
type Month int
const (
January Month = iota
February
// ...
)
func month(m Month) {}
func main() {
month(January) // OK
month(Monday) // Compiler error
}
Are you, perhaps, mixing up Go with Javascript?
> How can it?
By, uh, using its type system...? A novel concept, I know.