Go at SoundCloud
backstage.soundcloud.com
Go at SoundCloud
1–10 of 112 posts
Re: Go at SoundCloud
#2Re: Go at SoundCloud
#3Re: Go at SoundCloud
#4The way they describe Go as a WYSIWYG language makes me think of functional programming languages (e.g. mostly of elimination of side effects.)
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.
Re: Go at SoundCloud
#5The 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.
Re: Go at SoundCloud
#6I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
Re: Go at SoundCloud
#7We've just started using Go as well. It smokes our Python app in terms of speed, and is fun to use (maybe just because it's new?). I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
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 languages will make extraordinary claims. Discovering the evidence to support these claims is often left as an exercise to the programmer.
That being said, new has a lot of advantages. It's free to try to break away from past paradigms that perhaps limited programmers. Stability can always come later once the core ideas have been fleshed out. And it's always fun to work on fresh ideas rather than refining the same old ones that we're plagued with.
Personally I wouldn't use a language and compiler that only just reached 1.0 this year in a production system. If I was really interested in Go I'd certainly hack with it and perhaps on it, but I wouldn't trust it to be reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over brilliance when it comes to building systems that are dependable and robust.
Re: Go at SoundCloud
#8We've just started using Go as well. It smokes our Python app in terms of speed, and is fun to use (maybe just because it's new?). I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
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…
With Go 1.0 there is an even greater focus on stability: http://golang.org/doc/go1compat.html
Go is also quite different from most 'new' languages, many people find it to be the most fun language they have used in a long time (even after using many other new languages).
This might be in part because one of the things that makes Go special (and my favorite "feature") is not just the features it has, but all the stuff it doesn't have.
Go is simple and doesn't get on the way and lets you focus on the problem, other "new" languages are often described as "powerful", but much of the work involves using their "features", when Go is more often described as productive, the focus is not in the language and its features but on the problem you are trying to solve and the language gets out of the way.
Re: Go at SoundCloud
#9We've just started using Go as well. It smokes our Python app in terms of speed, and is fun to use (maybe just because it's new?). I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
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…
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?
Re: Go at SoundCloud
#10Earlier 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?
Personally, I'm not as worried about reliability as I am roadblocks. Say, for instance, we spend a month moving our framework over to Go. Then we find a problem that is yet unsolved. Either we solve it ourselves at an unknown cost or we have to just ... wait.. until another group solves it while we make payroll in other ways.
I'm lacking any real evidence here, maybe Go doesn't have a library for our Message Queue (not true, just an example). Now we aren't just porting, we're writing a pooling message queue interface that is beyond our pay grade in the language.