Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

Post reply on HN
Print view View original

431–440 of 449 posts

Re: Go + Services = One Goliath Project

#431

Post by apta »

Thaxll wrote: post #409
apta wrote: post #380

Earlier quoted context omitted.

> real world benchmark Highly debatable. Even then, you see that golang ranks in the 102nd place for the plaintext benchmark, almost 6x slower than Netty, which is very established in the JVM world. Same with the JSON benchmark, golang is in the 126th place, ~3.5x slower than Netty and Vertx. > but Go usually use between 3 and 10x less memory. The JVM by default will use whatever memory is assigned to it. This makes…

You didn't read the benchmark properly, plaintext benchmark it's 6th.

The first golang result in the plaintext benchmark ranks 8th (atreugo-prefork), which is incidentally immediately followed by firenio-http-lite, a Java library.

My point still stands, this is a third party library that is not commonly used, and depends on another third party library, fasthttp, which itself comes with caveats from the its author.

Re: Go + Services = One Goliath Project

#432

Post by apta »

hu3 wrote: post #411
apta wrote: post #377

Earlier quoted context omitted.

Java and C# provide the benefits you mentioned, while being more expressive languages and having better runtimes compared to golang.

Hardly. OP mentioned fast compilation and limited ways to code the same solution. C# and Java are slower to compile and offer way more options to do the same thing. Here's Uncle Bob take on testing with Go: https://m.youtube.com/watch?v=2dKZ-dWaCiU&t=36m40s

> C# and Java are slower to compile

Not for any meaningful work in my experience. As a matter of fact, I found the change/compile/run loop in golang to be slower on projects I've been working on due to the fact that it doesn't support incremental compilation, so any change I make ends up recompiling the entire program and writing out a 100+MB binary anyway. Compared to a Scala project I worked on before (and Scala is notorious for slow compiles), after the first compilation, all modifications happen very quickly as only the respective classes are re-compiled.

> Here's Uncle Bob take on testing with Go

Again, this doesn't apply for any non-trivial/large project. On a project I'm working on, it literally takes 7-8 minutes to do a clean build + run all unit tests in golang.

Re: Go + Services = One Goliath Project

#433

Post by hu3 »

apta wrote: post #432
hu3 wrote: post #411

Earlier quoted context omitted.

Hardly. OP mentioned fast compilation and limited ways to code the same solution. C# and Java are slower to compile and offer way more options to do the same thing. Here's Uncle Bob take on testing with Go: https://m.youtube.com/watch?v=2dKZ-dWaCiU&t=36m40s

> C# and Java are slower to compile Not for any meaningful work in my experience. As a matter of fact, I found the change/compile/run loop in golang to be slower on projects I've been working on due to the fact that it doesn't support incremental compilation, so any change I make ends up recompiling the entire program and writing out a 100+MB binary anyway. Compared to a Scala project I worked on before (and Scala is…

Go absolutely does incremental builds by default and has been like that since I can remember. Packages are only rebuilt when their source or their dependencies change.

Same for tests which are cached by default so during typical development only a subset of tests are executed and compilation time can be a big part. Leave full tests for CI.

An anecdote I found from 5 years ago:

On my 1.7GHz processor it takes 10 seconds to build the whole standard library from scratch (300k lines of code).

It's fast AF.

Re: Go + Services = One Goliath Project

#434

Post by Thaxll »

apta wrote: post #431
Thaxll wrote: post #409

Earlier quoted context omitted.

You didn't read the benchmark properly, plaintext benchmark it's 6th.

The first golang result in the plaintext benchmark ranks 8th (atreugo-prefork), which is incidentally immediately followed by firenio-http-lite, a Java library. My point still stands, this is a third party library that is not commonly used, and depends on another third party library, fasthttp, which itself comes with caveats from the its author.

Doesn't matter, it's still Go code, and contrary to many languages on that benchmark ( Java included ) all Go code is built in Go, so there is no runtime / external library written in C/C++. ( one of the reason why Go is also slow on the regex benchmarks )

Re: Go + Services = One Goliath Project

#435

Post by firethief »

jlokier wrote: post #153
firethief wrote: post #144

Earlier quoted context omitted.

> GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc. So what part of C is not in the list of warts averted in Go?

> So what part of C is not in the list of warts averted in Go? A simple language with only a few things to learn. Everything built up from those few things.

