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

3.5 Years, 500k Lines of Go

npf.io

Post reply on HN
Print view View original

231–240 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#231

Post by iopq »

weberc2 wrote: post #96
Filligree wrote: post #89

Earlier quoted context omitted.

Go has special syntax for channels, maps and slices. It's impossible to define your own data structures using the same syntax. An argument can be made for array subscripts, certainly, but why can't you use 'make' for your own code? They're also magic in that Go does have generics, but only for those three types.

I think you and I have different definitions of 'magic'. I agree that Go does not have user-defined generics. I don't think of a few blessed data-structures as 'magic', but I won't argue semantics.

I disagree with the concept of "blessed" syntax in the first place. I want users to write libraries just as powerful as the standard library.

Re: 3.5 Years, 500k Lines of Go

#232

Post by jy3 »

kuschku wrote: post #218
jy3 wrote: post #211

Earlier quoted context omitted.

> I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times Who would have thought. Maybe a rewrite would have been more appropriate.

Porting meant rewriting here. But I still ended up with the same classes replicated hundreds of times. Polymorphic code is not possible in any other way in go – you always have to duplicate the code.

I'm sorry it went badly then.

Your example intrigues me, isn't an interface enough?

Is what bother you that the return value won't be typed T but IIncrementable in go?

Re: 3.5 Years, 500k Lines of Go

#233

Post by josteink »

Is it too late to queue the joke about it being 500k lines because the lack of generics and the resulting code-generation?

Reading about projects with 100+ types of collections can certainly lead you to think so.

Re: 3.5 Years, 500k Lines of Go

#234

Post by norswap »

grey-area wrote: post #197
norswap wrote: post #140

Earlier quoted context omitted.

Hogwash. In a language with operator overloading, this would be something like `a.assign(b.plus(c))`. Which really doesn't tell you more about what go on under the wraps than the operator form. What can be confusing is what the meaning of `+` (or `plus` is). In some case it can be fairly obvious (e.g. concatenating sequences), while in other not so much. Operator overloading is nice, but has to be used tastefully (li…

In C#, you can overload operators, so the + could in theory do anything. What can be confusing is what the meaning of `+` (or `plus` is) QED

Any function can do anything. I can write a function called "read_from_file()" that doesn't read any files.

Amazing, I know.

Also please actually read the comment before replying:

> Operator overloading is nice, but has to be used tastefully.

Re: 3.5 Years, 500k Lines of Go

#235

Post by kazinator »

NateDad wrote: post #112
kasey_junk wrote: post #29

Earlier quoted context omitted.

> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…

> In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers

That is overloading! What go eschews is user-defined overloading.

Re: 3.5 Years, 500k Lines of Go

#236

Post by ryeguy »

cdelsolar wrote: post #153
grabcocque wrote: post #10

This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…

I write Go all the time. The number of times I've said "I wish I had generics" is 0. It's absurd how goddamn often this gets said ON EVERY GO THREAD EVER.

There is absolutely 0 chance in the time you've written go that you haven't encountered a problem that would be best solved by generics. Chances are you're just implementing them in a different way. I say this as someone who uses Go.

Re: 3.5 Years, 500k Lines of Go

#237

Post by kuschku »

jy3 wrote: post #232
kuschku wrote: post #218

Earlier quoted context omitted.

Porting meant rewriting here. But I still ended up with the same classes replicated hundreds of times. Polymorphic code is not possible in any other way in go – you always have to duplicate the code.

I'm sorry it went badly then. Your example intrigues me, isn't an interface enough? Is what bother you that the return value won't be typed T but IIncrementable in go?

Yes, exactly. This is an actual issue.

My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts.

So, the library now gets these functions, and does all the filtering on other threads.

So either I have to replicate the entire async code for every type, or I can’t keep type safety.

Re: 3.5 Years, 500k Lines of Go

#238

Post by weberc2 »

iopq wrote: post #231
weberc2 wrote: post #96

Earlier quoted context omitted.

I think you and I have different definitions of 'magic'. I agree that Go does not have user-defined generics. I don't think of a few blessed data-structures as 'magic', but I won't argue semantics.

I disagree with the concept of "blessed" syntax in the first place. I want users to write libraries just as powerful as the standard library.

Philosophically, I agree. Pragmatically, generics seem to tempt programmers into writing really weird code in pursuit of some purist notions of terseness or reusability. After having used Go as well as lots of languages with generics, I will say that most Go programmers write very similar code for very similar problems, and it does make it easier for programmers to understand each other's code. There are a few times that user-defined generics would be handy, but those times are really very rare and I'm not convinced that adding generics to the language would be a net positive. In fact, I think the case for algebraic data types is stronger than the case for generics.

Re: 3.5 Years, 500k Lines of Go

#239

Post by rogpeppe1 »

kuschku wrote: post #237
jy3 wrote: post #232

Earlier quoted context omitted.

I'm sorry it went badly then. Your example intrigues me, isn't an interface enough? Is what bother you that the return value won't be typed T but IIncrementable in go?

Yes, exactly. This is an actual issue. My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts. So, the library now gets these functions, and does all the filtering on other threads. So either I have to replicate the entire async code for every type, or I can’t keep type safety.

Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not required.

Re: 3.5 Years, 500k Lines of Go

#240

Post by kuschku »

rogpeppe1 wrote: post #239
kuschku wrote: post #237

Earlier quoted context omitted.

Yes, exactly. This is an actual issue. My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts. So, the library now gets these functions, and does all the filtering on other threads. So either I have to replicate the entire async code for every type, or I can’t keep type safety.

Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not required .

If you’re serious, that’s... the worst solution I’ve heard yet.

That’s the same mistake C did with void, Java did with Object and corrected with generics in 1.5, just called interface{} this time.

And while with python and Java, even if I circumvent the type system, I can still use annotations (see typed python, or JetBrains @Contract, Google’s @IntRange, etc), with Go I have nothing of that sort.

Types are useful to provide safety, if your type system has to be turnt off, then I am losing all that safety, and might as well code in PHP (although they also* saw that mistake, and are fixing it now, with 7.0 and later).

Post reply on HN