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

221–230 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#221

Post by [deleted] »

nuggien wrote: post #216
kasey_junk wrote: post #136

Earlier quoted context omitted.

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.

[deleted]

Re: 3.5 Years, 500k Lines of Go

#222

Post by [deleted] »

nuggien wrote: post #216
kasey_junk wrote: post #136

Earlier quoted context omitted.

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.

[deleted]

Re: 3.5 Years, 500k Lines of Go

#223

Post by kasey_junk »

tptacek wrote: post #220
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.

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.

This is true except in the case of structural satisfaction for interfaces. You can't trust a rename function in a IDE in go for instance due to this.

And in the case of channel select behavior...and ranges over a channel...and the context object, etc.

My point being "magic" seems to be code for "familiarity with the language and it's idioms". Which I'll grant might be easier in go because of how limiting it is.

Re: 3.5 Years, 500k Lines of Go

#224

Post by copperx »

greenhouse_gas wrote: post #201
oxalorg wrote: post #193

Earlier quoted context omitted.

I completely agree, and it's one of the reasons I've liked Python. From the zen of Python: There should be one-- and preferably only one --obvious way to do it.

This is my problem with modern day Java. Java is an OOP language. OOP languages communicate through message passing. So why do modern UI frameworks use callbacks?

Because, as a Zen master would point out, there is no message.

Re: 3.5 Years, 500k Lines of Go

#225

Post by johnfn »

rpeden wrote: post #157
johnfn wrote: post #38

Earlier quoted context omitted.

I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".

Over time, I've come to notice that once any online forum reaches a certain critical mass of programmers, nearly any mention of a specific programming language will devolve into a flamewar about that language. I find it frustrating, but I also suspect that it's been that case since approximately forever ago. One day I plan to don a flame retardant suit and wade into Usenet archives to see if programmers were as prone…

I think it's the whole bikeshedding thing, where people will jump to talking about the most superficial thing they have an opinion about.

Re: 3.5 Years, 500k Lines of Go

#226

Post by woah »

nemo1618 wrote: post #185
woah wrote: post #173

Earlier quoted context omitted.

I think generics would mostly be useful for container types, like putting methods on slices (like .map) without caring what's inside.

You might be interested in my side project: https://github.com/lukechampine/ply IMO when people say they want generics in Go, they really just want a few functional-style methods and functions on slices (e.g. map, filter, reduce methods, and functions like sort, reverse, repeat). So I wrote a compile-to-Go language that allow you to write "Go code" that also has those things. One of the things I've found, though, is…

Wouldn't

    xs.map((x int) int => x*x)
be simple desugaring without messing with the type system?

Re: 3.5 Years, 500k Lines of Go

#227

Post by pjmlp »

nuggien wrote: post #217
sheepmullet wrote: post #210

Earlier quoted context omitted.

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.

Just like you can make a function do something totally unrelated to how it is called, do what it is actually in the name, wipe out the hard drive, launch missiles, whatever.

Re: 3.5 Years, 500k Lines of Go

#228

Post by stymaar »

greenhouse_gas wrote: post #132

I happened to believe that a language should have one style. You want a functional language? Use it. You want a procedural language? Use it. You want an OOP language? Use it. They're all good, but not in one language. For example, you like FP idioms, and program everything with maps. I like for loops. You have to fix my code one day I'm on vacation. You think that it's ugly, and rewrite it as a map. I get back, bug c…

> You have to fix my code one day I'm on vacation.

> You think that it's ugly, and rewrite it as a map.

Well, if your colleagues do that, their is a social problem in your company, and I'm not sure a langague has anything to do with that. Your colleagues could also rename all your variables at this point…

Re: 3.5 Years, 500k Lines of Go

#229

Post by iopq »

NateDad wrote: post #168
zzzcpan wrote: post #155

Earlier quoted context omitted.

"they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code." Yes, this is a problem with many designs. More importantly they can't easily look up what does an operator do. But this problem can be easily avoided if a set of operators used in a particular scope had to be explicitly specified. For example, if you want "+" to mean a bigint add…

I agree, I wish + wasn't string concatenation either.

One of the few good decisions PHP made is not using + for concatenation.

Re: 3.5 Years, 500k Lines of Go

#230

Post by iopq »

Daishiman wrote: post #190
greenhouse_gas wrote: post #119

Earlier quoted context omitted.

I've got another heresy coming up: Outside of very specific fields, language doesn't matter . I was quite strongly attacked on another thread for implying that WhatsApp is just another CRUD app. The thing was that I wasn't bashing their dev team. They could have done a crazy amazing job, and it helped their company take off, but what was their secret sauce? The ability to have an (almost) free SMS/MMS app which worke…

The problem is that WhatsApp really isn't just another CRUD app and it's very unlikely that you could pull off an engineering feat of that scale with a different technology. It is the exact counterexample of what you say.

It's literally an XMPP server that doesn't connect to other XMPP servers. I downloaded it and I was very disappointed. It literally does nothing else.
Post reply on HN