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

71–80 of 207 posts

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

#71

Post by sethammons »

trumpeta wrote: post #3

Recently I have had the opportunity to write a microservice in Go. It was a very refreshing experience switching from Scala. Go is a lot faster to compile and runs with a far smaller footprint. The channels are nice. On the other hand the testing feels wrong because its so annoying to do mocks. And don't even get me started on the dependency management. Overall Go feels to me like some version compiled PHP with bette…

Chances are, if you are using mocks in Go, you are doing it wrong. Functions should take interfaces (not interface{}, but interfaces that list methods) and return structs. In your tests, you create a fake that meets the interface and pass that to your function under test.

If you have to test file io or DB interaction, you can either do the adapter pattern or, as I prefer, just actually use the filesystem and DB but with some test infrastructure around it.

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

#72

Post by benhoyt »

crdoconnor wrote: post #56
Dowwie wrote: post #39

What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…

>they're generally a premature optimization This example actually seems to be the opposite of an optimization. There's 50% more code to maintain and there appears to be almost no appreciable benefit to compensate for that.

No, there was no appreciable user benefit, and that was intended. To respond to others: it wasn't a "premature" optimization, because it wasn't any kind of optimization. The sole benefit in this case was for me to learn Go programming -- and I noted that in the article title and intro. :-)

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

#73

Post by jnwatson »

reacharavindh wrote: post #2

I'm at the same spot myself, trying to learn Go by building a simple web app. Your article was a refreshing read to me. One extra thing that is the major motivation for me to go to Go is the ability to deploy as a single God damn binary and not deal with dependancies and pip. pip and counting on OS repositories may be the right thing to do, but it is just too cumbersome. I have an air gapped setup at work, and there…

I'm in a similar situation with Python and deployment that has no internet. We have a solution that works well.

The philosophy is to think of Python as a compiled language and then everything works.

The CI system make the "image" and that gets pushed. In our case we make a virtualenv but you could also use pyfreeze.

Works like a charm.

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

#74

Post by bn__ »

_Codemonkeyism wrote: post #42
Dowwie wrote: post #39

What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…

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.

And without developers there would be no product at all and no "work" for either CEOs or consultants.

This Ayn Rand thing becomes more and more attractive every day...

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

#75

Post by ptman »

laumars wrote: post #67
zaarn wrote: post #23

Earlier quoted context omitted.

>- 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) Depends on what you do. I've written a good chunk of go code and interface{} is the rare exception rather than the rule, usually employed where a user might supply arbitrary types (ie a unmarshaljson like function) But if you do a website or webapp, 99…

> But if you do a website or webapp, 99% of your code is not using interface{} in it's methods. That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package. If you want to gzip your output, then you'll use interface{} with your writer. To be fair, I think interface{} gets an almost unfair amount of hate. While it is fscking annoying when passing ar…

I don't see anything about interface{} on https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.

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

#76

Post by drakonka »

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…

I am new to go and am especially curious about what you find lacking on go test. Could you elaborate on that point? I've found it nice to work with so far and wonder what kinds of issues others have had/what I can watch out for. Thanks!

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

#77

Post by narimiran »

reacharavindh wrote: post #62
beagle3 wrote: post #28

Earlier quoted context omitted.

Nim has everything nailed down except the ecosystem/commercial backing; It does have some of those, but not to the extent that I would blindly tell you they are there. It's as fun as writing Python (with a similar syntax), but it has essentially all the goodies you want from Lisp when you need them, runs as fast as equally optimized C, produces standalone native binaries, _or_ standalone JavaScript if that's your thi…

Cheers to Nim. I'm learning it in my spare time for fun. However, I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon.

> I will not consider using it for anything more than toy projects until it hits 1.0. Hopefully soon.

It should happen soon (TM), but from what I understand it will be just another version, just this time renamed to 1.0 - this basically means you could start using it more seriously even now.

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

#78

Post by laumars »

ptman wrote: post #75
laumars wrote: post #67

Earlier quoted context omitted.

> But if you do a website or webapp, 99% of your code is not using interface{} in it's methods. That's not really true. If you want an SQL database to back your website, then you'll deal with interface{} with Go's sql package. If you want to gzip your output, then you'll use interface{} with your writer. To be fair, I think interface{} gets an almost unfair amount of hate. While it is fscking annoying when passing ar…

I don't see anything about interface{} on https://godoc.org/compress/gzip , only byte slices, io.Reader and io.Writer.

[deleted]

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

#79

Post by acdha »

nspattak wrote: post #47
_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.

So if I get your argument correctly: Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool. The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working o…

> Developers learn a new language that is faster to develop, safer and faster to run than existing solutions

Would that it was that simple. Most of the time I've seen this it's been more like “writing new code is fun, fixing a bad design in our current code is too much like work” without factoring in the cost of rewriting, testing, optimizing all of the code which wasn't a problem relative to simply replacing the hotspot which was.

Yes, sometimes a codebase is so bad that there's nothing of value to be preserved but that's pretty rare and unless it's some turd from an acquisition or consultants the odds are extremely high that the broken business culture responsible for the first bad codebase will cause just as many problems the next time around.

That does happen but in my experience it's far less common than fanboyism or poor architectural/analytic skills — things like spending months rewriting a Python program in Go for a single-digit percentage gain because someone on HN said the magic pixie dust would make it faster and nobody checked whether it was I/O bound, spending most of its time in OpenSSL, etc. I've seen people propose rewriting code in C rather than optimize a database query because Real Programmers use hard things like C whereas SQL is beneath them. (I wish I was making that up)

To be clear: I'm not saying that Go isn't a perfectly fine choice, only that our field is more prone to fads than we like to admit and most of the things which cause bugs or make people wait are decisions higher in the stack.

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

#80

Post by rjammala »

Dowwie wrote: post #39

What I've noticed, and personally experienced, about these porting projects is that they're generally a premature optimization but are a great way to learn a new language. The gains from a port are largely intrinsic in nature, residing with the programmers. However, systems and operations largely carry on just fine with the original language chosen. Only one story comes to mind where a programmer had a legitimate pro…

How about this: once you write code in Go and test it well, you can deploy it and forget about it unless there is a hardware issue? I recently ported some C++ code to Go which processes 8 Billion events per day flawlessly.
Post reply on HN