14 ms·

Why Tech Startups Should Look at Go

50 points by ardan-bkennedy 12y ago

onion2k 12y ago
AWS is cheap enough that "throw more hardware at the problem" is a viable option for most startups. So long as you're not being completely stupid with the way you've coded the first version, pretty much any language is going to work, and the cost of people who can code well in more esoteric languages that might be better suited to the problem domain are going to be increasingly expensive. Obviously there is a time to rebuild with technologies that scale better than what you started out with, but I doubt all that many startups ever actually get to that point.
- bad_user 12y ago
  I don't think you've ever calculated just how much that cost is. Lets say that you have a web service that is serving 30,000 requests per second, with a 1 Kb request size and a 4 Kb response size and you're setting up an elastic load-balancer setup that on average keeps 300 c3.xlarge instances open. Do the math and you'll find that the cost on AWS, considering the instances used and the bandwidth, is over $80,000 per month. And that's a conservative example, since by my calculations that's about $1,000,000 per year and I know companies paying much more than that. Don't know what startups you're thinking about, but from where I'm standing, for startups that's a recipe for burning cash.
  - onion2k 12y ago
    30,000 requests per second is 2,592,000,000 per day... That's quite a lot. Obviously we're not talking page views (because that'd be crazy successful and well beyond 'startup' territory), so we're presumably in the domain of data logging, analytics, social networking etc. Sure, AWS might not be appropriate for those. But then, the level of traffic you're talking about represents maybe 0.1% of startups. People doing "a CRUD app for a niche", which is most SaaS startups TBH, could run their software on 1 AWS medium instance for the first year or two quite happily.
    - bad_user 12y ago
      You're right, we aren't talking about page views or CRUD, but it can happen in a B2B application. I ended up working for a startup like that, so this was a real anecdotal example. Our stuff was built to run on the JVM and we managed to get away with a variable number of instances between 15 and 30 (at the time we used c1.medium, which are now deprecated) - AWS's ELB is great in such a scenario as it can be configured to bring up new instances in case of traffic spikes, or kill them in case they were unused. So for us, AWS was saving us money, however that's because we were very efficient. My opinion is that if you're expecting your startup to grow soon (and I'm not talking about wishful thinking, but about requirements that have to happen for survival - i.e. you either get the desired contracts or you don't), then you have to prepare for it.
- shanemhansen 12y ago
  AWS is not cheap. It's a rather expensive way to rent hardware. It's only "cheap" if you are using some aspect of elastic computing to use 100 machines for a couple hours. I've worked with several startups who are paying 6 figure a month AWS bills. At that point it's really not a bad idea to take all those python or ruby data processing jobs and convert them to go. I have seen costs reduced by an order of magnitude this way. The key point here is that some startups need a pretty decent scale before they have a MVP. How many useful search results could google have provided if they weren't crawling most of the web from day 1? Some social media or analytics startups need to process twitter's firehose feed, even when they don't have many customers.
MCRed 12y ago
While go has some nice features-- standalone executables and fast execution are two. I don't really see a compelling reason to switch to it from Elixir/Erlang. Biggest downside seems there's no real easy way to handle errors being returned from function calls. Easier deployment would be good, but once you solve it for elixir it's not a big issue. On the other hand Erlang is very well tested and established and pretty complete-- though go's libraries and open source support is growing by leaps and bounds. So really, it's that error issue. Oh, and pipe. I really love elixir's pipe ( |> ) operator.
- ihsw 12y ago
  Can you be more specific in how handling errors is difficult? I've found it to be generally forced and explicit, which, while sometimes unpleasant, is quite comforting. The alternative seems to be exceptions flying unhinged.
  - masklinn 12y ago
    > The alternative seems to be exceptions flying unhinged. … The commenter you replied to explicitly mentioned Erlang and Elixir, you may want to have an idea about where they're coming from before replying to their comment.
    - ihsw 12y ago
      Yeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.
  - MCRed 12y ago
    Let it fail, let it fail, let it fail! (to the tune of "let it snow, let it snow, let it snow!) Supervisor Trees! Exceptions are not much better, but checking the return every time is no fun. And if you crash the whole thing crashes. In erlang you can have a once in 1x10^9 error and not even catch it, but only that process crashes (and your system keeps running) and that process gets relaunched. With go, it's the whole program that will crash, necessitating checking every return value. I say this, though I might be missing some error handling system in go that I'm simply not aware of.
nine_k 12y ago
tl;dr: * Stratups don't have time to rewrite the prototype the right way, and then hit the performance wall. * A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node.
- voidlogic 12y ago
  Some thoughts on those points. >Startups don't have time to rewrite the prototype the right way, and then hit the performance wall. I would guess that for experienced C/C++ programmers (and probably C#/Java) Go isn't going to be slower to build in than Python/Node etc. I actually build things the fastest right off the bad in Go... I've ported node.js applications to Go, and let me tell you it was not fun. Even if the first throw away prototype was in Go, it would have made the rewrite much easier. >A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node. Considering Go was built to compete with Python/C/C++/Java at Google I would hope so. I think a key metric that often is left out is maintainability. I think Go's very straight forward code (which some people call boring) is an asset here.
jonpress 12y ago
Gophers love to quote TJ Holowaychuk to justify choosing Go over Node.js. In my eyes, TJ is a traitor - If he preferred Go, that's fine - He could just go ahead and use it as he likes, but he wrote a post completely debasing Node.js without pointing to any real, concrete issue. I bet he is still using Node.js from time to time - The 'Goodbye' article is obviously just a stunt. He probably cashed out! I read somewhere that he got a decent sum for his Express framework. I would be interested to know who else is behind this.
- perturbation 12y ago
  Speaking only for myself, I've found the following to be broadly true with Node.js and Go: If I'm building a strictly server-side app using Express, it's a joy to use Node.js (especially for a prototype) - everything more or less works, and the NPM ecosystem is rich and broad. Very easy way of getting a RESTful JSON API up-and-running from FooDB. If I'm building a client (web scraper, getting stuff out of an API to load into R, etc.) then I really quickly run into "Too Much Concurrency" TM with Node. I quickly find myself building something with Go (or Ruby) to do the following: - Limited Number of workers - Automatically re-try request N number of times if fails, depending on response code - Log all successes/failures - Throttle total # of requests/second based on site-specific rate limiting To make the above work in Node, I have to use caolan's async + Q promises + other libraries (or write in Icedcoffeescript, which I like but is very weakly typed and has inferior tooling) and find myself refactoring most of the small script just to fit into the async libraries. With Go, I can use mutexes or simple channels to control throttling, and do whatever I want with errors. There's a lot of boilerplate to get the above up-and-running robustly for Node, or at least that's been my impression the last few times that I've used it. Node has solutions for advanced concurrency (Generators, promises, CSP libraries), but why reinvent the wheel when Go has that out of the box?
nkozyra 12y ago
Tech startups who hit this phase (or "wall," as it's described here), should look at all options. Even if Go is the best technical option, it may not be the best business decision. That's an unfortunate reality for startups - if you can't bring in the staff you want / need, the best tool for the job might not be the right one. This ends up being another pro for the distributed microservice model, allowing some experimentation and internal learning in new languages without impacting an entire product.
- nine_k 12y ago
  One upside is that learning Go is easy for a an experienced developer.
- voidlogic 12y ago
  > Even if Go is the best technical option, it may not be the best business decision Why might Go not be the best business option? I see technical case for or against Go as very much religious and shaped by personal preference. But what could be a business reason not to use Go for a new startup that is independent of the technical side?
  - nkozyra 12y ago
    I thought I hinted that it was more a matter of available resources. The Go community is growing but if you're a lean startup looking for developers to get moving quickly, the pool for Python, PHP, Node & Ruby/Rails dwarfs that of Golang. And to the other comment, yes, it's easy (and generally surprisingly pleasant) for experienced developers to pick up, but that's an investment.
    - NateDad 12y ago
      At Canonical, 2/3 of our developers on Juju hadn't written Go code before joining the team. They get up to speed in the first week, or often, even before their first day through their own efforts. The language is incredibly easy to pick up. It's basically zero cost if you have at least a few devs with Go experience to answer the occasional question.
amencarini 12y ago
The Iron.io blogpost was what got me looking into Go. As a Rubyist it was quite eye-opening!
- codygman 12y ago
  You'd probably enjoy Haskell more than Go as a Rubyist imo. Most Rubyist I've known seem to really like Haskell.
ryeguy 12y ago
Essentially all of the quoted usecases switched from a slow dynamically typed language to Go. Of course that's an improvement. But I still don't see why you would choose Go over Java (or Scala) for serious backend development. Java has more libraries, is faster, has generics (for the love of god), has better IDE support, and has a larger hiring pool. In summary, the ecosystem is more mature. Java's checked exceptions are less painful then Go's C-style error handling. They could have gone with something sane like Rust/Haskell style error handling (using the type system), but they instead regressed to return value checking. The complaints about Java's overwhelming verbosity are mostly dated both on the language-level and the ecosystem-level. Java 8 has lambdas, streams, and more. Spring Boot and Dropwizard are 2 modern, lightweight frameworks that do away with the XML configuration nonsense. I'm actually genuinely asking why anyone would choose Go over Java and not trying to start a flame war. An API I'm working on is due for a rewrite and it's currently written in PHP. I'd like to give Go a chance but it just seems like a poor choice compared to Java.
- MCRed 12y ago
  I'm much more productive (in terms of bug-free-functionality-per-hour) in Go than I am in Java (and even more so in Elixir than go). It seems the value of those 3rd party libraries are not as much for me as for you and others. I guess cause the essential stuff is covered for Elixir and most other languages.
  - tljr 12y ago
    I like coffee and long walks.
    - deleted 12y ago
      [deleted]
    - rdtsc 12y ago
      Great point. If you switched to those language you might have more time to go for coffee and take long walks, because your system have a higher chance to manage errors and crashes and you don't have to rush to the office right away or at night to fix issue.
mrcwinn 12y ago
Here's my take on this as someone who loves both Go and PHP (yeah, I know!). I agree that startups can get entrenched in their legacy code, but I also think there is a false choice here: 1. Write with a system language from the start. Yikes! 2. Do a total rewrite of your application later when you hit scale issues. Yikes! In my opinion, though, Go is not well-suited (today) for rapid prototyping or web application development, even with some of the frameworks. This shouldn't be a surprise. Go is a systems language. I think languages like PHP, Ruby, and the lot are much better suited early stage startups. When you hit problems of scale, it's very straight-forward to isolate parts of your application that do not scale well and translate those components to Go. Introducing Go for only the components that require high availability and guarantee a level of performance / memory safety as an iteration to your original application code is probably a much saner choice.
ChikkaChiChi 12y ago
If your team has a common skillset that can be used to rapidly and efficiently deliver a thing and you don't yet have the same confidence in your collective Go abilities: do not use Go. Otherwise, feel free. Not sure why this is such a huge point of contention.
jonpress 12y ago
Node.js is way better than Go! It's more expressive, more flexible and more portable. ... Thanks for the downvotes. Well worth the bad karma :)
emehrkay 12y ago
I watched the Rob Pike Concurrency is Not Parallelism video (http://vimeo.com/49718712 http://vimeo.com/49718712) a few days ago and thought that "maybe I should be using Go instead of Python." Then I thought about all of the work that would have to be redone, all of the learning that I'd have to do, all of the retooling, all of the etc., just to get back to where I'm at now. If I were starting again Id probably start with Go, probably.
- NateDad 12y ago
  2/3rds of our devs working on juju hadn't written a line of Go before they were hired. Getting up to speed on Go is very far (like a week to get productive). Many of them have very Python heavy backgrounds. Just dive in, it's easy.
orenbarzilai 12y ago
at the end of the day, on the first days of (most) startups you focus on showing results as fast as you can. Prototyping languages (Pyhon / Ruby etc) are the right choice. Nice stories about how iron.io reduced 30 ruby servers to 2 go servers became relevant only after they proven good market fit and working growth engine. So GO? maybe yes but probably only when the prototyping languages, can't carry weight.
- falcolas 12y ago
  I have found Go to be high level enough to make prototyping very straightforward.
  - orenbarzilai 12y ago
    Define "high level enough" python / ruby are much faster...
    - falcolas 12y ago
      Exactly what I said. Just like Python/Ruby can be "fast enough" to do many things, Go is "high level enough" that I don't have to spend too much time thinking about the lower level details. The few seconds of difference is small enough that it effectively does not matter. For example, I don't have to worry about maps (dicts, hashes, etc); they're in place, but require one additional statement before they use them. I don't have to worry about array lengths; I can just use append(). I don't have to worry about finding a third party library to do network requests, it's part of the standard library (and doesn't require too many convolutions to use). I do have to think a bit more about pointers when writing function signatures in Go than in Python or Ruby (not that those two languages really free me from that concern: some structures when modified in a function modify the underlying data from the callee as well).
maxer 12y ago
its hard enough to hire decent developers never mind decent go developers
copsarebastards 12y ago
It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does, you're going to see a big benefit. But there are lots of languages that address the problems mentioned by those startups, and I think that Go is possibly the worst of the options. It's telling that none of the startups in question switched out of a language which provides good compile-time type and thread-safety guarantees: 1. iron.io: ruby -> go 2. SendGrid: perl -> python -> go 3. TJ Holowaychuck: node.js -> go Go would have a reasonable compile-time type system, except that without generics you end up having to cast a lot, which renders your compile-time type system almost irrelevant. It's also telling that none of the authors mentioned experience with functional programming. Go supports some functional programming, but it doesn't seem to be a very big part of the language. The only one who mentions that they even considered any functional languages is the iron.io guy, and it seems like a big part of his choice was not technical: he mentions that he had to sell the idea of Go to his team by mentioning that Google supports it. A language that was a more serious paradigm shift (OO -> functional) would have been an even harder sell. (EDIT: Okay, the SendGrid guy did mention considering Scala.) The fact is, there are a bunch of languages that would have solved their problems, in addition to a few they didn't know they had. Julia has coroutines similar to Go, but is much more expressive, Rust has a more traditional threading model but a type system and focus on immutability that provides better safety guarantees. There are other choices, but those two stand out as the major ones that could have solved their problems better than go.
- rogpeppe1 12y ago
  > Go would have a reasonable compile-time type system, except that without > generics you end up having to cast a lot, which renders your compile-time > type system almost irrelevant. In my experience of Go, this is not actually true. For example, in the latest project I've been working on, there are 8487 lines of non-test code. In that code, there are a total of 16 dynamic casts, more than half of which are checked (mostly checking for particular error types). There are a total of 4 occurrences which might possibly be amenable to generics. The type system is totally relevant, and checks 99.9% of our code.
  - 12y ago

AWS is cheap enough that "throw more hardware at the problem" is a viable option for most startups. So long as you're not being completely stupid with the way you've coded the first version, pretty much any language is going to work, and the cost of people who can code well in more esoteric languages that might be better suited to the problem domain are going to be increasingly expensive. Obviously there is a time to rebuild with technologies that scale better than what you started out with, but I doubt all that many startups ever actually get to that point.

bad_user 12y ago
I don't think you've ever calculated just how much that cost is. Lets say that you have a web service that is serving 30,000 requests per second, with a 1 Kb request size and a 4 Kb response size and you're setting up an elastic load-balancer setup that on average keeps 300 c3.xlarge instances open. Do the math and you'll find that the cost on AWS, considering the instances used and the bandwidth, is over $80,000 per month. And that's a conservative example, since by my calculations that's about $1,000,000 per year and I know companies paying much more than that. Don't know what startups you're thinking about, but from where I'm standing, for startups that's a recipe for burning cash.
- onion2k 12y ago
  30,000 requests per second is 2,592,000,000 per day... That's quite a lot. Obviously we're not talking page views (because that'd be crazy successful and well beyond 'startup' territory), so we're presumably in the domain of data logging, analytics, social networking etc. Sure, AWS might not be appropriate for those. But then, the level of traffic you're talking about represents maybe 0.1% of startups. People doing "a CRUD app for a niche", which is most SaaS startups TBH, could run their software on 1 AWS medium instance for the first year or two quite happily.
  - bad_user 12y ago
    You're right, we aren't talking about page views or CRUD, but it can happen in a B2B application. I ended up working for a startup like that, so this was a real anecdotal example. Our stuff was built to run on the JVM and we managed to get away with a variable number of instances between 15 and 30 (at the time we used c1.medium, which are now deprecated) - AWS's ELB is great in such a scenario as it can be configured to bring up new instances in case of traffic spikes, or kill them in case they were unused. So for us, AWS was saving us money, however that's because we were very efficient. My opinion is that if you're expecting your startup to grow soon (and I'm not talking about wishful thinking, but about requirements that have to happen for survival - i.e. you either get the desired contracts or you don't), then you have to prepare for it.
shanemhansen 12y ago
AWS is not cheap. It's a rather expensive way to rent hardware. It's only "cheap" if you are using some aspect of elastic computing to use 100 machines for a couple hours. I've worked with several startups who are paying 6 figure a month AWS bills. At that point it's really not a bad idea to take all those python or ruby data processing jobs and convert them to go. I have seen costs reduced by an order of magnitude this way. The key point here is that some startups need a pretty decent scale before they have a MVP. How many useful search results could google have provided if they weren't crawling most of the web from day 1? Some social media or analytics startups need to process twitter's firehose feed, even when they don't have many customers.

MCRed 12y ago

While go has some nice features-- standalone executables and fast execution are two. I don't really see a compelling reason to switch to it from Elixir/Erlang. Biggest downside seems there's no real easy way to handle errors being returned from function calls. Easier deployment would be good, but once you solve it for elixir it's not a big issue. On the other hand Erlang is very well tested and established and pretty complete-- though go's libraries and open source support is growing by leaps and bounds. So really, it's that error issue. Oh, and pipe. I really love elixir's pipe ( |> ) operator.

ihsw 12y ago
Can you be more specific in how handling errors is difficult? I've found it to be generally forced and explicit, which, while sometimes unpleasant, is quite comforting. The alternative seems to be exceptions flying unhinged.
- masklinn 12y ago
  > The alternative seems to be exceptions flying unhinged. … The commenter you replied to explicitly mentioned Erlang and Elixir, you may want to have an idea about where they're coming from before replying to their comment.
  - ihsw 12y ago
    Yeah, that's why I said seems. I'm not going to lie, I know next to nothing about Erlang and Elixir.
- MCRed 12y ago
  Let it fail, let it fail, let it fail! (to the tune of "let it snow, let it snow, let it snow!) Supervisor Trees! Exceptions are not much better, but checking the return every time is no fun. And if you crash the whole thing crashes. In erlang you can have a once in 1x10^9 error and not even catch it, but only that process crashes (and your system keeps running) and that process gets relaunched. With go, it's the whole program that will crash, necessitating checking every return value. I say this, though I might be missing some error handling system in go that I'm simply not aware of.

nine_k 12y ago

tl;dr: * Stratups don't have time to rewrite the prototype the right way, and then hit the performance wall. * A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node.

voidlogic 12y ago
Some thoughts on those points. >Startups don't have time to rewrite the prototype the right way, and then hit the performance wall. I would guess that for experienced C/C++ programmers (and probably C#/Java) Go isn't going to be slower to build in than Python/Node etc. I actually build things the fastest right off the bad in Go... I've ported node.js applications to Go, and let me tell you it was not fun. Even if the first throw away prototype was in Go, it would have made the rewrite much easier. >A few startups explain how Go is faster and more reliable than Ruby/Rails, Python, and JS/Node. Considering Go was built to compete with Python/C/C++/Java at Google I would hope so. I think a key metric that often is left out is maintainability. I think Go's very straight forward code (which some people call boring) is an asset here.

jonpress 12y ago

Gophers love to quote TJ Holowaychuk to justify choosing Go over Node.js. In my eyes, TJ is a traitor - If he preferred Go, that's fine - He could just go ahead and use it as he likes, but he wrote a post completely debasing Node.js without pointing to any real, concrete issue. I bet he is still using Node.js from time to time - The 'Goodbye' article is obviously just a stunt. He probably cashed out! I read somewhere that he got a decent sum for his Express framework. I would be interested to know who else is behind this.

perturbation 12y ago
Speaking only for myself, I've found the following to be broadly true with Node.js and Go: If I'm building a strictly server-side app using Express, it's a joy to use Node.js (especially for a prototype) - everything more or less works, and the NPM ecosystem is rich and broad. Very easy way of getting a RESTful JSON API up-and-running from FooDB. If I'm building a client (web scraper, getting stuff out of an API to load into R, etc.) then I really quickly run into "Too Much Concurrency" TM with Node. I quickly find myself building something with Go (or Ruby) to do the following: - Limited Number of workers - Automatically re-try request N number of times if fails, depending on response code - Log all successes/failures - Throttle total # of requests/second based on site-specific rate limiting To make the above work in Node, I have to use caolan's async + Q promises + other libraries (or write in Icedcoffeescript, which I like but is very weakly typed and has inferior tooling) and find myself refactoring most of the small script just to fit into the async libraries. With Go, I can use mutexes or simple channels to control throttling, and do whatever I want with errors. There's a lot of boilerplate to get the above up-and-running robustly for Node, or at least that's been my impression the last few times that I've used it. Node has solutions for advanced concurrency (Generators, promises, CSP libraries), but why reinvent the wheel when Go has that out of the box?

nkozyra 12y ago

Tech startups who hit this phase (or "wall," as it's described here), should look at all options. Even if Go is the best technical option, it may not be the best business decision. That's an unfortunate reality for startups - if you can't bring in the staff you want / need, the best tool for the job might not be the right one. This ends up being another pro for the distributed microservice model, allowing some experimentation and internal learning in new languages without impacting an entire product.

nine_k 12y ago
One upside is that learning Go is easy for a an experienced developer.
voidlogic 12y ago
> Even if Go is the best technical option, it may not be the best business decision Why might Go not be the best business option? I see technical case for or against Go as very much religious and shaped by personal preference. But what could be a business reason not to use Go for a new startup that is independent of the technical side?
- nkozyra 12y ago
  I thought I hinted that it was more a matter of available resources. The Go community is growing but if you're a lean startup looking for developers to get moving quickly, the pool for Python, PHP, Node & Ruby/Rails dwarfs that of Golang. And to the other comment, yes, it's easy (and generally surprisingly pleasant) for experienced developers to pick up, but that's an investment.
  - NateDad 12y ago
    At Canonical, 2/3 of our developers on Juju hadn't written Go code before joining the team. They get up to speed in the first week, or often, even before their first day through their own efforts. The language is incredibly easy to pick up. It's basically zero cost if you have at least a few devs with Go experience to answer the occasional question.

amencarini 12y ago

The Iron.io blogpost was what got me looking into Go. As a Rubyist it was quite eye-opening!

codygman 12y ago
You'd probably enjoy Haskell more than Go as a Rubyist imo. Most Rubyist I've known seem to really like Haskell.

ryeguy 12y ago

Essentially all of the quoted usecases switched from a slow dynamically typed language to Go. Of course that's an improvement. But I still don't see why you would choose Go over Java (or Scala) for serious backend development. Java has more libraries, is faster, has generics (for the love of god), has better IDE support, and has a larger hiring pool. In summary, the ecosystem is more mature. Java's checked exceptions are less painful then Go's C-style error handling. They could have gone with something sane like Rust/Haskell style error handling (using the type system), but they instead regressed to return value checking. The complaints about Java's overwhelming verbosity are mostly dated both on the language-level and the ecosystem-level. Java 8 has lambdas, streams, and more. Spring Boot and Dropwizard are 2 modern, lightweight frameworks that do away with the XML configuration nonsense. I'm actually genuinely asking why anyone would choose Go over Java and not trying to start a flame war. An API I'm working on is due for a rewrite and it's currently written in PHP. I'd like to give Go a chance but it just seems like a poor choice compared to Java.

MCRed 12y ago
I'm much more productive (in terms of bug-free-functionality-per-hour) in Go than I am in Java (and even more so in Elixir than go). It seems the value of those 3rd party libraries are not as much for me as for you and others. I guess cause the essential stuff is covered for Elixir and most other languages.
- tljr 12y ago
  I like coffee and long walks.
  - deleted 12y ago
    [deleted]
  - rdtsc 12y ago
    Great point. If you switched to those language you might have more time to go for coffee and take long walks, because your system have a higher chance to manage errors and crashes and you don't have to rush to the office right away or at night to fix issue.

mrcwinn 12y ago

Here's my take on this as someone who loves both Go and PHP (yeah, I know!). I agree that startups can get entrenched in their legacy code, but I also think there is a false choice here: 1. Write with a system language from the start. Yikes! 2. Do a total rewrite of your application later when you hit scale issues. Yikes! In my opinion, though, Go is not well-suited (today) for rapid prototyping or web application development, even with some of the frameworks. This shouldn't be a surprise. Go is a systems language. I think languages like PHP, Ruby, and the lot are much better suited early stage startups. When you hit problems of scale, it's very straight-forward to isolate parts of your application that do not scale well and translate those components to Go. Introducing Go for only the components that require high availability and guarantee a level of performance / memory safety as an iteration to your original application code is probably a much saner choice.

ChikkaChiChi 12y ago

If your team has a common skillset that can be used to rapidly and efficiently deliver a thing and you don't yet have the same confidence in your collective Go abilities: do not use Go. Otherwise, feel free. Not sure why this is such a huge point of contention.

jonpress 12y ago

Node.js is way better than Go! It's more expressive, more flexible and more portable. ... Thanks for the downvotes. Well worth the bad karma :)

emehrkay 12y ago

I watched the Rob Pike Concurrency is Not Parallelism video (http://vimeo.com/49718712 http://vimeo.com/49718712) a few days ago and thought that "maybe I should be using Go instead of Python." Then I thought about all of the work that would have to be redone, all of the learning that I'd have to do, all of the retooling, all of the etc., just to get back to where I'm at now. If I were starting again Id probably start with Go, probably.

NateDad 12y ago
2/3rds of our devs working on juju hadn't written a line of Go before they were hired. Getting up to speed on Go is very far (like a week to get productive). Many of them have very Python heavy backgrounds. Just dive in, it's easy.

orenbarzilai 12y ago

at the end of the day, on the first days of (most) startups you focus on showing results as fast as you can. Prototyping languages (Pyhon / Ruby etc) are the right choice. Nice stories about how iron.io reduced 30 ruby servers to 2 go servers became relevant only after they proven good market fit and working growth engine. So GO? maybe yes but probably only when the prototyping languages, can't carry weight.

falcolas 12y ago
I have found Go to be high level enough to make prototyping very straightforward.
- orenbarzilai 12y ago
  Define "high level enough" python / ruby are much faster...
  - falcolas 12y ago
    Exactly what I said. Just like Python/Ruby can be "fast enough" to do many things, Go is "high level enough" that I don't have to spend too much time thinking about the lower level details. The few seconds of difference is small enough that it effectively does not matter. For example, I don't have to worry about maps (dicts, hashes, etc); they're in place, but require one additional statement before they use them. I don't have to worry about array lengths; I can just use append(). I don't have to worry about finding a third party library to do network requests, it's part of the standard library (and doesn't require too many convolutions to use). I do have to think a bit more about pointers when writing function signatures in Go than in Python or Ruby (not that those two languages really free me from that concern: some structures when modified in a function modify the underlying data from the callee as well).

maxer 12y ago

its hard enough to hire decent developers never mind decent go developers

copsarebastards 12y ago

It's not at all surprising that those startups solved their problems with Go: if you switch from a language that doesn't address your problems to one that does, you're going to see a big benefit. But there are lots of languages that address the problems mentioned by those startups, and I think that Go is possibly the worst of the options. It's telling that none of the startups in question switched out of a language which provides good compile-time type and thread-safety guarantees: 1. iron.io: ruby -> go 2. SendGrid: perl -> python -> go 3. TJ Holowaychuck: node.js -> go Go would have a reasonable compile-time type system, except that without generics you end up having to cast a lot, which renders your compile-time type system almost irrelevant. It's also telling that none of the authors mentioned experience with functional programming. Go supports some functional programming, but it doesn't seem to be a very big part of the language. The only one who mentions that they even considered any functional languages is the iron.io guy, and it seems like a big part of his choice was not technical: he mentions that he had to sell the idea of Go to his team by mentioning that Google supports it. A language that was a more serious paradigm shift (OO -> functional) would have been an even harder sell. (EDIT: Okay, the SendGrid guy did mention considering Scala.) The fact is, there are a bunch of languages that would have solved their problems, in addition to a few they didn't know they had. Julia has coroutines similar to Go, but is much more expressive, Rust has a more traditional threading model but a type system and focus on immutability that provides better safety guarantees. There are other choices, but those two stand out as the major ones that could have solved their problems better than go.

rogpeppe1 12y ago
> Go would have a reasonable compile-time type system, except that without > generics you end up having to cast a lot, which renders your compile-time > type system almost irrelevant. In my experience of Go, this is not actually true. For example, in the latest project I've been working on, there are 8487 lines of non-test code. In that code, there are a total of 16 dynamic casts, more than half of which are checked (mostly checking for particular error types). There are a total of 4 occurrences which might possibly be amenable to generics. The type system is totally relevant, and checks 99.9% of our code.
- 12y ago