Huh. "A simple X" is a wily phrase, because everything is exceedingly "simple" in the aspect its designer had in mind[1], but complex from other perspectives. C may be simple in terms of how you would describe it building on the interface provided by a typical CPU, but to someone who only knows Scheme or Haskell learning the machine model is no small task--I don't think the 683-page length of the C11 specification can be attributed to its authors being long-winded. I don't really see Go as having inherited C's simplicity-in-terms-of-differences-from-a-machine-model. If they were optimizing for the same kind of "simplicity" that C has, they'd have to be out of their minds to add garbage collection, strings, maps, lambdas, and goroutines. Go, like Scheme, Haskell, and python, is a different "simple" from C.

1: unless designed by a committee with no such single-minded aim

Re: Go + Services = One Goliath Project

#436

Post by andy_ppp »

pm90 wrote: post #429
andy_ppp wrote: post #356

Earlier quoted context omitted.

It’s not bland it’s direct. What you’re doing is conflating personal preference with actual language features. Most developers who aren’t us would say python, being a higher level, dynamic scripting language rather than Golang which is lower level and extremely explicit about the data your program is using. Iteration in go is simply harder as you have to be more explicit rather than sketching something out. Changing…

It’s funny that none of the things you mention in your last paragraph are handled any better in Python. Without type safety, you instead have to deal with bugs caused by inane mistakes. If we’re talking about generics, the conversation has shifted from “writing scripts that does x” to “maintaining a production system” and for the latter, golangs type safety, out of the box excellent default tooling and easily grokkab…

Clearly I don’t agree but it’s an interesting and detailed answer. I do agree that type systems help with refactoring but not iteration. There’s a fine line there. Personally I think Golang’s type system isn’t as good as it could have been... I do like the idea that Golang reports to provide quite good (simplicity above everything), if they added proper macros to replace code generation and to replace the desire I have for generics it would be a much more useful language for my needs.

Re: Go + Services = One Goliath Project

#437

Post by _y5hn »

andy_ppp wrote: post #333
Sevii wrote: post #269

Earlier quoted context omitted.

People are willing to pay for it when you have 50+ engineers trying to push code through one deployment pipeline. There's an inflection point somewhere at which the cost of sharing deployments is no longer worth it.

I actually think this is where good software design and bounded contexts come in. You can perfectly well run a monolith with hundreds of developers if each of the sections is very well contained. There is no need to add network partitions everywhere to enforce this!

This. Usage of multiple nodes, networking, redundancy, etc. is because of operational concerns. It shouldn't be over "development concerns", which is exactly the wrong cause to embarge upon such a long-winded journey!

Re: Go + Services = One Goliath Project

#438

Post by jacques_chester »

apta wrote: post #376
jacques_chester wrote: post #347

Earlier quoted context omitted.

The JVM hasn't yet become fully container-friendly because it bases its calculation on the host OS figures, not the container figures. You can use a calculator to get precise, proven settings for any supported JVM: https://github.com/cloudfoundry/java-buildpack-memory-calcul...

I thought this was a solved issue since JDK 10: https://www.docker.com/blog/improved-docker-container-integr...

In my understanding, no. It's improved but not fully "fixed". Unfortunately that's as far as my understanding extends.

Re: Go + Services = One Goliath Project

#439

Post by zmmmmm »

plinkplonk wrote: post #322

just trying to understand - you guys think moving a Python2 monolith to Python 3 is too painful, and so you are going to port all the code from Python2 to a completely new language (Go), change the architecture (monolith -> microservices) and move the HTTP API to React + GraphQL, all in one year? 2020 is going to be in an interesting year at Khan Academy ;-)

That isn't what they said. They carefully explained that they could migrate to Python3 but that the benefit of doing so was small so they looked at the performance benefits of using other languages and decided that the performance benefit was large. The performance benefits of using Go (or Kotlin) were the deciding factor.

My guess is that the framework for them thinking about this is that they have already been thinking about migrating languages to get better performance and the Python3 migration seems like completely wasted effort if you then throw it all away to go to another language shortly after.

Re: Go + Services = One Goliath Project

#440

Post by zmmmmm »

I think some of the misunderstanding in these comments comes from not fully appreciating the perspective of not-for-profit organisations. While I can't speak for Khan Academy, I know that in every NFP organisation I have worked for there is an acute awareness that funding could dry up one day and the prime directive is to ensure that in a scenario like that, the work of the organisation can continue.

In this case, it leads to a higher concern about minimising the cost of the operational services than you might have in a for-profit organisation. In all the strategic planning I have been involved in with NFP, we always have the "what if worst case scenario arises" plan and in that plan the ability to scale down to bare minimum operational cost is key. It may not be conscious but I suspect that may be part of the reason the performance savings from moving to Go are so attractive in this case, where most profit-making companies just ask the question of whether they can afford to pay for the servers with their current margin or not and if they can they have more important things to worry about.

Post reply on HN