Live data from Hacker News

Why We Think GoLang Is Ready For Early Stage Startups

jellolabs.com

1–10 of 13 posts

Re: Why We Think GoLang Is Ready For Early Stage Startups

#3
What on earth were you comparing with to come up with go as having stricter code checking?

I'd say early stage startups are probably the least likely place for go to be a good choice - it sacrifices a lot for the sake of performance, which only matters once you've made it. As they say, scaling is a nice problem to have.

(Edit: and like Java it makes other sacrifices in the interests of being maintainable by less talented engineers. Again, that's something big companies need, not early stage startups)

Re: Why We Think GoLang Is Ready For Early Stage Startups

#4
post #2

I would like to know the reasons why they rules out Java and the gangs on the JVM such as Scala, Clojure.

We haven't really ruled out any of the common stack tech choices. They are all good in their own ways, and have their own tradeoffs - and the intention here was not to spark wars about which tool is the best.

I think the choice was much more of a proactive choice - we liked Go, we like the way it fitted us - good for fast iterative development upfront, good for the long term, fun to write code in and with a lot of advantages that come with the fact that it's a language designed today - with a lot of lessons learned from the past.

Re: Why We Think GoLang Is Ready For Early Stage Startups

#5
Did you also consider Java or any JVM-based language?

Modern Java is a lot less verbose than it used to be and it knows a lot of tricks (e.g. akka, play framework, dropwizard, Rx, dependency management, good IDEs, advanced profiling and instrumentation etc.)

Netflix is an excellent example of how you can leverage the JVM to build one of the most advanced system architectures hosted on AWS.

Re: Why We Think GoLang Is Ready For Early Stage Startups

#6
post #3

What on earth were you comparing with to come up with go as having stricter code checking? I'd say early stage startups are probably the least likely place for go to be a good choice - it sacrifices a lot for the sake of performance, which only matters once you've made it. As they say, scaling is a nice problem to have. (Edit: and like Java it makes other sacrifices in the interests of being maintainable by less tale…

What we are discovering is that actually it doesn't sacrifice as much as you'd think - and I think that's the point we are trying to make with our article.

You get both the performance, and you get a very lightweight language - I'd say almost as easy to write as Ruby or Python - with great open source support and growing and with a great community around it.

Re: Why We Think GoLang Is Ready For Early Stage Startups

#7
post #4
post #2

I would like to know the reasons why they rules out Java and the gangs on the JVM such as Scala, Clojure.

We haven't really ruled out any of the common stack tech choices. They are all good in their own ways, and have their own tradeoffs - and the intention here was not to spark wars about which tool is the best. I think the choice was much more of a proactive choice - we liked Go, we like the way it fitted us - good for fast iterative development upfront, good for the long term, fun to write code in and with a lot of ad…

>We haven't really ruled out any of the common stack tech choices. They are all good in their own ways, and have their own tradeoffs - and the intention here was not to spark wars about which tool is the best.

This is way diplomatic. Though for me your article has no beef, the Pros and Cons of Go has been repeated here for so many times. I was expecting to see the v.s. stuffs, why this, why that, your thought process and experiments. Right, those are the beefs I wanted from your article but didn't find.

>I think the choice was much more of a proactive choice - we liked Go, we like the way it fitted us - good for fast iterative development upfront, good for the long term, fun to write code in and with a lot of advantages that come with the fact that it's a language designed today - with a lot of lessons learned from the past.

This is not convincing though. As much as I admire Ken Thompson and Rob Pike, I tend to agree with the perspective that Go to C is like Plan9 to Unix. Of course, I could be wrong and am glad to be corrected by insightful comparisons and opinions.

Re: Why We Think GoLang Is Ready For Early Stage Startups

#9
post #6
post #3

What on earth were you comparing with to come up with go as having stricter code checking? I'd say early stage startups are probably the least likely place for go to be a good choice - it sacrifices a lot for the sake of performance, which only matters once you've made it. As they say, scaling is a nice problem to have. (Edit: and like Java it makes other sacrifices in the interests of being maintainable by less tale…

What we are discovering is that actually it doesn't sacrifice as much as you'd think - and I think that's the point we are trying to make with our article. You get both the performance, and you get a very lightweight language - I'd say almost as easy to write as Ruby or Python - with great open source support and growing and with a great community around it.

Many modern languages in any field are almost as easy to write as Ruby or Python, have great open source support and a great community.

If you use Ruby or Python, you get extreme dynamism that makes things like ActiveRecord or dealing with external semi-structured data very easy (though you pay a performance cost).

If you use OCaml or Scala you get a lot of control over effects, making the code very safe and easy to reason about. And the type systems let you pull out high-level patterns in your code without going crazy, even when those patterns are very abstract, resulting in more concise and maintainable code.

From here go looks like the worst of both worlds.

Re: Why We Think GoLang Is Ready For Early Stage Startups

#10
post #3

What on earth were you comparing with to come up with go as having stricter code checking? I'd say early stage startups are probably the least likely place for go to be a good choice - it sacrifices a lot for the sake of performance, which only matters once you've made it. As they say, scaling is a nice problem to have. (Edit: and like Java it makes other sacrifices in the interests of being maintainable by less tale…

Go has both faster run-time performance and stricter type checking than Ruby, Python, or JS, competitors in the server space.

Go development is fast, because the language is simple and it compiles very quickly.

Once you've made it, you certainly don't want to recode. Although, of course, if you've super-made it, you can just get more hardware. But even the largest web companies can run into the performance bottleneck. Like Google, apparently.

The Go Authors say one of the motives for building Go was the very long compile times of building C++ apps for large-scale web development. One thing they mentioned in particular was the large compile times due to processing and reprocessing of #include files. We know Microsoft ran into the same problem because they put Pre-Compiled Headers (PCH files) into their C family tools. Go has an import facility that prevents the problems of the #include file design.

Go is trying to hit the sweet spot for large-scale development. Go is by no means the only one, of course.

Any of you guys know how well .NET does in compiling big web-scale applications? I don't.

Post reply on HN