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

371–380 of 449 posts

Re: Go + Services = One Goliath Project

#371

Post by ElonMuskrat »

ngngngng wrote: post #92

Unpopular opinion, writing Go is faster than Python. With the compiler, strong typing, and no versioning hell, I'm much more productive in Go. Whenever I use python I run into problems with versions and dependencies. And the whole community just tells me to use pyenv or virtualenv and it will "fix all my issues". Only it doesn't.

I just cannot understand how rational engineers would choose untyped languages like Python or Ruby for large scale systems. Humans make mistakes - even very smart humans make frequent mistakes - and blast radius grows with the size of the system.

Re: Go + Services = One Goliath Project

#372

Post by ElonMuskrat »

sibeliuss wrote: post #129

Isn't there a quote somewhere along the lines of "full rewrites are suicidal?" Seems pretty risky to me.

> Isn't there a quote somewhere along the lines of "full rewrites are suicidal?"

This is just dogma. Often it's the wrong choice, but sometimes engineers have very good reasons to re-write a system. As with all decisions, tailor the solution to the situation - not the other way around.

Re: Go + Services = One Goliath Project

#373

Post by gray_-_wolf »

jnwatson wrote: post #165
smadge wrote: post #152

Earlier quoted context omitted.

Maybe you could create some text macros to simplify the process, and then run a preprocessor on your program, and then.... uh oh.

You joke, but source code generation is the standard way to generics in go. They even have some standard hooks for it in the build system.

I still consider weird that results of go generate are supposed to be committed. Since when does generated code belong to the repository :/

Re: Go + Services = One Goliath Project

#374

Post by AnonymousPlanet »

harel wrote: post #369

Migration from python 2 to 3 is easy and fast. I've migrated multiple large apps and it took about a day each. Most libraries that matter have been migrated. Some don't even support python 2 anymore. It's practically 2020. This should not even be a consideration. After 2 to 3 is done they should consider again If they want to redo the stack but first I'd focus on this small maintenance task.

Hahaha, sorry but this is a very cute thing to say, in my view. At our company we just barely finished migrating our software with nearly a million lines of legacy Python 2 code to Python 3. This took over a year of nearly exclusive migration effort, just making our code work with both. The entire migration project started way before I joined the company several years ago.

So, no, things are not as simple if you're not dealing with toy projects. And no, you can't assume that it's the same for everyone if you're not in their shoes.

Your comment is pretty much the equivalent of "I don't see a bug. Works for me."

Re: Go + Services = One Goliath Project

#375

Post by jhoechtl »

harel wrote: post #369

Migration from python 2 to 3 is easy and fast. I've migrated multiple large apps and it took about a day each. Most libraries that matter have been migrated. Some don't even support python 2 anymore. It's practically 2020. This should not even be a consideration. After 2 to 3 is done they should consider again If they want to redo the stack but first I'd focus on this small maintenance task.

After all it will still be Python.

Khan Academy rationale might be false, as the transition path might be easy from Python 2 to Python 3.

But in the end they will have the same stack as before and that's what they clearly try to avoid. Given that it makes sense to transition from a dynamically typed language to a statically typed which offers more compiler feedback.

Re: Go + Services = One Goliath Project

#376

Post by apta »

jacques_chester wrote: post #347
apta wrote: post #286

> Go, however, used a lot less memory, which means that it can scale down to smaller instances. I could be mistaken, but this sounds like they went ahead with the default JVM settings, where it tends to use as much memory it is allowed to (which makes sense from a utilization and efficiency perspective). If memory usage is a concern, the JVM can be tuned for such.

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...

Re: Go + Services = One Goliath Project

#377

Post by apta »

kureikain wrote: post #324

Go is a very weird language :-(. It's very limited when you started to do complex thing. Example, let's say you are building websocket. You will have a hard time to write type safe websocket handler to process the payload from client for all the events... I started to do Rust/Crystal and both of them are better than Go(performance, type system). Yet, whenever I build something for work, I come back to Go :-(. I told…

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

Re: Go + Services = One Goliath Project

#378

Post by josteink »

purple-again wrote: post #9

We turned our monolith into a bunch of micro services almost 6 years ago to the day. For a long time I was very happy with the new pattern but over the years the weight of keeping everything updated along with the inevitable corners that fall behind and have...questionable..security due to how long they sit neglected has really left me wondering if I am happy with it after all. I would love hear some thoughts from ot…

> I would love hear some thoughts from others that made the move, especially anyone that decided to move back to a monolith repo.

We had a big monolith where I work.

We’ve been slowly, but surely isolating parts of the monolith as separate deliverables, extracted into their own repos. But only when appropriate, and not as a forced exercise.

The remaining “monolith” is still pretty big, but it does (mostly) represent one logical deliverable, so effort to split it up has some what stalled.

There’s been small points of friction, but nothing near as painful as we used to have it. No way we’re going back.

So everything in moderation. Micro services architecture is a tool. Use it when it’s the right one.

Re: Go + Services = One Goliath Project

#379

Post by StavrosK »

AnonymousPlanet wrote: post #374
harel wrote: post #369

Migration from python 2 to 3 is easy and fast. I've migrated multiple large apps and it took about a day each. Most libraries that matter have been migrated. Some don't even support python 2 anymore. It's practically 2020. This should not even be a consideration. After 2 to 3 is done they should consider again If they want to redo the stack but first I'd focus on this small maintenance task.

Hahaha, sorry but this is a very cute thing to say, in my view. At our company we just barely finished migrating our software with nearly a million lines of legacy Python 2 code to Python 3. This took over a year of nearly exclusive migration effort, just making our code work with both. The entire migration project started way before I joined the company several years ago. So, no, things are not as simple if you're n…

It very much depends on how good the codebase is. I also spent a year on and off porting a large codebase from 2 to 3, and it would have gone an order of magnitude faster if the codebase were in better shape.

Re: Go + Services = One Goliath Project

#380

Post by apta »

Thaxll wrote: post #239
coldtea wrote: post #227

Earlier quoted context omitted.

See what? This is an unofficial benchmark game - and based on implementations people bothered to provide. Not some scientific test, and nothing that guarantees these are the best implementations. And even if they were they're not representative of server/long running program behavior (where JIT quality and especially GC implementation) matters. Even so, the page linked starts with "Back in April 2010, Russ Cox charit…

I used both Java and Go in production and yes Go can be faster or Java it depends but Go usually use between 3 and 10x less memory. https://www.techempower.com/benchmarks/ ( real world benchmark with networking / serialization ect ... ) Get over it yes Go can be faster than Java it's not a secret.

> 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 sense from an efficiency and utilization point of view, as it generally aims for maintaining good throughput (whereas golang is only tuned for latency). The JVM now ships with new low latency GCs (ZGC and Shenandoah) which are currently available in experimental phase.

Post reply on HN