Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Go by porting a medium-sized web back end from Python

benhoyt.com

Post reply on HN
Print view View original

181–190 of 207 posts

Re: Learning Go by porting a medium-sized web back end from Python

#181

Post by hasenj »

didibus wrote: post #130
hasenj wrote: post #64

Earlier quoted context omitted.

What would you choose instead?

OP was saying porting a project to Go sounds like premature optimization. The alternative is obviously to continue to use the original language. The question to be answered is why are you porting it? Fun and giggles? Hoping to achieve better performance? Scale? Portability? Correctness? Simplicity? Support? I'd say most of the time its for fun and giggles. Which I think is as fine a reason as all the others, but when…

I think it's the opposite. Choosing python in the first place is mostly for fun and giggles.

People want to switch away from python because of all the pain they feel from it.

Re: Learning Go by porting a medium-sized web back end from Python

#182

Post by hasenj »

lmm wrote: post #111
hasenj wrote: post #63

Earlier quoted context omitted.

Writing in a fast compiled language is not premature optimization. Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance. Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. Writing in a slow interpreted language is more like premature "de…

No-one goes out of their way to choose a slower language. People who choose to write something in Python are getting value out of it, or at least believe they are; if writing the program in Go will be more costly (in development time, defect rate, library availability or something else) than writing it in Python then writing it in Go is premature optimization, and if writing it in Go wouldn't be more costly than writ…

> No-one goes out of their way to choose a slower language.

> (...)

> why were you thinking of writing it in Python at all?

They simply have no awareness of how slow it is, or how important performance is.

> IME thinking about language performance at all is premature optimization

Are you serious? Python code is about 10 times slower than equivalent code in Go.

Re: Learning Go by porting a medium-sized web back end from Python

#183

Post by hasenj »

monktastic1 wrote: post #102
hasenj wrote: post #63

Earlier quoted context omitted.

Writing in a fast compiled language is not premature optimization. Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance. Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. Writing in a slow interpreted language is more like premature "de…

> "deoptimization" pessimization? But the code doesn't have to become more complicated for it to be premature optimization. It literally just means improving something (generally performance) before there's a clear need. > Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. I assume you mean "rewriting" here, since we're t…

Remember the context here. The idea is "premature optimization is evil". A lot of people often abuse the quote and then conclude "Caring about performance is bad" which is a complete non-sequiter and not the originally intended meaning of the quote.

The reason premature optimization is evil is that it consumes a lot of time and makes the coder more difficult to read and reason about.

If there's no clear benefit to this, then all the work done to optimize it resulted in _negative_ value. There was no gain, only time wasting and more complicated code.

An example of where performance doesn't matter: a piece of code is only executed once every 10 seconds and it finishes executing in 5ms. Spending time to reduce its execution time to 1ms does not produce any tangible benefits.

An example of where performance does matter: a piece of code is running all the time and it takes 500ms. If you can reduce it to 20ms, it's totally worth it.

Re: Learning Go by porting a medium-sized web back end from Python

#184

Post by hasenj »

didibus wrote: post #126
hasenj wrote: post #63

Earlier quoted context omitted.

Writing in a fast compiled language is not premature optimization. Premature optimization would be something that makes the code more complicated and more difficult to follow but produce better performance. Writing the same code in a fast compiled language is just the default thing that you should be doing when you are not doing premature optimization. Writing in a slow interpreted language is more like premature "de…

I don't follow this logic. Why not use C all the time by default then?

Sometimes you have no choice, for example, on the browser.

But if you're writing server code, I think choosing an interpreted language like Python/Ruby is the single worst mistake you can do.

Re: Learning Go by porting a medium-sized web back end from Python

#185

Post by didibus »

hasenj wrote: post #181
didibus wrote: post #130

Earlier quoted context omitted.

OP was saying porting a project to Go sounds like premature optimization. The alternative is obviously to continue to use the original language. The question to be answered is why are you porting it? Fun and giggles? Hoping to achieve better performance? Scale? Portability? Correctness? Simplicity? Support? I'd say most of the time its for fun and giggles. Which I think is as fine a reason as all the others, but when…

I think it's the opposite. Choosing python in the first place is mostly for fun and giggles. People want to switch away from python because of all the pain they feel from it.

Ya, maybe for some. I think for businesses part of it is familiarity, as its now a lot of people's first language. I also think its a choice made often when you start, because it allows you to go faster in the beginning. Which is where a lot of new projects need to be the fastest. Its still a great choice for projects that are short lived, that's why ML works so well on it, most of ML is just quick iterations on prototypes until you find a solid model.

