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

441–449 of 449 posts

Re: Go + Services = One Goliath Project

#441

Post by karlicoss »

zo1 wrote: post #412
makapuf wrote: post #354

Earlier quoted context omitted.

Re: your last sentence, what is text editor + my so bad ? How does pycharm warrant this definitive advices ?

Honestly, at this point mypy is inferior to the built-in PyCharm when it comes to speed, integration and in some cases the type-inference as well. I've also compared it to the VS python language server and it too doesn't stack up. The other metric would be what a person coming from established, full-fledged IDEs such as VS would expect. With PyCharm, you get intellisense almost on-par with what you get from VS for C#…

They actually added a daemon recently that should help to speed things up (https://mypy.readthedocs.io/en/latest/mypy_daemon.html) . Haven't had a chance to try it yet though.

Re: Go + Services = One Goliath Project

#442

Post by whatsmyusername »

viraptor wrote: post #317
whatsmyusername wrote: post #311

Earlier quoted context omitted.

This. The problem with decoupling services is usually there end up being a couple services that are critical but not sexy. No one wants to touch them so they sit around unmaintained until an unrelated change or unpatched security issue comes around. Suddenly you've got a big problem with a mystery codebase.

That sounds very familiar, but I'm not sure this is something that can be blamed on decoupling itself. An unpopular module is going to need as much attention as a micro service from code point of view. For upgrades / patching, there would be a company-wide process around it that doesn't care that much how the code is organised.

'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.

Re: Go + Services = One Goliath Project

#443

Post by viraptor »

whatsmyusername wrote: post #442
viraptor wrote: post #317

Earlier quoted context omitted.

That sounds very familiar, but I'm not sure this is something that can be blamed on decoupling itself. An unpopular module is going to need as much attention as a micro service from code point of view. For upgrades / patching, there would be a company-wide process around it that doesn't care that much how the code is organised.

'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.

I wrote company-wide, but it's not the case everywhere. At some scale you'll want department, or even project-wide process. But the policy should be fairly common - who owns it, what's the response time, how to escalate urgent things, etc.

Re: Go + Services = One Goliath Project

#444

Post by joshuamorton »

doteka wrote: post #352
whalesalad wrote: post #213

Earlier quoted context omitted.

This trend will gradually fade into the history books. Just because it’s a thing doesn’t mean it’s a good one.

Large anonymous functions are a thing in every modern language I can think of except python. It’s the only sensible solution in the case of functional method chaining, which is much more readable than nested comprehensions. Python just got this one wrong.

Large anonymous functions are rarely used in rust, go, python, java (streams instead), or cpp.

Streams and repeated application of short anonymous functions are a much better solution to the method chaining issue.

If js supported better streaming tools, they'd be less common in js too.

Re: Go + Services = One Goliath Project

#445

Post by AtlasBarfed »

zik wrote: post #57
timwaagh wrote: post #17

Seems like such a waste. Is switching to python 3 really that hard? Is hardware that expensive? If this is indeed the right call it doesn't bode well for traditional scripting languages as the web scales to fewer high traffic apps. We might start to see more jvm, go (apparently) or even rust and c(++), rather than speed of development languages like Python or Ruby. Trend seems to be the reverse though, with python th…

In terms of general compute speed Go is many times faster than Python - approximately on a par with Java speed-wise but with much less memory use. That means your server costs are many times cheaper and your page latencies are much faster than Python. It's significant.

I thought Go's GC was more wasteful of memory than Java's b/c of the focus on reduced pause times.

Re: Go + Services = One Goliath Project

#446

Post by AtlasBarfed »

cle wrote: post #51
zozbot234 wrote: post #35

Earlier quoted context omitted.

What's a "rapid development" language? I know about RAD, but that was a buzzword that was only ever used to push terrible languages like Visual Basic, and somewhat less terrible ones like Embarcadero Delphi.

Dynamic languages (so you can hack together stuff and quickly bypass any roadblocks), with REPLs (quick feedback and avoiding writing tests), and low cognitive overhead (so new folks can ramp up quickly). Some example languages that come to mind here: Python, Ruby, JavaScript, Clojure, Groovy. Go actually comes close here, even though it doesn't have a REPL and isn't very dynamic, because of its focus on minimizing c…

Rubys devs said the same thing about Java when Rails first came out.

Now look at Ruby, its stack is gigantic and cumbersome.

I guess Go will try to resist that, but over time Go will become burdened with a huge stack of outmoded software.

Re: Go + Services = One Goliath Project

#447

Post by zik »

AtlasBarfed wrote: post #445
zik wrote: post #57

Earlier quoted context omitted.

In terms of general compute speed Go is many times faster than Python - approximately on a par with Java speed-wise but with much less memory use. That means your server costs are many times cheaper and your page latencies are much faster than Python. It's significant.

I thought Go's GC was more wasteful of memory than Java's b/c of the focus on reduced pause times.

No, not at all. Go uses the stack for most variables so it's a lot less heavy on GC than Java.

Re: Go + Services = One Goliath Project

#448

Post by whatsmyusername »

viraptor wrote: post #443
whatsmyusername wrote: post #442

Earlier quoted context omitted.

'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.

I wrote company-wide, but it's not the case everywhere. At some scale you'll want department, or even project-wide process. But the policy should be fairly common - who owns it, what's the response time, how to escalate urgent things, etc.

I mean, I can write policy documents all day. Most of them would have had a better life as toilet paper.

Re: Go + Services = One Goliath Project

#449

Post by alfalfasprout »

bhntr3 wrote: post #281

> If we moved from Python to a language that is an order of magnitude faster, we can both improve how responsive our site is and decrease our server costs dramatically. I see people say things like this a lot but my experience is that while other languages are 10x or more faster than python in some benchmarks it's very rare that computation time dominates server latency or that servers are running at 60%+ cpu across…

Well Brad, that's very dependent on what exactly the service is. Moreover oftentimes low CPU utilization is actually a limitation of the implementation on a slow language (eg; Python technically does have async webservers but adds a lot of idle overhead).

Indeed, there are many benefits these more performant languages have over Python aside from raw single-core performance. For starters, more efficient concurrency and parallelism can help reduce average latency when combined with a quality async webserver. Then there's gains due to shared memory across threads.

So in many cases-- absolutely, you can only need 1 server vs. 10 when you migrate. It's thus not fair to say that these gains are "very rare".

Post reply on HN