Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

91–100 of 449 posts

Re: Go + Services = One Goliath Project

#91
post #79
post #71

Earlier quoted context omitted.

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

I'm sorry, what were you trying to say here? I've been staring at it for a few minutes and can't decipher it.

As I read it:

> “Typescript is a hack on top of [a] [supposedly] server side language that is [awful]. ( Node doesn't even support int64 )”

"supposedly" in this context meaning Js is not worth being called a "server side language", in the commenter's opinion (citing lack of int64 support for example). This also implies in subtext that "server side languages" would be of a higher category/value than languages for whatever other use-cases.

I personally don't agree with any of that, just helping communication here.

Re: Go + Services = One Goliath Project

#92
Unpopular opinion, writing Go is faster than Python. With the compiler, strong typing, and no versioning hell, I'm much more productive in Go.

Whenever I use python I run into problems with versions and dependencies. And the whole community just tells me to use pyenv or virtualenv and it will "fix all my issues". Only it doesn't.

Re: Go + Services = One Goliath Project

#93

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…

> Is hardware that expensive?

Hardware is cheap. Hardware is on the "accessible to a 3rd world middle class person" level of cheap.

But with enough scale, it adds up, while the costs of a rewrite don't. And the difference between a language like Go and one like Python is on the hundreds of times.

Re: Go + Services = One Goliath Project

#94
post #57

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…

In terms of general compute speed Go is many times faster than Python - approximately on a par with Java speed-wise but with much less memory use. That means your server costs are many times cheaper and your page latencies are much faster than Python. It's significant.

In the past companies would just compile python down to c to get the memory and perf they need. Probably would be the right answer here too, but that would not look as cool on the resume.

Re: Go + Services = One Goliath Project

#95
post #4

I was under the impression that Go was more performant than Kotlin. TMYK :)

Go was written for servers, Kotlin for mobile apps. Seems an obvious choice really.

The only thing I see where Golang wins over the JVM is overall memory usage for daemons.. As Khan is non-profit they want to save at any avenue.

Re: Go + Services = One Goliath Project

#96

Earlier quoted context omitted.

I think I meant the treatment of anonymous functions - lambdas are limited compared to normal functions.

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.

Re: Go + Services = One Goliath Project

#97

Earlier quoted context omitted.

def a(n): return lambda: print(n)

That's a couple characters over most languages I normally use. Plus lambdas have a number of strange warts and restrictions (no multi-line lambdas?) that leave me feeling that Python really dislikes traditional functional programming constructs.

Python has become less functional over time. It’s also not a particularly good OO language either. It’s really a more descriptive sort of bash that became ubiquitous despite its short comings.

Re: Go + Services = One Goliath Project

#98

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.

Do you mean a code comment could help the reader understand, or you want a comment about why for loops are less obvious than other more functional approaches?

Re: Go + Services = One Goliath Project

#99

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…

Switching to python3 is hard, especially if you have a massive python codebase interacting with other systems. Its not as easy as importing unicode_literals. Unicode breaks in very subtle ways.

Re: Go + Services = One Goliath Project

#100
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

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.

Post reply on HN