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

201–210 of 449 posts

Re: Go + Services = One Goliath Project

#201

Post by krallja »

WoodTree wrote: post #88
im3w1l wrote: post #69

Earlier quoted context omitted.

If you need more power than a lambda you would use a nested function, e.g. def a(n): def b(): print(n) return b

Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

A lambda also behaves this way; it’s how it captures the closure scope.

Re: Go + Services = One Goliath Project

#202

Post by catalogia »

dx87 wrote: post #55
catalogia wrote: post #41

Earlier quoted context omitted.

Go seems to be optimized for onboarding new developers (particularly straight out of school) quickly, rather than for the long term comfort of developers using it. There are Rob Pike quotes that speak to the first part of that at least. If I was a business owner, I'd love Go. But what I can't really figure out is why so many devs love it. It's far from the worst thing in the world, I don't hate it, but I just can't g…

From what I can tell by reading what Go developers write, they like it precisely because it's not something to get excited over. It seems like the kind of language where once you learn it, you don't have to keep up with a bunch of blog posts detailing all the cool new things being added to it, and decisions over stuff like formatting are made for you. I primarily use Rust for hobby projects, and the steady stream of…

I think there can exist a happy middleground between constant churn and what Go currently provides. Some nice quality of life features like pattern matching and list comprehensions would go a long way towards making it a more pleasant language, without making developers feel like they're in a constant struggle to stay current.

Re: Go + Services = One Goliath Project

#203

Post by lonelappde »

freyr wrote: post #58
neurobashing wrote: post #38

Earlier quoted context omitted.

Everyone’s project/code base is different but in my experience there’s been a critical mass of libraries for a few years. I presume the “it’s hard to move to 3” is dev teams wanting a new toy as much as “the rewrite is too complex”. Library use, size of code base etc are all big factors but at the end of the day, I think team motivation is really the deciding factor.

That mirrors my experience as well. Someone with influence is bored or wants to level up, so they'll drag the entire company into a long, expensive quagmire. Unless the existing codebase is mired in technical debt and completely unsalvageable or cannot scale further, this seems like a very radical move.

Replacing an old unholy mess with a new unholy mess is usually a bad plan. It's called the Second System Effect.

Re: Go + Services = One Goliath Project

#204

Post by threatofrain »

joshuamorton wrote: post #131
dwaltrip wrote: post #112

Earlier quoted context omitted.

Regular functions definitions can't be used as expressions. You are basically saying that one should never need a multi-line lambda. Obviously, I disagree.

If you need to express something complex enough that you can't do it in a single statement in Python, it deserves to have a name (or more likely, it already has one in the standard library).

I've started to use Python type hints, but even with typing I like to label my names things that describe local concerns (types are often more general than what you mean to say), and sometimes I'll deliberately shorten the names to make a Python lambda fit where in another language with bracketing I'd just take an extra 1-2 lines and format the line differently.

I've written snippets or data structures one way or another as I'm sure many have, and in my experience the results have been mixed. This and the fact that reduce has no bearing on your app architecture, I do see this as arguing over a small and vague gain or loss.

Re: Go + Services = One Goliath Project

#205

Post by stoicShell »

aazaa wrote: post #62

> Now, in 2019, Python 3 versions are dominant and the Python Software Foundation has said that Python 2 reaches its official end-of-life on January 1, 2020 , so that they can focus their limited time fully on the future. Undoubtedly, there are still millions of lines of Python 2 out there, but the truth is undeniable: Python 2 is on its way out. The Python 2/3 split is by far the most annoying thing about Python. I…

On a personal level, I have the same problems with using Python.

I've become enamored with package management in Go — not perfect yet but efficient, simple, to the point. The backwards compatibility enforced at the version level is also great — you often find Go code years old that keeps running just fine. I like things that you set up once and may just forget, that's where real productivity is found imho — it doesn't matter that I can do X in 1h if I have to do it every other day, I'd rather spend a full week or even ten, and solve it forever.

I think Js is comparably simple but I've heard so many horror stories about dependency management that I just don't know — I've yet to use Js in prod myself at work and I don't look forward to this day.

Here's the thing: it does not matter how great a language may be while I'm writing it, because that's 10-25% of my time; what matters is that everything around, from setting up dev environments to shipping passing by devops, especially as a one-man/small team, can be done "simply enough". And that, IMHO, is where Go is miles ahead of most other languages from a philosophy standpoint.

