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

211–220 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#211

Post by jy3 »

kuschku wrote: post #102
NateDad wrote: post #61

Earlier quoted context omitted.

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

And go can not write abstract functions and methods. I can not write a function dealing with arbitrary values. Somethind I’d do in Java with public static T increment(T val) { val.increment(); return val; } is impossible to do in Go. You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of t…

> 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.

Re: 3.5 Years, 500k Lines of Go

#212

Post by sheepmullet »

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…

If your project has high turnover (say 20%+) then a blub language makes a lot of sense.

Any gains from using a richer language are dwarfed by extra time spent getting new developers up to speed.

I've worked on projects with an average tenure of 9 months and projects with an average tenure of 4 years. The approach you have to take is completely different.

There is just so much variation in our industry.

As an example the most important work I did on one project was setup and maintain a prebuilt dev environment image. It saved many dev years worth of effort. We were adding ~15 new devs/month.

On the other hand I've also worked on projects where setting up and maintaining a prebuilt dev environment would be a complete waste of resources. We were adding a new dev every ~18 months.

Re: 3.5 Years, 500k Lines of Go

#213

Post by user5994461 »

tigershark wrote: post #202
user5994461 wrote: post #192

Earlier quoted context omitted.

>>> I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers -- especially for a new language where hiring experienced devs is next to impossible. The ease of onboarding is reason enough for businesses to consider Go as over an org's life a lot of time will be spent (wasted?) onboarding. Agree. I feel it so much. I stopped counting the companies I couldn't join because they had ex…

Accordingly to your logic then we should have no language other than C because everyone had decades worth of experience in that language and was not interested in starting fresh again. From my point of view I was very relieved when imperative languages and their adept seemed finally to embrace better tools after Y2K. Apparently now there is Go that follows up with that style (that was perfectly fine for a 10 years ol…

Actually, yes, that's a very good example.

Go uses the C syntax. That is the most known syntax in the world. It's in the same family as C++, Java, C#, and in a different league PHP, Javascript.

That's the kind of VERY IMPORTANT DETAILS that make a language reasonable. Go didn't attempt to throw under the bus a decade of muscle-memory coding.

By comparison, F# or Ruby are total aliens in every regard and not just the syntax, even when compared to the most similar languages.

Re: 3.5 Years, 500k Lines of Go

#214

Post by psiclops »

tonyedgecombe wrote: post #40
ben_pr wrote: post #9

I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity. > Because Go has so little magic, I think this was easier than it would have been in other languages. You don’t have the magic that other languages have that can make seemingly simple lines of code have unexpected functionality. You never have to ask “how does this work?”, because it’s just plain old Go code. That lack…

> It appears to offer a lot with minimal complexity. Actually I think it offers little with minimal complexity.

Here's a blog post from Rob Pike about the design philosophies inherent in Go, and how that affected adoption from C/C++ developers vs. Python, Ruby, etc.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: 3.5 Years, 500k Lines of Go

#215

Post by dahauns »

sagichmal wrote: post #198
pjmlp wrote: post #195

Earlier quoted context omitted.

Just because Go eschews decades of CS knowledge, in the name of the "easy to hire programmers" for Google[1], it doesn't make it less true. [1] - According to the language designers own words

What you wrote isn't a universal truth. In Go, + is not a function like any other. There's no argument to this.

What is the difference, apart from the notation?

Re: 3.5 Years, 500k Lines of Go

#216

Post by nuggien »

kasey_junk wrote: post #136
gentoo wrote: post #104

Earlier quoted context omitted.

In go, there are a minimal amount of primitives (like channels, slices) to learn. Once you know them, they're fairly intuitive. In C#, properties can be arbitrarily complex. You can't just know how properties "work" and then do mental shorthand on them. Every time you look at a new codebase you might have to dig through several files to find out what one line does.

But the "magic" in this case is that properties can be methods. Once you know that how is it any different than methods? In go methods can be arbitrarily complex. You can't know how they work without digging through several files to find what one line does. Another example of magic in go would be method names . You have no idea if it is safe to change the name of a method because it could be satisfying an interface f…

> Another example of magic in go would be method names. You have no idea if it is safe to change the name of a method because it could be satisfying an interface far away from the definition site (or in the case of exported methods nowhere you have access to).

Is this true? If you changed the name of a method, it will no longer satisfy that interface and your code would not compile.

Re: 3.5 Years, 500k Lines of Go

#217

Post by nuggien »

sheepmullet wrote: post #210
sagichmal wrote: post #194

Earlier quoted context omitted.

> From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.

The point is in most languages operator overloading is no more complex than a method call. It's not exactly magic.

Overloading + could be magic if you want it to be. In go, + is exactly what you think it is. In languages with operator overloading, I literally could make + do whatever I wanted to.

Re: 3.5 Years, 500k Lines of Go

#218

Post by kuschku »

jy3 wrote: post #211
kuschku wrote: post #102

Earlier quoted context omitted.

And go can not write abstract functions and methods. I can not write a function dealing with arbitrary values. Somethind I’d do in Java with public static T increment(T val) { val.increment(); return val; } is impossible to do in Go. You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of t…

> 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.

Re: 3.5 Years, 500k Lines of Go

#219

Post by erik_seaberg »

grey-area wrote: post #171
goatlover wrote: post #158

Earlier quoted context omitted.

That's a legitimate concern. But then again, the world is full of programming languages. Sometimes you really appreciate what an R gives you when needing to do a lot of statistical computing and data wrangling, or what C or Rust offers for systems programming, and so on. And speaking of DSLs, the Pandas and Numpy libraries in Python are super useful, and they're possible because Python offers enough metaprogramming f…

I think the point is that Lisp lets you create an ad-hoc, poorly-specified version of any language you like, or perhaps several mashed together, which feels great at the time, but feels horrible when you come back to it later. DSLs/Jargon/New Languages are constructing a new world, and you need to be really sure the costs of that abstraction are outweighed by concrete and lasting benefits in the domain (sometimes the…

The DSL doesn't go away. Your only choices are to implement it, or else read and write the boilerplate you get by imperfectly compiling it in your head.

Re: 3.5 Years, 500k Lines of Go

#220

Post by tptacek »

kasey_junk wrote: post #29
ben_pr wrote: post #9

I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity. > Because Go has so little magic, I think this was easier than it would have been in other languages. You don’t have the magic that other languages have that can make seemingly simple lines of code have unexpected functionality. You never have to ask “how does this work?”, because it’s just plain old Go code. That lack…

> 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.

I don't know about this axis of "magic vs. muggle" we're talking about, but for me the phenomenon we're talking about seems like it can best be described by the ease with which you can find the code that implements specific behavior. Go (and Java) are pretty good at this. Python is OK. Ruby is awful.
Post reply on HN