Nowadays, polyglot approach is the only right path for a software company. When I arrived in Berlin a month ago, I was positively surprised that SoundCloud supports local Clojure or functional programming groups. Keep up with great work!
Go at SoundCloud
11–20 of 112 posts
Re: Go at SoundCloud
#12The way they describe Go as a WYSIWYG language makes me think of functional programming languages (e.g. mostly of elimination of side effects.)
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
I agree. For some reason the whole OOP thing got really out of hands and has been force fed into a whole generation of programmers. Yet there's no real evidence that OOP is the right way to go. And then there was the whole Java deal where the "everything is an object" mantra was taken so far that it hurts. The result is probably the most expensive mistake in the history of computing with machines.
> UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
In 25 years, we will be laughing at the present for sure. I just disagree on what that fad is (functional programming is hardly popular enough to be called a "fad", but it's been bubbling under for 30+ years). I think it is dynamic programming languages like Ruby and Python, which to some degree are great but fall apart quickly. Another candidate is Node.js -style asynchronous programming, which will be laughed at once a mainstream language ships with a proper async model like the IO manager of Haskell or Erlang.
Re: Go at SoundCloud
#13Go also works very well at STARTeurope, powering our event-platform http://startuplive.in/
Developing a high level webframework from scratch just for one website was a bit of a crazy undertaking: https://github.com/ungerik/go-start
(sorry, the documentation needs a big update and a tutorial. Most time was spent on running stuff and shipping features...).
Re: Go at SoundCloud
#14Earlier quoted context omitted.
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
But Go doesn't get rid of OOP, it just fixes it.
Does it? Seems like Go just has somewhat weak structural typing and a poor (by 2012 standards) type system. No parametric polymorphism? Whaaaaaaa
Re: Go at SoundCloud
#15Go also works very well at STARTeurope, powering our event-platform http://startuplive.in/ Developing a high level webframework from scratch just for one website was a bit of a crazy undertaking: https://github.com/ungerik/go-start (sorry, the documentation needs a big update and a tutorial. Most time was spent on running stuff and shipping features...).
Just don't use Go on 32bit systems, the 32bit garbage collector leaks. On 64bit systems everything is rock solid.
Re: Go at SoundCloud
#16The way they describe Go as a WYSIWYG language makes me think of functional programming languages (e.g. mostly of elimination of side effects.)
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
> It took us 25 years to begin to see that the king is naked!
That king is an impostor. http://c2.com/cgi/wiki?AlanKayQuotes
> UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
Only if unwashed masses start doing a half-baked version of FP without really understanding it. This is what happened to OO. It's similar to what happens to musical genres.
Re: Go at SoundCloud
#17The way they describe Go as a WYSIWYG language makes me think of functional programming languages (e.g. mostly of elimination of side effects.)
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
In 25 years, the kids will still be trying to decide which approach is black-and-white "correct", while the experienced will still be using a blend of styles depending on the given problem.
Eliminating side effects sounds brilliant until you start interacting with filesystems or networks. What, you can't memoize those ops or split them across a pmap?
Re: Go at SoundCloud
#18Earlier quoted context omitted.
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
I agree. For some reason the whole OOP thing got really out of hands and has been force fed into a whole generation of programmers. Yet there's no real evidence that OOP is the right way to go. And then there was the whole Java deal where the "everything is an object" mantra was taken so far that it hurts. The result is probably the most expensive mistake in the history of computing with machines. > UPDATE: I have a…
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.
Re: Go at SoundCloud
#19Go also works very well at STARTeurope, powering our event-platform http://startuplive.in/ Developing a high level webframework from scratch just for one website was a bit of a crazy undertaking: https://github.com/ungerik/go-start (sorry, the documentation needs a big update and a tutorial. Most time was spent on running stuff and shipping features...).
Just don't use Go on 32bit systems, the 32bit garbage collector leaks. On 64bit systems everything is rock solid.
Garbage collection is actually a lot easier with 64 bit pointers, since the odds of a random collision between pointers and non-pointer data goes way, way down. And because the ratio of memory in use to total address space goes down.
Re: Go at SoundCloud
#20Earlier quoted context omitted.
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. It took us 25 years to begin to see that the king is naked! UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
In 25 years, the kids will still be trying to decide which approach is black-and-white "correct", while the experienced will still be using a blend of styles depending on the given problem. Eliminating side effects sounds brilliant until you start interacting with filesystems or networks. What, you can't memoize those ops or split them across a pmap?
My favorite illustration of the reason why OO and FP each have their strengths is the expression problem: http://en.wikipedia.org/wiki/Expression_problem
Briefly, functional programming is good at one use case (adding new operations over the data type) and weak at one use case (adding new data type variants), while OO is the opposite (adding new data type variants is easy, while adding new operations is not). You have to choose between OO and FP based on which notion of extensibility is more important to you for the problem at hand (unless you use the relatively exotic solutions of multimethods or the generics trick that Wadler originally proposed).
My takeaway is that OO and FP both have their time and place, and the pragmatic programmer will learn when to use one or the other instead of choosing one camp and bashing the other side.