I tend to feel very positively about Rust for it looks to be an extraordinary intelligently lead project, with comparably 'real' benefits that extend beyond the code page (but I've yet to use it myself to confirm first-hand).

We see the importance of these topics so clearly with Py2/3: none of the problems between these two have anything to do with what's in the code, with programming; all of it has to do with the ecosystem, with the real and much larger task of maintaining codebases, managing teams and deploying 'stuff' in ways that work with the environment (whether tech, people, knowledge, politics, what have you).

The move to 3 by Python has been a failure in that regard, and IMHO it rests on the shoulders of an entire community who chose to stick to 2 now regardless of what happened then. Well then is now and the result is chaotic.

I'm not worried about Python itself — the language is incredibly popular, especially in academia, and we need to double the programmers population earthly each year so that's a sustainable amount of new projects written in Python 3 every day. Old 2 projects will be but a drop 10 years from now simply because of this number effects of growing tech at such an insane rate (it's been about true since the late 1940's, uncle Bob has a great take on it in his latest appearance in The Changelog podcast).

Anyway. I can't wait for py2 to die and py3 to become the only Python.

Re: Go + Services = One Goliath Project

#206

Post by dangoor »

sibeliuss wrote: post #129

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

You might be thinking of this excellent article by Joel Spolsky: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

(Ironically, that post is about Netscape and the rewrite, Mozilla, ended up growing as a nonprofit far beyond Netscape's original scale.)

The so-risky-it's-almost-certain-to-fail approach is a big bang rewrite. Stop the world until the rewrite is done.

That's not what we're doing. A tiny bit of our GraphQL schema is _already_ running in production atop new services written in Go. We're going to do this step-by-step, while keeping the site running, _and_ adding committed features next year.

It's still a huge investment and comes with risks, but it's an incremental process and we'll be able to track the progress at every step.

Re: Go + Services = One Goliath Project

#207

Post by nemo1618 »

gsempe wrote: post #142
catalogia wrote: post #41

Earlier quoted context omitted.

Go seems to be optimized for onboarding new developers (particularly straight out of school) quickly, rather than for the long term comfort of developers using it. There are Rob Pike quotes that speak to the first part of that at least. If I was a business owner, I'd love Go. But what I can't really figure out is why so many devs love it. It's far from the worst thing in the world, I don't hate it, but I just can't g…

Go is mainly loved by devs who love to build products over to write beautiful code. Go is for product builders who use coding as a mean and not an end.

Most of the "means vs. end" dichotomy occurs at a level above choice of language. Every language permits both beautiful code and ugly code. Every language allows you to optimize. I write Go every day and I strive to write beautiful and performant code, for the sake of writing beautiful and performant code. Go may not allow you express e.g. quicksort as beautifully as in Haskell, but its simplicity and pragmatism lend themselves to a different kind of beauty.

Re: Go + Services = One Goliath Project

#208

Post by lonelappde »

ljm wrote: post #155
goostavos wrote: post #139

Earlier quoted context omitted.

>knee-jerk reaction against monolithic code It's almost religious. The reaction some people have when you suggest monoliths is completely baffling. It's apparently just "known" that it is the correct approach to all problems, so, y'know, it's embarrassing for you to have even suggested otherwise.

The best systems I've worked on have all been well architected monoliths. The code is ugly as fuck in some places but that's what tech debt is. If you release a bug to prod in your monolith, it is exactly the same as a dependent microservice releasing the same and bringing the cluster down. You get a crash either way, and at least with a monolith you're not spreading your call-stack over the network; it's all in memo…

A micro service can have non critical dependencies.

Re: Go + Services = One Goliath Project

#209

Post by nradov »

thatswrong0 wrote: post #39

Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don't like either. Is there something I'm missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I've wanted to create more complex business logic with stricter constraints, neither has been quite up to the task. Go doesn't make things easy. It asks you to repeat yourself.…

Java can do almost all of that now, and offers excellent runtime performance.

Re: Go + Services = One Goliath Project

#210

Post by edflsafoiewq »

hactually wrote: post #172
zeugmasyllepsis wrote: post #76

Earlier quoted context omitted.

While functions are first class in Go, the limitations of the type system make them less ergonomic to use, I think. Without user defined generics, many of the common uses of first-class functions become a lot less convenient to use.

Do you have an example where that's the case?

map, filter, fold, etc.
Post reply on HN