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

131–140 of 207 posts

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

#131

Post by warent »

laumars wrote: post #115
PopsiclePete wrote: post #110

Earlier quoted context omitted.

>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 o…

> With this statement, you've shown you have close to 0 Go experience. With that statement you've shown yourself to be an arrogant dick so I stopped reading. Maybe when you're in the mood to play nice I'll link you to some of the stuff I've written in Go over the last 6 years. Some of them are pretty cool - if I do say so myself - and definitely not beginner projects. For what it's worth, we all have the occasional b…

When having an off-day, I find it's sometimes best to pause before saying something. The irony of this comment is really unfortunate

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

#132

Post by didibus »

fellowmartian wrote: post #104
hasenj wrote: post #64

Earlier quoted context omitted.

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.

I think any of the JVM languages like Java, Kotlin, Clojure, Scala, Eta, etc.

The JVM as far as I know is still the runtime king, faster then Go.

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

#133

Post by randomdata »

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 suggests that such automation fell apart in practice.

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

#134

Post by joshuamorton »

rjammala wrote: post #80
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.

I feel like this is true for any language though.

Once you write a well designed, well tested, and feature complete piece of software, you can deploy it and forget about it unless the server it's running on breaks.

Go isn't special in that regard, unless there's something that makes Go easier to write, test, or deploy, which might be the case, but you haven't supported that.

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

#135

Post by weberc2 »

mrhwick wrote: post #120
weberc2 wrote: post #69

Earlier quoted context omitted.

I haven't had a problem with testing in Go, but I also don't mock many things. Most things that should be mocked are already interfaces in my code. My biggest grievances with Go are its limited type system and dependency management. Unlike most[^1], I don't need semantic versions--I just need deterministic, reproducible builds, and for that, vendoring is fine in theory, but Go's tooling around it needs work. I love t…

Have you used dep? https://github.com/golang/dep

I have, but early on and not much since. I forget my particular issues; I just remember at the time there didn't seem to be a way to do what I wanted (I think it was adding docker as a dependency).

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

#137

Post by joshuamorton »

_Codemonkeyism wrote: post #92
oweiler wrote: post #70

Earlier quoted context omitted.

There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion

I do not argue that Kotlin is a nicer and a language with more features that are useful. What of these would you call "more expressive"? I'd agree with sealed classes, they express a limited set of possible classes. Perhaps tail recursion as I can express problems in way of recursion without stack overflows. I don't think coroutines are more expressive than Futures/get, only a runtime optimization for many concurrent…

Async/await coroutines (C#, python, ECMAscript 7) are much nicer than futures, at least ime. I think that in terms of expressiveness of async code it goes

callbacks -> futures/promises -> coroutines

Because callbacks are a completely different style of code, your async looks totally different. Futures and promises are better, but still make it difficult to ever break out of the async context, coroutines make the difference between async and normal code nonexistant, and allow clean escape from an async context.

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

#138

Post by laumars »

warent wrote: post #131
laumars wrote: post #115

Earlier quoted context omitted.

> With this statement, you've shown you have close to 0 Go experience. With that statement you've shown yourself to be an arrogant dick so I stopped reading. Maybe when you're in the mood to play nice I'll link you to some of the stuff I've written in Go over the last 6 years. Some of them are pretty cool - if I do say so myself - and definitely not beginner projects. For what it's worth, we all have the occasional b…

When having an off-day, I find it's sometimes best to pause before saying something. The irony of this comment is really unfortunate

Yeah, it is unfortunate. My ranting was born from frustration that HN used to be a refuge from the usual pointless egotistical jibes as seen on other forums and social platforms. But over the years the quality of counterarguments has slowly been lowering to the level where it's now commonplace for people to make judgemental remarks about a persons ability based solely on a solitary semantical error (I obviously get the distinction between the two - I just wasn't aware they were described differently in literature).

I have amassed a large body of real world projects under my belt over the last 3 decades and have used Go for 6 of those years. I've written some pretty interesting stuff in Go like file systems compiled against FUSE and compilers. Yet I by no means consider myself an expert in anything - least of all Go - as to do so would imply I'm not open to learning something new (even basic things I somehow missed during my initial studies). Despite that I still find it highly offensive and unnecessary for someone who knows nothing about me to say "you have close to 0 Go experience." when I've clearly demonstrated and described various Go-isms prior to his or her remark.

Edit: weirdly I've got more down votes for this comment than my last one. I guess some people think rudeness is acceptable. Sad times.

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

#139

Post by TheAceOfHearts »

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…

Surely there's tools to bundle python apps? I'm not as familiarized with the python ecosystem, but with node you can use browserify or webpack to bundle an app into a single JS file, or pkg [0] to generate a single executable.

Some languages have even more powerful tools for that sort of deployment. One of the best examples I've seen is distillery [0], an Elixir package which allows for hot upgrades. That means you can just copy a single a file and upgrade without having to take anything down.

[0] https://github.com/zeit/pkg

[1] https://hexdocs.pm/distillery/getting-started.html

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

#140

Post by skj »

fellowmartian wrote: post #101
acdha wrote: post #81

Earlier quoted context omitted.

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 abstraction…

I pull my joy from the task being accomplished rather than the syntactic swirls I sketch out while accomplishing it.
Post reply on HN