Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

Post reply on HN
Print view View original

231–240 of 396 posts

Re: Russ Cox is stepping down as the Go tech lead

#231

Post by foldr »

Cthulhu_ wrote: post #203
lopkeny12ko wrote: post #194

Earlier quoted context omitted.

> Unified codestyle The moment I got my first compile error due to an unused variable and an unused import, made me realize Go is not a serious programming language.

I wonder who hurt them, that is, how much did unused variables/imports hurt at Google for them to make those a compiler error? Insofar I know it, I can imagine C/C++ caused some issues like that because it's hard to figure out whether an import is used, but an unused import does have a cost.

I think the fundamental reason behind this behavior is just Go's rejection of the concept of compiler warnings. Unused variables must either be A-ok or trigger an error. They chose the second option for unused variables. Some other code smells are considered A-ok by the compiler and need to be caught by linters.

Re: Russ Cox is stepping down as the Go tech lead

#232

Post by jessekv »

_the_inflator wrote: post #191
cookiengineer wrote: post #158

Earlier quoted context omitted.

The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion up…

Clutter death that creeps in any language, as I see it. To this day, only a small subset of JS syntax is used; I cannot recall anyone besides me ever using method chaining like .map .filter, etc. There is a reason why almost every good language is somewhat akin to C to this day, and maybe people started over to get rid of the noise.

Haha interesting. I actually like .map/.filter/.find/etc. in JS and comprehensions in Python. I find they communicate the intent of the programmer really clearly as compared to a for-loop.

Re: Russ Cox is stepping down as the Go tech lead

#233

Post by remus »

hankman86 wrote: post #147

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

I guess it depends on how you define success, but given there's a lot of people writing a lot of go code inside and outside of google over the last 15 years it seems likely it's doing a decent job at solving problems for those people. I'd call that a success.

Re: Russ Cox is stepping down as the Go tech lead

#234

Post by noelwelsh »

foldr wrote: post #229
noelwelsh wrote: post #193

Earlier quoted context omitted.

I think you're confusing the type and value level. The original statement was about a range type , that is something like an integer that is statically constrained to a range of, say, 1..4 (1, 2, 3, 4). To work with this as a type you need to have type level operations, such as adding two ranges (which can yield a disjoint range!), adding elements to the range, and so on, which produce new types. These all have to wo…

OP is just saying that you don't have to permit operations such as addition or incrementation on range types, in which case you don't need the corresponding type-level operations.

> That is certainly a valid way to address your question – i.e. don't allow incrementing said type. Force converting it to a type that supports incrementing, and then from that the developer can, if they so choose, convert it back to an appropriate range type, including the original range type if suitable.

The quoted part above is an argument for dependent types. The conversion back to a range type creates a type that depends on a value, which is the essence of dependent typing.

Re: Russ Cox is stepping down as the Go tech lead

#236

Post by jen20 »

trustno2 wrote: post #174
KronisLV wrote: post #166

Earlier quoted context omitted.

With it being so consistent and predictable, I wonder why it hasn’t displaced .NET and Java in the enterprise for back end development. Maybe because a framework like ASP.NET or Spring that covers like 80+% of the enterprise needs hasn’t quite emerged? Or perhaps we just need to give it a decade or so. There are still very few Go jobs in my country, most are either .NET, Java or PHP.

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language. The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise. yes there are orm solutions and DI frameworks and all that, but they always feel like they…

> usually have lots of layers for organizational reasons

The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).

Re: Russ Cox is stepping down as the Go tech lead

#237

Post by foldr »

noelwelsh wrote: post #234
foldr wrote: post #229

Earlier quoted context omitted.

OP is just saying that you don't have to permit operations such as addition or incrementation on range types, in which case you don't need the corresponding type-level operations.

> That is certainly a valid way to address your question – i.e. don't allow incrementing said type. Force converting it to a type that supports incrementing, and then from that the developer can, if they so choose, convert it back to an appropriate range type, including the original range type if suitable. The quoted part above is an argument for dependent types. The conversion back to a range type creates a type tha…

No, I think the idea is that you'd get a runtime exception if the value was outside the range. No need for dependent types. It is no different conceptually from casting, say, a 64-bit integer to a 32-bit integer. If the value is outside the range for a 32-bit integer, then (depending on the language semantics) you either raise a runtime error, or the result is some kind of nonsense value. You do not need to introduce dependent types into your language to enable such casts (as long as you're willing to enforce the relevant checks only at runtime, or forego such checks altogether).

Re: Russ Cox is stepping down as the Go tech lead

#238

Post by jen20 »

foldr wrote: post #231
Cthulhu_ wrote: post #203

Earlier quoted context omitted.

I wonder who hurt them, that is, how much did unused variables/imports hurt at Google for them to make those a compiler error? Insofar I know it, I can imagine C/C++ caused some issues like that because it's hard to figure out whether an import is used, but an unused import does have a cost.

I think the fundamental reason behind this behavior is just Go's rejection of the concept of compiler warnings. Unused variables must either be A-ok or trigger an error. They chose the second option for unused variables. Some other code smells are considered A-ok by the compiler and need to be caught by linters.

The problem with such rejection is that every serious project written in Go has invented compiler warnings outside the compiler, with linters.

Re: Russ Cox is stepping down as the Go tech lead

#239

Post by [deleted] »

dash2 wrote: post #146
TheDong wrote: post #137

Earlier quoted context omitted.

[flagged]

That argument completely makes sense (I don’t know if it’s true, because I know absolutely zero about the go community, but it’s a sensible argument). It’s a pity that to make it, you initially used the shorthand of “old white dudes“ - a derogation based on people’s race, sex and age.

[deleted]

Re: Russ Cox is stepping down as the Go tech lead

#240

Post by noelwelsh »

foldr wrote: post #237
noelwelsh wrote: post #234

Earlier quoted context omitted.

> That is certainly a valid way to address your question – i.e. don't allow incrementing said type. Force converting it to a type that supports incrementing, and then from that the developer can, if they so choose, convert it back to an appropriate range type, including the original range type if suitable. The quoted part above is an argument for dependent types. The conversion back to a range type creates a type tha…

No, I think the idea is that you'd get a runtime exception if the value was outside the range. No need for dependent types. It is no different conceptually from casting, say, a 64-bit integer to a 32-bit integer. If the value is outside the range for a 32-bit integer, then (depending on the language semantics) you either raise a runtime error, or the result is some kind of nonsense value. You do not need to introduce…

I think the original comment is imprecise. E.g. "don't allow incrementing said type" can be read as either "don't allow incrementing values of said type" or literally as don't allow incrementing the type. I can see both your and my interpretation, depending on how one chooses to read the comment.
Post reply on HN