Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

111–120 of 449 posts

Re: Go + Services = One Goliath Project

#111

The article says this: "Moving from Python 2 to 3 is not an easy task." I disagree with this. It's a Python project's dependencies that make it hard to move from 2 to 3, and most libraries have been updated. Of course, you could argue that it isn't easy to migrate a codebase from one major version of a language (or framework, or database) to another, but when you eliminate easy from your vocabulary it becomes harder…

That’s precisely why it’s not an easy task!!

Re: Go + Services = One Goliath Project

#112

Earlier quoted context omitted.

The lack of multi-line lamdas is one of my biggest gripes with python.

If you feel the need to use a multi line lambda you should be using a regular function. This is a code smell for sure.

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.

Re: Go + Services = One Goliath Project

#113
post #23

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 think that the fact you have much more visibility over which of the services are behind and have lower security practices one of the things I love about our microservices - we recently (a year ago) broke up our monolithic codebase into a service oriented architecture (I would hesitate to call our services micro personally) and I was astounded at all of the hidden security issues and random code in the far reaching…

Well, I can only agree with all that... But the move to services adds a lot of surface that needs it's own security and architecture maintenance.

The more you break down your code (the smaller the size of the services), the more maintenance need is created from the division, and the easier it is to fall behind on it.

Re: Go + Services = One Goliath Project

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

c++ is in narrow niches?!

Re: Go + Services = One Goliath Project

#115
The article mentions Go's superior compile time, when compared to Kotlin. I have done a lot more Java development than Kotlin, but my recollection is that both of them compiled fairly fast.

Is Go really significantly faster to compile for similarly sized projects?

Re: Go + Services = One Goliath Project

#116

Earlier quoted context omitted.

> For loops take more reading to understand. A short comment would help here.

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

No, Go does not need this and I do not want it to get these useless "features". Go is simple and it gets things done with an amazing standard library. Use a different programming language if this does not suite you. Every programming language ends up with its own implementation of these "concepts" that it is hard to keep track. What is so difficult about for loops? It's simple for everyone and you don't need to learn new concepts because it works.

Re: Go + Services = One Goliath Project

#117
post #27

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…

What's really the ergonomic difference between "traditional scripting languages" and Go? I came up writing professional C code, and spent most of the last 15 years writing "traditional scripting language" code, and Go feels a lot closer to scripting than to C to me, despite compiling down to machine code. Go has static types, and that distinguishes it from Python, Ruby, and Perl. But the trend now seems to be for lan…

It’s usually the DSL argument. In Go you can establish calling patterns for errors, but you’re really limited in terms of providing libraries with nice APIs that prevent you from making mistakes.

In Python you have a lot of ways to make sure someone does a thing. Exceptions are good for making sure an error is handled. Context managers make sure a resource is cleaned up properly.

I might be wrong but I feel like writing something like jquery (with its fluent API) would be really tough in Go.

Re: Go + Services = One Goliath Project

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

C++ is not a narrow niche. We do see it pretty much everywhere and it continues to be the most used language for systems programming, games, embedded systems, and pretty much anything else where performance is critical.

Re: Go + Services = One Goliath Project

#119

The article mentions Go's superior compile time, when compared to Kotlin. I have done a lot more Java development than Kotlin, but my recollection is that both of them compiled fairly fast. Is Go really significantly faster to compile for similarly sized projects?

I’ve written some things in both languages and compiling go feels an order of magnitude faster.

Re: Go + Services = One Goliath Project

#120
post #71

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

Typescript is a hack on top of supposly server side language that is aweful. ( Node doesn't even support int64 )

Node supports BigInt now (integers of arbitrarily high precision).
Post reply on HN