Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

71–80 of 449 posts

Re: Go + Services = One Goliath Project

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

Re: Go + Services = One Goliath Project

#72
post #29

Earlier quoted context omitted.

migrating from python 2 to 3 is such a large task that migrating to any other language is a comparable effort. this is not just a library problem the language itself changed significantly source: no python services at my company are going to be migrated to python 3; it’s all moving to a JVM

> migrating from python 2 to 3 is such a large task that migrating to any other language is a comparable effort I'm going to call BS on that one. If you're having issues with Python 2, then it might make more sense to switch to another language instead of upgrade to Python 3. But going from Python 2 to 3 is much easier than switching languages completely. Python is not a perfect language. There is no perfect language…

I'm skeptical too but if they're doing a lot of communication with other services and they relied on bytes and ASCII just working and the code isn't backed up by tests then I can see them having a very bad time going from Py2 to Py3.

Re: Go + Services = One Goliath Project

#73
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…

> 2005-era Python was wrong about that.

Given Python's incredible rise since 2005, and even in the past few years, I'm not sure we can say they were "wrong." It's serves a purpose.

Re: Go + Services = One Goliath Project

#74

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.

Re: Go + Services = One Goliath Project

#75
post #62

> Now, in 2019, Python 3 versions are dominant and the Python Software Foundation has said that Python 2 reaches its official end-of-life on January 1, 2020 , so that they can focus their limited time fully on the future. Undoubtedly, there are still millions of lines of Python 2 out there, but the truth is undeniable: Python 2 is on its way out. The Python 2/3 split is by far the most annoying thing about Python. I…

If you're installing a package via the package manager, it will very quickly tell you if you can install it on your specific version of python. Unless you're downloading some rather obscure and un-loved library where the author didn't explicitly state which versions of python they support.

Multiple package managers: There has only been 2 big ones from my long-term general usage of python. Easy-install and pip, the former of which is falling in favor but still semi-supported. Pretty much everything runs off of pip. What may be confusing you, and does confuse me at times as well, is their naming and the installation instructions as provided by library authors. E.g. some say python setup.py -install others just tell you to "pip install" it. Some would say use "setuptools", etc. Other would tell you to use things such as "conda" or "anaconda", pipx, and to create virtualenvs. All secondary, but things that should not ideally distract you from just plain using pip.

3. This has also been getting a whole lot better in the last 5 or so years. Microsoft has been funding dev-time to make the ecosystem for python (including extension compilation) much more pleasant in the Windows space. Also, the package managers and library authors are doing a whole lot better in that binary distributions are much more prominent so the compilation of the extensions never has to happen on your machine.

Re: Go + Services = One Goliath Project

#76

Earlier quoted context omitted.

You had me nodding in agreement until the last paragraph. Functions are first class in Python. You can pass them all over the place and use them the same way you would in JS. You don’t have Lodash but frankly it’s not needed. The stdlib, functools and itertools are pretty much all you could ever ask for.

In fact, they're first class in Go too, in fact there's fewer languages where that's not the case than is, I'd imagine.

While functions are first class in Go, the limitations of the type system make them less ergonomic to use, I think. Without user defined generics, many of the common uses of first-class functions become a lot less convenient to use.

Re: Go + Services = One Goliath Project

#77
post #69

Earlier quoted context omitted.

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

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…

Re: Go + Services = One Goliath Project

#78
post #66

Kotlin looks nice now but on the long term it's a bad choice since they're stuck on Java 8 they will always lag behind the real JVM and won't be able to catch up since they need heavy modifications.

If you mean the java 8 bytecode version, that hasn't been true since April:

https://blog.jetbrains.com/kotlin/2019/04/kotlin-1-3-30-rele...

Re: Go + Services = One Goliath Project

#79
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 )

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