Re: Learning Go by porting a medium-sized web back end from Python

#186

Post by Daishiman »

randomdata wrote: post #133
4c2383f5c88e911 wrote: post #21

I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…

- Go's opinion about generics has always been that it should have them, but finding the right expertise to implement them in a non-ridiculous way has been a struggle. They are marked for inclusion in coming versions (2.0). - error is an interface. If you are returning strings most of the time, you're probably doing it wrong. - Wasn't gofmt originally executed during compile time? I'm not sure why it changed, but it s…

> Go's opinion about generics has always been that it should have them, but finding the right expertise to implement them in a non-ridiculous way has been a struggle. They are marked for inclusion in coming versions (2.0).

The fact that people can claim that C#, Java, Scala, Kotlin, Haskell, Rust, Swift have "ridiculous" implementations of generics sounds like a very bad excuse.

Re: Learning Go by porting a medium-sized web back end from Python

#187

Post by hasenj »

didibus wrote: post #178
AnimalMuppet wrote: post #158

Earlier quoted context omitted.

Let's say that C produces 100% of the performance available. How much does Go produce? Maybe 90%? How much does Python, say, produce? 25%? So going from Python to a compiled language produces a huge gain, and going from Go to C produces a little bit more. But why not get all the gain? Well, sure, if performance is the only thing you care about . But it usually isn't. You might also care about networking, or multithre…

Yes, that's my point. It is premature optimization, because you do not have a use case for such performance. Instead you might want Python's extensive numerical libraries, or you enjoy its quick prototyping capacities. The same way that you do not always go for C, and sometimes prefer Go, because of non performance related requirements. That's why saying a compiled performant language should be default is not logic I…

The only reason python has numerical libraries (e.g. numpy) is because they are written in C.

Re: Learning Go by porting a medium-sized web back end from Python

#188

Post by Twirrim »

4c2383f5c88e911 wrote: post #21

I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…

> - stability: the language itself is fine on that, but the ecosystem really isn't. The fact that they don't even have the package management quality of python (which I find awful already) is baffling. I don't even know how they could think "yeah, github-importing is a good idea, let's do it". Go is eight years old tomorrow and you still have to rely on third-party tooling to do proper imports that don't burn your house.

Google operates on a mono-repo basis, as I understand it (from speaking to ex-googlers.) All libraries etc. etc. all under one big repo. If you think about how that would appear to end tooling consuming it, the approach taken with imports makes sense. It's lousy for the rest of us outside of the google mono-repo ecosystem, but it does make sense.

Re: Learning Go by porting a medium-sized web back end from Python

#189

Post by richardknop »

sidlls wrote: post #97
_Codemonkeyism wrote: post #42

Earlier quoted context omitted.

Developers have the gain, company suffers, developers move on for higher salary with more skills, CTO is in it, doesn't fullfil his duty towards the company or investors, CEO has no clue and doesn't manage the CTO. The story I see over and over again as a startup CEO consultant.

Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody else on the team has experience with, and which isn't used anywhere else in the company, and to solve a problem that is perfectly well solved (in both development time and performance) with the language and tooling we already use. As far as I can tell this eng…

But this also might be a problem of a company not providing any improvement / career prospects for your programmers.

If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc).

You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it.

I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be.

You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things.

It's like that analogy I have heard over and over again.

CFO asking CTO: What happens if we invest in developing / training our people and they leave?

CEO replies: What happens if we don't and they stay?

Re: Learning Go by porting a medium-sized web back end from Python

#190

Post by remus »

adamkittelson wrote: post #168
lunch wrote: post #107

Earlier quoted context omitted.

Context: I've been programming in Go full-time for the last 2 years and come from a Python and C# background. > No Generics The lack of generics was something I was hung up on, too, but TBH I haven't found myself reaching for them for a while now. > Error handling This is not a problem for me, either. I can easily handle different `error` types and if I want to provide more context I pull in github.com/pkg/errors > g…

> The lack of generics was something I was hung up on, too, but TBH I haven't found myself reaching for them for a while now. I mean, if you lose an arm you probably stop trying to pick stuff up with your missing hand after a while too, doesn't mean it's not better to have two arms.

Are generics as useful as an arm? I think that's a slight exaggeration. I'm sure they're useful in a lot of situations but there's a lot of programs you can write where their absence is neither here nor there.
Post reply on HN