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

141–150 of 449 posts

Re: Go + Services = One Goliath Project

#141

Post by throwthisaway2 »

reedwolf wrote: post #124
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.…

>I'd rather just use Javascript Not a phrase you hear every day.

This is a symptom of people being js first. And now their entire world is js. Especially talking about constraints.

And you can tell the gripe about anon functions is just lazy abstraction. Its like the opposite problem of the goto, everything here now. No abstraction.

Re: Go + Services = One Goliath Project

#142

Post by gsempe »

catalogia wrote: post #41
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.…

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.

Re: Go + Services = One Goliath Project

#143

Post by baddox »

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

But python for loops can and typical do have multiple lines, yet that “block” inside the for loop doesn’t have a name. The fact that the body of a for loop can have multiple lines but an anonymous function cannot is a purely arbitrary syntax limitation, and the principle you stated ought to apply (or not apply) equally to both use cases.

Re: Go + Services = One Goliath Project

#144

Post by firethief »

nordsieck wrote: post #67
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…

> But what I can't really figure out is why so many devs love it. I think, in order to understand why so many people love Go, you first need to understand why so many people love C. Go is C with most of the warts removed (for application development). GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc. Yes, there are plenty of places that C can…

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

Re: Go + Services = One Goliath Project

#145

Post by baddox »

aserafini wrote: post #130
ptx wrote: post #100

Earlier quoted context omitted.

Where's the boilerplate? "def b():" and "() => {}" are both 8 characters. It is annoying that you have to give the function a name, though.

On the one hand it’s annoying, on the other it enforces a discipline of thought in the same way that having to name variables does.

That’s an interesting principle, something like “a block of code that is complex enough to be written across multiple lines of code ought to be given a name,” but standard idiomatic Python already violates that principle by featuring multiple lines in the body of a for loop. The fact that the body of a for loop can be multiple lines but the “body” of a lambda cannot is an arbitrary syntax inconsistency.

Re: Go + Services = One Goliath Project

#146

Post by bakul »

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…

IMHO a microservice should follow the unix philosophy of doing one thing well. But interfacing with other services is not as simple as unix pipes. In particular it is more of a request/response communication. Consequently, interfacing needs to be thought through carefully and made as simple as possible. They should evolve much more slowly than individual service code. While you may use (g)rpc or http at a lower level, your specific protocols will have many more constraints. Ideally you have codified assertions about their behavior in tests early on.

Note that they are not all going to start/stop at exactly the same time and during development they may even crash so each microservice should survive such transitions. You may have two different versions of service code or even completely different implementations or two different version of the API in use at the same time. This can happen as different services evolve at a different rate. And you may want to transition to a new version in a piecemeal manner so as to not bring the whole service down. All these considerations complicate things. So ideally you have factored out these common tasks in shared library/packages. And ideally you write your code such that if necessary more than one service can be compiled into the same binary for performance reasons.

In a monolith some things become easier since everything dies at once! But somethings become more complicated - such as supporting evolving code. And monolitha require more discipline to keep things modular. Over time this gets harder and harder. Lack of modularity means you have to understand a lot more code and when you evolve things, more code will have to change and there may be unforeseen side-effects. And scaling can become harder.

Re: Go + Services = One Goliath Project

#147

Post by FpUser »

WoodTree wrote: post #101
FpUser wrote: post #82

Earlier quoted context omitted.

The performance of Go is not particularly impressive. Especially when it is used to write busy servers with many simultaneous requests. And as a language it is not inspiring either. Not sure why business owners should love it either. Not enough features in the language coding productivity suffer in a long run. Also if the developer needs Go because other languages are "too complex" maybe said developer can't produce…

Complex languages don’t result in better programs. Else we would see Scala and C++ everywhere instead of them being relegated to narrow niches.

You know, there are things in between. As for being niche - not sure bout Scala as I have zero experience with it, C++ however is anything but.

Re: Go + Services = One Goliath Project

#148

Post by dwaltrip »

baddox wrote: post #143
joshuamorton wrote: post #131

Earlier quoted context omitted.

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

But python for loops can and typical do have multiple lines, yet that “block” inside the for loop doesn’t have a name. The fact that the body of a for loop can have multiple lines but an anonymous function cannot is a purely arbitrary syntax limitation, and the principle you stated ought to apply (or not apply) equally to both use cases.

Thanks for writing this, that clarifies the issue more clearly and concisely than what I had in mind.

I will mention a core aspect of my argument, to add to your point.

When you make a named function and then use it separately somewhere else, there is a loss of locality. The logic is now further from its point of use. This is a cost, and sometimes it is an unreasonable one.

Re: Go + Services = One Goliath Project

#149

Post by dwaltrip »

StillBored wrote: post #135
dwaltrip wrote: post #90

Earlier quoted context omitted.

They could also improve the language. Map, filter, and reduce are such fundamental concepts.

Fundamental? IMHO, they are just syntactic sugar on a foreach loop. Which in many ways is bad because it provides yet another way to express the same concept, without a significant difference in the method of execution. What am I missing?

Map and filter allow for a very concise and clear indication of the intention of the code, so it is much quicker for the reader to parse what it is doing.

Edit: Also, for loops are just a way of implementing a mapping, where you have data A that you want transformed into data A*. The map is the fundamental concept here, not the for loop.

Re: Go + Services = One Goliath Project

#150

Post by smadge »

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

Just write an implementation of map/reduce/filter for every type in your go program!
Post reply on HN