Why Tech Startups Should Look at Go

Post by functional_test » Thu, Jan 15, 2015, 4:55 PM UTC

pjmlp wrote: post #56

functional_test wrote: post #53

Earlier quoted context omitted.

Java actually doesn't have generics. It has syntactic sugar for generics, but they are so horribly broken they can't be fixed. For example, because the generics are just sugar for casts, you can't specialize them. Because you can't specialize them, you have to put behavior in the "wrong place". Take for example a hash map from Double -> T. Because IEEE floats don't actually form an equivalence class (NaN != NaN), the…

It won't be longer true in Java 9, latest Java 10.

Post by onion2k » Thu, Jan 15, 2015, 5:07 PM UTC

bad_user wrote: post #77

onion2k wrote: post #43

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…

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…

Post by orenbarzilai » Thu, Jan 15, 2015, 5:24 PM UTC

falcolas wrote: post #67

orenbarzilai wrote: post #39

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.

I have found Go to be high level enough to make prototyping very straightforward.

Post by shanemhansen » Thu, Jan 15, 2015, 5:41 PM UTC

ryeguy wrote: post #19

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…

    if a, err := f(); err == nil {
        // do something with a
    } else {
        // do something with err
    }
 

    match f() {
        Ok(a) => { // do something with a }
        Err(err) => { // do something with err }
    }

Post by rdtsc » Thu, Jan 15, 2015, 5:51 PM UTC

falcolas wrote: post #88

rdtsc wrote: post #68

Earlier quoted context omitted.

> Go's panic() acts similarly to what you're expecting out of Erlang. You still have to call it for other libraries. Go uses a shared heap. So even though one go-routine panics, you can't safely assume the state of your system is still predictable. If it is not predictable you can't necessarily safely restart that go-routine. Without Erlang/Elixir I would actually do it with OS processes / containers at a higher leve…

To be fair, if you're modifying the heap from a goroutine, you're "doing it wrong". Go provides channels, which work quite well at reducing the need to mutate the global state. I use such a pattern quite frequently (the http.Server), and have never had a problem with heap corruption due to a handler goroutine panicing.