Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

121–130 of 449 posts

Re: Go + Services = One Goliath Project

#121

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…

I find the tooling to be very attractive, especially since modules came out. go test, go mod, go vendor, etc... Working in the Go ecosystem is mostly pleasant and easy.

Re: Go + Services = One Goliath Project

#122
post #114

Earlier quoted context omitted.

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

Java killed it for general purpose use in the 90s. It’s never your first option unless you are in areas like games, graphics, some embedded work, or quantitative trading.

Re: Go + Services = One Goliath Project

#123

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…

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.

I worked on a fairly large codebase that needed to be rewritten from scratch when migrating from 2 to 3, primarily because all the tests were written using a test framework that was no longer maintained. So given that you might need to start over anyway, I think it's reasonable to consider other options. That said, yeah it's difficult to understand how KA's web server costs aren't already basically zero, and how their endpoints aren't already basically instantaneous.

Re: Go + Services = One Goliath Project

#124

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.

Re: Go + Services = One Goliath Project

#125

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

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

A for loop could mean anything, and not necessarily what the author intended. https://en.wikipedia.org/wiki/Rule_of_least_power leads to list.filter(p) always calls p O(n) and returns a list of the same type with some or all of the same elements. list.map(f) always calls f O(n) times and returns a list of the same length. p and f can be reused and only depend on a single element. A good platform will inline list.filter(p).head into machine code that exits a loop early, that you don't have to write or review.

Re: Go + Services = One Goliath Project

#126
post #55

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…

It also lends itself to patterns in code. One thing that learned about Python coming from Perl was there was a “Pythonic” solution. Go seems to take that idea further with gofmt and a small but powerful std lib. I can typically glance at how someone is configuring their http.Server and understand the intention of the code.

Re: Go + Services = One Goliath Project

#127

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…

I don't think upgrading to python 3 will be as hard as rewriting the entire thing, but rewriting does come with the benefit that you are not stuck with the problems that come with dynamic typing in a huge codebase, and i'm assuming this is why sticking with python is hard. They also said a faster language will improve their server.

Instead of rewriting with static types, they could just gradually add them – Python 3 supports static typing[1] with the actual type-checking done by external[2] tools.

[1] https://docs.python.org/3/library/typing.html

[2] http://www.mypy-lang.org/

Re: Go + Services = One Goliath Project

#128
As much as I personally don’t enjoy writing Go I really can’t fault them.

I still find it interesting that for a relatively obvious feature set of fast compiles, fast startup and fast runtime there really isn’t anything mainstream out there to compete with Go.

I really hope something like Kotlin, Swift, ReasonML or even AOT JVM/.NET brings something to the table soon. Or perhaps I’ll just have to wait for WASM to really take off server side.

Re: Go + Services = One Goliath Project

#130
post #100

Earlier quoted context omitted.

That's a lot of boilerplate for a closure…

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.
Post reply on HN