4 ms·

W/r/t #2 - you're not familiar with Go but knew exactly what was going on. That's totally a feature. The language was designed around exactly that kind of readi

W/r/t #2 - you're not familiar with Go but knew exactly what was going on. That's totally a feature. The language was designed around exactly that kind of reading. "break;" is implicit in Go.

joshuaellinger 13y ago
Sure, I spend a decade in C. It's not hard to read. My only problem with using generics in this context is that you can't catch type-conversion errors at compile time. Seems like a step backwards with only downside. I get why exceptions are a double-edge sword. I'm not clear on why undermining compile time type safety is an feature.
- burntsushi 13y ago
  > I'm not clear on why undermining compile time type safety is an feature. More safety usually requires a more complex type system. Such a type system is usually more expressive and can make more guarantees about your program, which is a pro. But of course, it is also more complex, which is a con.
- smosher 13y ago
  > I'm not clear on why undermining compile time type safety is an feature. I think this is what people will ultimately focus on when considering Go. Many of the complaints are a product of type weaknesses in the language, voiced by people who had assumed that a modern static language wouldn't have that fault. Others tend not to mind because they lack that expectation, and regard the dynamic behaviour you can get as a feature. The argument about shared mutable state goes the same way, but for some concurrent but non-parallel code it might be convenient. I can easily see people picking Go when moving from Python. But not when moving from a static language with a stronger, safer type system. Also, as burntsushi points out, it does require more sophistication in the type system. I doubt they're trying to sell a naively simplistic type system (sophistication often makes it easier to use), but when Go was announced the feature they seemed to be selling the hardest was short compilation times. I think that feature is the seed of this behaviour.

W/r/t #2 - you're not familiar with Go but knew exactly what was going on. That's totally a feature. The language was designed around exactly that kind of reading. "break;" is implicit in Go.

joshuaellinger 13y ago

Sure, I spend a decade in C. It's not hard to read. My only problem with using generics in this context is that you can't catch type-conversion errors at compile time. Seems like a step backwards with only downside. I get why exceptions are a double-edge sword. I'm not clear on why undermining compile time type safety is an feature.

burntsushi 13y ago
> I'm not clear on why undermining compile time type safety is an feature. More safety usually requires a more complex type system. Such a type system is usually more expressive and can make more guarantees about your program, which is a pro. But of course, it is also more complex, which is a con.
smosher 13y ago
> I'm not clear on why undermining compile time type safety is an feature. I think this is what people will ultimately focus on when considering Go. Many of the complaints are a product of type weaknesses in the language, voiced by people who had assumed that a modern static language wouldn't have that fault. Others tend not to mind because they lack that expectation, and regard the dynamic behaviour you can get as a feature. The argument about shared mutable state goes the same way, but for some concurrent but non-parallel code it might be convenient. I can easily see people picking Go when moving from Python. But not when moving from a static language with a stronger, safer type system. Also, as burntsushi points out, it does require more sophistication in the type system. I doubt they're trying to sell a naively simplistic type system (sophistication often makes it easier to use), but when Go was announced the feature they seemed to be selling the hardest was short compilation times. I think that feature is the seed of this behaviour.