Live data from Hacker News

Go at SoundCloud

backstage.soundcloud.com

41–50 of 112 posts

Re: Go at SoundCloud

#41

Earlier quoted context omitted.

You bring up an interesting point about "new." New is fun. Exploration is fun. I think a lot of people will swear by a new language simply because it's not old and probably doesn't suffer many of the same deficiencies they're used to in their "every day," language. This to me is an illusion however. One must remain skeptical and treat new, untested languages with even more scrutiny than an old one. Many of these new…

Is it really helpful to judge a language by its version number? Go is a very conservative language, in that it only uses well known and studied language features, and has been in production at many companies, including Google, Canonical, CloudFlare, etc. Certainly it deserves more faith than any random language designed for the exploration of new paradigms and features and which is only used by its maker?

To paraphrase Big Lebowski: "Well, like, that's just Google's opinion, man."

Of course Go is already in production at Google because the Go team designed it to fit particular pain points that Google was having, so it's going to have the libraries that are needed to solve those problems. The question is whether the current libraries are there to solve your problems, and, as others noted, it's not that cut-and-dried.

Re: Go at SoundCloud

#42
post #32
post #26

Earlier quoted context omitted.

The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed. This requires some flow analysis, but brings real benefit and safety.

The problem is it's no better than C Multiple return values are pretty clearly better than C. The comma-OK or comma-err idiom is verbose, but powerful and unambiguous.

A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception:

http://www.reddit.com/r/programming/comments/w1ig0/things_i_...

Re: Go at SoundCloud

#44

I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?

Opertor overloading is really horrible.

By reading the code "foo + bar" you can't know what is really doing internally.

He is talking about operator (+-*=[]&) overloading. Not method overloading.

Re: Go at SoundCloud

#45

I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?

His point is that, if you aren't familiar with the code, operator overloading can be difficult to read. It gives objects the appearance of being native types, and it is sometimes not entirely clear what the result of the overload might be. What does "dog + cat" equal? In an extreme example, if you are crazy enough, it might make sense to have animal + animal = baby animal. You need to temper that example down to something closer to reality :)

I personally like overloading, but I think it's probably too easy to abuse, and I can see how it would cause problems with a team size larger than 5.

As far as I can see, whenever the Go team encountered a language feature that could possibly be abused, they always deferred to leaving it out. Whether that is good or bad I'm not sure we will know until we have years of experience with it.

Re: Go at SoundCloud

#46

I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?

The argument is roughly that it is, in fact, not very useful, while opening up a vast array of misuses - especially in the domain of being all too clever. What does "+" mean on a list and an object? Add, probably. But what if it's two lists? Union? Or add the second list as the last element to the first? Named functions "add" and "union" aren't any less readable and loads more descriptive.

The only situation you positively need operator overloading is when doing arithmetic, and you should do that using the built in types. This, of course, sucks when the built in types are inadequate, and you e.g. want to use a arbitrary precision library such as BigDecimal in Java.

This, of course, is an opinion, and I'm not shy to admit it's been shaped by being burned by Lift, the Scala web framework which makes heavy use of symbolic function names which makes it incredibly difficult to talk about or search for answers online.

Re: Go at SoundCloud

#47

I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?

The argument is roughly that it is, in fact, not very useful, while opening up a vast array of misuses - especially in the domain of being all too clever. What does "+" mean on a list and an object? Add, probably. But what if it's two lists? Union? Or add the second list as the last element to the first? Named functions "add" and "union" aren't any less readable and loads more descriptive. The only situation you posi…

Of course, Go itself is completely unsearchable, so you always have to search for Golang, which means that thee mut be hundreds of pages that get missed.

Re: Go at SoundCloud

#48
post #37

Earlier quoted context omitted.

It got out of hand, but it's still a rather nice paradigm if you're actually simulating a system or designing a GUI. Teaching it as the One True Paradigm is certainly bad, but it certainly has its uses.

> designing a GUI Not really. HTML/CSS/JavaScript combination is not really OO, but works really really well. In general, I think that any "programming language" for GUI is a fail - we need to develop a declarative approach to GUI (like HTML/CSS, but with more features (e.g. effects) and more emphasis on Application Development (e.g. it's still really hard to create a photoshop-like interface in HTML), less on text p…

Related: http://www.youtube.com/watch?v=4moyKUHApq4

An interesting approach to declarative GUI programming from Adobe.

Re: Go at SoundCloud

#49

Earlier quoted context omitted.

The argument is roughly that it is, in fact, not very useful, while opening up a vast array of misuses - especially in the domain of being all too clever. What does "+" mean on a list and an object? Add, probably. But what if it's two lists? Union? Or add the second list as the last element to the first? Named functions "add" and "union" aren't any less readable and loads more descriptive. The only situation you posi…

Of course, Go itself is completely unsearchable, so you always have to search for Golang, which means that thee mut be hundreds of pages that get missed.

And "C" or "D" are searchable? Or "Java" (island, coffee) or "C#" (musical scale)? Or "Basic" (fundamental)? Or "Python" (snake) or "Ruby" (gemstone)? Or "Lisp" (speech impediment)? Or "Pascal" (French mathematician, SI unit and general given name)? Or "Smalltalk" (informal conversation)? Or "Logo" (emblem)? Or "Lua" (Portuguese word for moon)? ...

Re: Go at SoundCloud

#50

I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?

Operator overloading has nothing to do with OOP.

In go you get polymorphism via interfaces and you can share implementation via embedding. http://golang.org/doc/effective_go.html#embedding

Post reply on HN