Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

131–140 of 449 posts

Re: Go + Services = One Goliath Project

#131

Earlier quoted context omitted.

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.

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

Re: Go + Services = One Goliath Project

#132

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.

Most people who hate things can recognize that other people don't hate them.

For some reason, JavaScript haters always seem baffled when confronted with a person who doesn't hate JavaScript.

Re: Go + Services = One Goliath Project

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

    def b(x):
      return x + 1
vs

    x => x + 1

Re: Go + Services = One Goliath Project

#134
post #63
post #26

Earlier quoted context omitted.

Numerous large projects and companies have publicly stated that they are stuck on Python 2 and it's easier to migrate languages, even to ones that they have to invent (Go) than to migrate to python 3. At least one of these companies had Guido on their staffs for years. Another, also with Guido on the staff, needed over three years to migrate from 2 to 3. The overwhelming body of evidence shows that migrating a large…

wait - what? Is Django a big enough project for you? Did you know that Django was not only successfully migrated from Python 2 to Python 3, it was ported in such a way that for many years it used the same codebase in both languages ... Perhaps that's the biggest advantage of porting from 2 to 3. A lot of the code could run in both languages.

The corollary of my complaint is there will always be someone who pops up on HN with no idea how many lines of code are in a "large project" like Dropbox or YouTube.

Re: Go + Services = One Goliath Project

#135

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.

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?

Re: Go + Services = One Goliath Project

#136

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

Check out rust. Everything about the language is sturdy.

Re: Go + Services = One Goliath Project

#137
post #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 rea…

> fast compiles, fast startup and fast runtime

All I can think of is D, but it’s not quite mainstream. Are there any other less popular languages that meet all 3 conditions?

Re: Go + Services = One Goliath Project

#138

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

That is a niche, because most applications are IO bound and not compute bound. What even qualifies as “systems programming” is ill defined. Far more critical business systems run on Java and C# servers than C++. If there are C++ components they tend to be small parts along the critical path and not the primary implementation language.

Re: Go + Services = One Goliath Project

#139
post #40

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've worked with or known about too many places that have jumped on the microservices bandwagon and the only thing I've encountered is a lack of maturity (mine included) and a knee-jerk reaction against monolithic code, when the problem isn't the size of the codebase but its organic growth over time. Go is an excellent language for it but distributing your business logic and functionality over a network fundamentally…

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

Re: Go + Services = One Goliath Project

#140
post #63

Earlier quoted context omitted.

wait - what? Is Django a big enough project for you? Did you know that Django was not only successfully migrated from Python 2 to Python 3, it was ported in such a way that for many years it used the same codebase in both languages ... Perhaps that's the biggest advantage of porting from 2 to 3. A lot of the code could run in both languages.

The corollary of my complaint is there will always be someone who pops up on HN with no idea how many lines of code are in a "large project" like Dropbox or YouTube.

This is kind of a cop-out, how would anyone know?

Is Dropbox open source? Is Dropbox even a typical Python application representative of the challenges of porting from 2 to 3?

My hunch is that the challenges of porting Dropbox to any other language have to do less with Python more with the need to deal with a filesystem at a lower and more granular level than what typical programming languages offer. Thus everything needs to be rewritten in bazillions of ways to handle the bazillion corner cases.

Post reply on HN