Live data from Hacker News

Why We switched from Python To Go

medium.com

71–79 of 79 posts

Re: Why We switched from Python To Go

#71
post #56
post #19

Earlier quoted context omitted.

"If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you." People change. Dynamic typing was popular some years ago, but opinions have changed.

This is weird. It's not a matter of what was popular a few years ago. Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so. And so will the flamewars about them, unfortunately.

"Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so."

That's a non sequitur.

Re: Why We switched from Python To Go

#72
post #43
post #35

Earlier quoted context omitted.

For the majority of my career I haven't worked on greenfield projects. I've been debugging, modifying, and otherwise maintaining pre-existing projects. As a result I've grown to really dislike frameworks that autowire things together. The very same features that made it easy to get started make them harder to maintain going forward. It turns out following the code in your own codebase is easier than following the cod…

Reading your comment reminded me of this great talk by Christin Gorman about maintainable code: https://vimeo.com/138774243 (Jump to 25:50 for an anecdote about maintaining a "well engineered" system)

Oh my goodness. She totally captured my career in a nutshell. There is nothing quite like running into an interface while you are trying to trace a problem. Your head just immediately hits the desk and then you go looking for aspirin.

Re: Why We switched from Python To Go

#73
post #58
post #35

Earlier quoted context omitted.

For the majority of my career I haven't worked on greenfield projects. I've been debugging, modifying, and otherwise maintaining pre-existing projects. As a result I've grown to really dislike frameworks that autowire things together. The very same features that made it easy to get started make them harder to maintain going forward. It turns out following the code in your own codebase is easier than following the cod…

Just my personal anecdote, but I recently had to port the backend of one of my pet projects away from ruby due to performance issues - parsing around 50MB of string in ruby isn't an amazing idea. So I figured the natural choices there would be go because it's new and in demand, and java because I have a couple years of java se experience. So, figured, let's evaluate java... and I just failed to comprehend the spring…

Yeah, Spring is one of the worst offenders I've seen. At my current job I'm working on code written with Spring and debugging takes probably 5 times as long as it should.

Re: Why We switched from Python To Go

#74
post #54
post #53

This article of full of fluff. Citing a static type system as a point for Go? Go's type system is about the weakest of any popular, statically typed language being written today. It's full of escape hatches.

> It's full of escape hatches. For people who are accustomed to Python or Javascript this is a feature, not a bug.

It's neither, it's a bad design decision that they were forced to make because the type system isn't expressive enough.

Re: Why We switched from Python To Go

#75
post #71
post #56

Earlier quoted context omitted.

This is weird. It's not a matter of what was popular a few years ago. Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so. And so will the flamewars about them, unfortunately.

"Static typing didn't "stop" being popular while dynamic typing "was" popular, nor have opinions "changed". Dynamic and static typing have coexisted almost the entire history of programming and will continue to do so." That's a non sequitur.

How so? It was directly addressing this:

> Dynamic typing was popular some years ago, but opinions have changed.

Re: Why We switched from Python To Go

#76
post #4

> #2 Static Type System It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you. > For example it has http, json, html templating built in language natively So does Python with urllib and json modules. I don't know if it has…

> It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place.

Sure, if your only or most important criteria is static typing. But you can view static typing as desirable, but prefer Python because it has more important positive traits that no alternative with static typing has, so you sacrifice static typing for them. But then Go comes along, that is good enough on those criteria and has static typing, and you prefer it.

Of course, Python now has optional static typechecking available anyhow.

Re: Why We switched from Python To Go

#77
post #14
post #4

> #2 Static Type System It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you. > For example it has http, json, html templating built in language natively So does Python with urllib and json modules. I don't know if it has…

About the static type system: When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java. Think about someone that knows Python and have to use Java, then they think that all static type languages are as a pain in the ass. So they begin disliking static type systems when they really just hate the Java's one. And so the moment they are using Python and start p…

> When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java.

Go's system throws out a lot of the ceremony of older Java, but also throws out a lot of the benefit; many modern languages (including recent Java) also use type inference and other features to reduce static typing ceremony, but retain at least the power of the classic Java type system, and often far more.

Go's type system seems to be a poor benefit-to-ceremony trade-off.

Re: Why We switched from Python To Go

#78
post #45

As an aside, the greatest thing about Python is StackOverflow one-liner solutions to common problems. How do you find your developer productivity fares in Go? To take a simple example, I was experimenting with C++ and had the simple task of "reading in a CSV". This simple C++ task does not have a nicely formatted, pre-approved, community rubber-stamped, best practice 500 green ticks StackOverflow top accepted answer…

Right, it's almost impossible to get any work done without having pre-approved code to copy and paste from. This is especially true for highly complex problems like reading a CSV file. Those virtually require the presence of promiment PyCon developers as no one else can possibly get this right. Only use code with at least 500 green ticks.

I always appreciate a healthy dose of sarcasm, but I think you're missing the wider point about the great community we have in Python - not only in terms of the ecosystem, but also continuous guidance on best practice for common problems.

Re: Why We switched from Python To Go

#79
post #46

So this lists the usual stuff that people who aren't experts in any system think are good reasons to pick one or the other for. 1. The single binary is attractive, but with modern virtualenv and wheel and anylinux wheel files this is far far less important than it would have been 10 years ago. I count this as irrelevant but probably python's library packaging is confusing to a beginner. 2. Static types don't really h…

1. There are other ways to do it, yes. But "just upload anywhere and it works" is not just for server, but for tooling. That what comes out of the compiler can be used everywhere is a huge selling point that also, unfortunately, helped PHP even though there were other ways to do that too. 2. I could not disagree more. Just costs between int, float, int64, and double cause lots of bugs. Go makes costs explicit, which…

autocorrect. "costs" should be "casts"
Post reply on HN