The reasons we have for moving our Scala heavy process app to Go are:

1. Much, much smaller memory footprint, both, initial app running and then 
loading the same number of items from our database.
2. During development, compilation time.
3. Version upgrades:
    As long as you vendor your Go dependencies, you are golden (and by this 
point, unless you write libraries, you should be vendoring), Go 1.8 just 
came out, I didn't have to wait for my 5 dependencies to publish a Go 1.8 
compatible version. Every time Scala comes up with a new version, I do have 
to wait for all my deps to be built for the new Scala version (And as a 
library maintainer of a large Scala web framework, have to deal with 
updating our code/publishing/etc)
4. This may or may not be a big point for your architect, depending on 
his/her preference, deploying a Scala app just takes longer than a Go app. 
(jar size with all dependencies vs a Go binary)

That being said, I try to control risk when introducing a new tech at work, 
I hope this won't be your first Go app. I personally wrote several apps on 
the side before we started using Go at work, because I didn't want to run 
into cases where I made s silly mistake and then the rest of the team would 
use that to say Go is terrible, when in fact it was just me making a 
mistake/misusing a feature, etc.

Hope that helps.

Diego



On Saturday, February 18, 2017 at 1:55:37 AM UTC-5, Will Faught wrote:
>
> I want to make the case to a software architect where I work that we 
> should write some fast, high-load servers we need in Go rather than Scala. 
> What pragmatic arguments should I use?
>
> Note that the architect isn't against ever using Go; the question is 
> whether to use Go now, for these servers in particular. Not much detail has 
> been hashed out yet about them, aside from general speed and load 
> requirements.
>
> As a general example of a pragmatic reason one might choose Go over Scala, 
> the architect said Scala would be bad for making a standalone program that 
> checks gRPC health endpoints because the binary would be large and the 
> start-up time would be long.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to