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

101–110 of 207 posts

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

#101

Post by fellowmartian »

acdha wrote: post #81
fellowmartian wrote: post #46

Earlier quoted context omitted.

Using a compiled language is not a premature optimization if you're not sacrificing expressiveness. With that said, Go is not the best choice. Like, for anything.

Go isn't my first choice but “like, for anything” reeks of dogma. Can you explain your rationale?

That was just a harmless (I hope) hyperbole. I've actually used Go a couple of times for image processing workers and such. And that's when I developed my distaste for this language.

I mean, I get it, it's easy to pick up and use. Coroutines and channels are useful, and make easy to write async stuff.

But god damn, it's so dull and boring, there's no joy in it. We're programmers, we're supposed to extract abstractions and express them in the code we write. And IMO your language should definitely try to help with that.

Instead, Go wants you to do err, value = ..., if err == nil { ... } on almost every single line. You can't adequately compose stuff. Well, you can try, but you quickly run into its ugly, verbose syntax for anonymous functions or lack of generics.

Maybe I'm not getting something, maybe it's just not for me, I dunno. But next time I need high performance compiled language, I'll use Swift or maybe even Rust. Also I think Scala Native is somewhat stable already, gotta look into that.

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

#102

Post by monktastic1 »

hasenj wrote: post #63
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…

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 talking about porting existing code. Sometimes it's the best use of time, sometimes it's premature.

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

#103

Post by monktastic1 »

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.

> There's 50% more code to maintain

Given that Go is similarly verbose to Python, probably 100% more code.

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

#104

Post by fellowmartian »

hasenj wrote: post #64
fellowmartian wrote: post #46

Earlier quoted context omitted.

Using a compiled language is not a premature optimization if you're not sacrificing expressiveness. With that said, Go is not the best choice. Like, for anything.

What would you choose instead?

Depends. If we're talking about high performance, yet expressive language without a steep learning curve, I say Swift. The only major drawback right now is lack of pure Swift AWS SDK. And unfortunately, AWS team has no plans to write one, yet.

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

#105

Post by jerf »

laumars wrote: post #100
jerf wrote: post #85

Earlier quoted context omitted.

"io.Reader and Writer are interface{}'s[1]." No, they are interfaces , but they are not interface{} s, the interface that is met by having no methods and is therefore met by everything. Nobody is complaining about the use of interfaces that declare a useful set of methods, and are meant to be used when the set of methods is all the target code cares about. They may complain about some of the edges around them (no sup…

[deleted]

"io.Reader is literally an interface{} though. I think what you're referring to is the other packages that define their own Reader's, ie using structs with methods, those are referred to as interfaces despite not literally being an interface{}."

That appears to be a definition unique to you that I have never seen from anyone else before, including the Go designers. io.Reader is an interface, no braces. Its full expansion would be interface { Read(p []byte) (n int, err error) }, and it is incorrect to substitute that for interface{} as that is a very different thing. Structs that implement the interface are, well, structs that implement the interface. interface{} is specifically reserved for discussion about the empty interface.

For instance, do a browser find for "interface" in https://golang.org/doc/effective_go.html ; you will find the documentation frequently referring to "interfaces" and that interface{} is reserved for the empty interface.

For the final proof of this, note how confusing it is for you to be reading the Go criticism as being about the use of interfaces-in-general in Go. Why would that provoke such a reaction? The answer is that people aren't talking about the feature, they are specifically referring to the number of places interface{} appears, the "Any" type, the "I don't know what's in there at all" type. It's not the use of interfaces in general, it's the way that suddenly one goes from a decent enough statically-typed language to a not-all-that-great dynamically-typed language when interface{} appears. (I disagree with the HN gestalt about the severity of this problem, but I understand it and still agree it's a non-zero problem.)

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

#106

Post by [deleted] »

jerf wrote: post #105
laumars wrote: post #100

Earlier quoted context omitted.

[deleted]

"io.Reader is literally an interface{} though. I think what you're referring to is the other packages that define their own Reader's, ie using structs with methods, those are referred to as interfaces despite not literally being an interface{}." That appears to be a definition unique to you that I have never seen from anyone else before, including the Go designers. io.Reader is an interface, no braces. Its full expan…

[deleted]

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

#107

Post by lunch »

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…

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

  > gofmt
gofmt is great

  > go test
go test has been totally sufficient for me and I was quickly writing and running tests. The testing package itself is builtin and writing tests is dead simple.

  > dep / dependency stability
Dependency management has been a huge PITA with Go and is my largest complaint. Personally, I've used everything go GB vendor, godeps, glide, and now dep. dep has been Just Working for me and is decent enough working on a team. As for dumping the dependency code in your source tree-- it lives in a folder called ./vendor so it's easy enough to not look at it.

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

#108

Post by bischofs »

I am doing some python to go conversions for some performance gains in parts of my stack - I really like it so far because of how they brought some of the perks of languages like python into a compiled language. One thing I really miss though is ipdb.

The Delve debugger still doesn't let you run functions and I miss all the autocomplete fun with ipdb. I hope they can make go a little more friendly to debugging in general.

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

#109

Post by dmoy »

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…

To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.

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

#110

Post by PopsiclePete »

laumars wrote: post #78
ptman wrote: post #75

Earlier quoted context omitted.

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

[deleted]

>io.Reader and Writer are interface{}'s[1].

With this statement, you've shown you have close to 0 Go experience.

* interace{} - a place-holder for a value of "any type". It means "a value that satisfies the empty interface", i.e. an interface with no methods. All types implement it. To do anything with the actual data it encapsulates, you have to do a type assertion to unbox the value. The type assertion will panic or return an error if the type assertion is incorrect. This is something like C's void , or Java's Object.

io.Reader, io.Writer - these are interface types that specify a set of methods that must be implemented by another type in order to satisfy that interface. These are akin to C#/Java's interfaces, but are less restrictive in the sense that any type in Go can implement them, not just "classes". E.g., http.HandlerFunc - a function type that implements the http.Handler interface.

Post reply on HN