Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

101–110 of 449 posts

Re: Go + Services = One Goliath Project

#101
post #82

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…

The performance of Go is not particularly impressive. Especially when it is used to write busy servers with many simultaneous requests. And as a language it is not inspiring either. Not sure why business owners should love it either. Not enough features in the language coding productivity suffer in a long run. Also if the developer needs Go because other languages are "too complex" maybe said developer can't produce…

Complex languages don’t result in better programs. Else we would see Scala and C++ everywhere instead of them being relegated to narrow niches.

Re: Go + Services = One Goliath Project

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

>The Python 2/3 split is by far the most annoying thing about Python.

It's _literally_ the reason why I went with Ruby instead of Python all those years ago.

Re: Go + Services = One Goliath Project

#103
post #98

Earlier quoted context omitted.

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

Code comment

Re: Go + Services = One Goliath Project

#104
post #58

Earlier quoted context omitted.

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.

That mirrors my experience as well. Someone with influence is bored or wants to level up, so they'll drag the entire company into a long, expensive quagmire. Unless the existing codebase is mired in technical debt and completely unsalvageable or cannot scale further, this seems like a very radical move.

Which is precisely why most of the Web Dev should not be called Engineers.

Re: Go + Services = One Goliath Project

#105
post #57

Earlier quoted context omitted.

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.

By compiling you mean rewriting it in C or Cython. Which is only a good idea for certain applications.

Re: Go + Services = One Goliath Project

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

100% agreed, and you made me realize something.

As someone who writes — I mean prose, whether fiction or not (mostly not: essays, technical, etc) — I had to come to terms quite early with the dichotomy you explain here.

There is a place for the "beautiful language", the parts of it and the ways of using it that make it a pleasure, as a writer and as a reader. This, unsurprisingly, usually demands a whole lot of additional work on top of the 'direct meaning'.

Then there's a place, in casual communication, in business, in marketing, in essays as well, in technical docs, in speeches, in a lot of places, for the 'direct meaning', or close to that. The efficient use of language, when all form recedes in favor of meaning, of concepts, of getting that 'other' to get what you mean.

It's just that, in human language, you do it all with the same tools, we use formal or topical subsets of a vastly larger ensemble. In programming, we're more likely to use different languages [themselves subsets of human language if you think about it, but let's forget that for the sake of simplicity].

And there are programmers among us who love to dabble in the form, like some writers would spend 10%, twice, ten times the effort crafting just "better form" over an already well-defined idea/story. While other programmers, or at other times, just focus on getting things done. Cue the spectrum in-between.

So it all depends what we put in our code, as programmers, as human beings I guess. Is that thing a personal statement? Or is it just garbage code to temporarily expedite some roadblock? How do we approach complexity, bottom-up from the simplest elements/code, or top-down with the most expressive almost-meta entities? Maybe some side-line out-of-the-box angle? See how we'd word all of these, in human languages, as in code. We just wouldn't say the same, nor code (select languages) the same.

I don't know if I explained it well. But looking at it from a human language writer, it all seems clear now. The whole rat race of languages, the churches, the sheer effort put into form when meaning has already been solved 10 times by others, the strong NIH syndromes... it's all so common in traditional writers circles. We're all just writers, really!

Re: Go + Services = One Goliath Project

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

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.

Are lambdas different?

Re: Go + Services = One Goliath Project

#108

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.

I doubt that's unpopular. It's the same reason I significantly prefer Go over Ruby.

Re: Go + Services = One Goliath Project

#109

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.

I think Go is pretty refreshing as it is. If it isn’t to one’s taste there are 3712 other languages to choose from.

Re: Go + Services = One Goliath Project

#110

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 had similar feelings regarding anonymous functions before, having come from a more FP background.

Ways to make your Python experience nicer:

- almost never try to use map or filter. List/set/dictionary comprehensions are more pythonic and will be easier in the long run

- learn about standard library stuff, especially the methods on dictionaries, as well as the collections package. If you’re thinking about lodash, Python tends to have replacements that end up being better tbh

- if you really want a local function, just creating an inner def statement is fine. But KISS should usually make this rare.

Post reply on HN