Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

181–190 of 449 posts

Re: Go + Services = One Goliath Project

#181

Earlier quoted context omitted.

Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

I’ve never seen it create a bottle neck, have you?

It will definitely be a problem if you use JIT interpreter like pypy

Re: Go + Services = One Goliath Project

#182
post #47

Earlier quoted context omitted.

> Is switching to python 3 really that hard? I think it's more that given their specific codebase it's similarly difficult to switch to python 3 as it is to switch to a number of other, entirely different programming languages. Once you recognize that rough equivalency, then it's worth considering the stability, compile times, necessary production resources, etc of those other programming languages. If your project's…

> it's similarly difficult to switch to python 3 But that's almost certainly not the case. Even if their existing codebase relies very heavily on the small subset of Python2 features that require manual porting, switching to Python3 will be much less work than rewriting everything in a new language.

The Python 2 to 3 conversion was only part of it. The libraries were a huge difference for us.

I will agree that porting to Python 3 would be less work than porting to Go, but we believe that the difference is less than people would suspect.

Re: Go + Services = One Goliath Project

#183
post #160

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 dislike JS, but love TS. But really, who cares about me anyway? The big picture is that JS is the English of software languages. It’s not beautiful, it steals from everyone else, and it’s never the best tool, but it’s becoming - more and more - rarely the wrong tool. I expect this trend to continue. Some genius will get JS to compile to native bytecode (WASM is the intermediate step). And, it too will be neither th…

As an aside, I find English to be a beautiful language. By stealing words from so many origins (Saxon words, Latin worse and Old Norse words), there's so much versatility.

The Saxon words are direct and burly. E.g. oak, brash, death, iron, etc. The Latin words are multisyllabic (e.g. multisyllabic :) ). The Norse words are just plain fun (e.g. Yule, law, heathen, oaf).

It's nice to be able to choose depending on context. Similarly, I find versatility to be nice in JS, as the community goes from embracing OOP to a more functional style.

Re: Go + Services = One Goliath Project

#184

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.

Making them work with strong types would require generics which would introduce a lot of complexity to the language though. It's being debated for years.

It's pretty trivial to write your own custom map/filter/reduce though.

Re: Go + Services = One Goliath Project

#185

Earlier quoted context omitted.

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

Large anonymous functions are very much a thing in JavaScript.

Re: Go + Services = One Goliath Project

#186

Earlier quoted context omitted.

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?

Why isn’t the foreach form the syntactic sugar?

Re: Go + Services = One Goliath Project

#187
post #183
post #160

Earlier quoted context omitted.

I dislike JS, but love TS. But really, who cares about me anyway? The big picture is that JS is the English of software languages. It’s not beautiful, it steals from everyone else, and it’s never the best tool, but it’s becoming - more and more - rarely the wrong tool. I expect this trend to continue. Some genius will get JS to compile to native bytecode (WASM is the intermediate step). And, it too will be neither th…

As an aside, I find English to be a beautiful language. By stealing words from so many origins (Saxon words, Latin worse and Old Norse words), there's so much versatility. The Saxon words are direct and burly. E.g. oak, brash, death, iron, etc. The Latin words are multisyllabic (e.g. multisyllabic :) ). The Norse words are just plain fun (e.g. Yule, law, heathen, oaf). It's nice to be able to choose depending on cont…

It’s a shame we stole the spelling rules from all those languages too.

Re: Go + Services = One Goliath Project

#188

Earlier quoted context omitted.

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.

> Regular functions definitions can't be used as expressions I’m having a difficult time understanding what you mean here. Can you offer an example? I have never felt compelled to write a multi line lambda.

Python can't replicate the structure of this JavaScript code:

  fooBaz(x => {
    // multiple lines of logic
  })
In python, you are forced to move the logic away from the point of usage, which means you lose some locality. This loss is sometimes not worth getting a "name" for the logic.

Of course, sometimes it is better to create a named function away from the point of usage, but I don't think that is always the case.

Re: Go + Services = One Goliath Project

#189

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'm not going to unequivocally contradict you here. However, I feel compelled to suggest something.

What if the end goal is not to do something elegantly, or perfectly, or with superb efficiency?

What if the goal is just to solve a problem in a way that's a little better than what came before?

Re: Go + Services = One Goliath Project

#190

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 and Python are for getting things done effectively, not nitpicking beauty of code.

That's why the authors of YouTube built YouTube in Python, and the authors of Khan Academy (re)built Khan Academy in Go, instead of bickering about nitpicks on HN.

Post reply on HN