On Saturday, February 18, 2017 at 10:29:03 PM UTC-5, Will Faught wrote: > > Definitely not my first rodeo. :) Been using Go professionally for a > couple years. I've done a lot of Java stuff in the past, and I suspect > Scala/JVM work will be as burdensome. >
Great! hope you and your team get to use Go on this next project. > On Sat, Feb 18, 2017 at 1:30 PM Diego Medina <fmpw...@gmail.com > <javascript:>> wrote: > >> 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 a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/Fg1I34HrtqU/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
