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

Why we switched from Python to Go

getstream.io

Post reply on HN
Print view View original

21–30 of 406 posts

Re: Why we switched from Python to Go

#21

Post by camus2 »

carlisle_ wrote: post #2

> Python, Node and Ruby all have better systems for package management Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages. Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're…

> Go also doesn't have the problem of conflicting system level packages.

Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others.

> Go doesn't have to deal with interpreter dependencies

As long as Go is forward compatible this will old true, but I don't think this was the point of the comment.

'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool.

There is a reason why some gophers are working on an actual package manager...

Re: Why we switched from Python to Go

#22

Post by teraflop »

kevinconaway wrote: post #18
jancsika wrote: post #11

> Our largest micro service written in Go currently takes 6 seconds to compile. What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?

Two large projects that I know of are CockroachDB and Influxdb A quick glance seems to indicate that cockroachdb takes about 9 minutes [1] and infuxdb about 15 minutes [2] [1] https://teamcity.cockroachdb.com/viewLog.html?buildId=380603... [2] https://circleci.com/gh/influxdata/influxdb/tree/master

That build log for CockroachDB takes a lot longer than a normal build, because it's generating releasable artifacts for multiple platforms, which means running the entire build process multiple times. Also, the build time is dominated by a few vendored C++ dependencies (mainly libprotobuf and libsnappy) which are built using CMake.

On my system, building just the Go code for the latest version of CockroachDB (about 360kloc) takes 24 seconds.

Re: Why we switched from Python to Go

#23

Post by btym »

dundercoder wrote: post #3

Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compare…

Second this. I've been playing with Nim for the past couple months and love it. The biggest downside has been lack of tooling.

Re: Why we switched from Python to Go

#24

Post by mjevans »

The only thing actually missing from Go's standard library that I've wanted is an abstraction of 'native' UI things (assuming you're compiling for a graphical platform).

For portability there is shipping your a widget set (QT is OK for this if your licencing needs are compatible with either case).

Re: Why we switched from Python to Go

#25

Post by btym »

tschellenbach wrote: post #16
dundercoder wrote: post #3

Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compare…

I never heard of Nim, something to try out at some point. What's your favorite Nim tutorial?

Nim by Example[0] is a great introduction. The blog mentioned in the OP also has a writeup that explores some of the tooling[1]. After that, the official tutorial[2] is a comprehensive dive. The standard library documentation is sometimes lacking but is easily searchable.

[0]: https://nim-by-example.github.io

[1]: http://howistart.org/posts/nim/1/

[2]: https://nim-lang.org/docs/tut1.html

Re: Why we switched from Python to Go

#26

Post by camus2 »

dvt wrote: post #13
omegaworks wrote: post #4

>Reason 3 – Developer Productivity & Not Getting Too Creative There is a time and place for these tools. A part of managing a team is ensuring there are good practices around "getting creative" and that there is a clear rationale. Python's metaprogramming came in handy for helping us provide a high level syntax to work with our data model.

I'm happy that Python's metaprogramming came in handy for you and your team, but Python's propensity for DSLs is one of the reasons I loathe it so much. I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug.

> I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug.

What do you think struct-tags are? it's not like Go is free of DSL either. In fact the std lib itself uses them. Let's not pretend Go is without fault on that matter.

Re: Why we switched from Python to Go

#27

Post by squiguy7 »

catnaroek wrote: post #5

> Another great aspect of concurrency in Go is the race detector. This makes it easy [emphasis mine] to figure out if there are any race conditions within your asynchronous code. Am I reading correctly?

It can be a bear to try and track down some race conditions but at least it will not report false positives. However, it will not catch all race conditions or data races you may have.

Re: Why we switched from Python to Go

#28

Post by btym »

jancsika wrote: post #11

> Our largest micro service written in Go currently takes 6 seconds to compile. What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?

Docker takes about 10m to build: https://jenkins.dockerproject.org/job/docker/job/docker.gith...

Kubernetes takes about 16m: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/...

Re: Why we switched from Python to Go

#29

Post by squiguy7 »

jancsika wrote: post #11

> Our largest micro service written in Go currently takes 6 seconds to compile. What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?

Building pure go applications can be speedy but as soon as you introduce cgo, you can expect these times to inflate pretty significantly.

Re: Why we switched from Python to Go

#30

Post by setheron »

How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity".

Let me give a specific example where moving to Go really helped our tooling:

Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when an operator has already ssh'd within the region (the tool is installed on hosts as well -- so that long running tasks can be performed).

It was easy to create HTTP clients that easily tunnel through an SSH connection via Go's Dialer interface (present in the net & ssh package) or just directly if no tunnel was needed.

Post reply on HN