Live data from Hacker News

Why we switched from Python to Go

getstream.io

211–220 of 406 posts

Re: Why we switched from Python to Go

#211

Earlier quoted context omitted.

Rust is descended from ml? Isn't Rust a algol based language? Is it functional?

OCaml was a really strong influence on Rust. The first Rust compiler was written in OCaml. Rust's traits are also similar to Haskell's typeclasses.

Rust also has discriminated unions, structural pattern matching and local type inference.

Re: Why we switched from Python to Go

#212
post #92

Earlier quoted context omitted.

That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What is (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.

Rust is descended from ml? Isn't Rust a algol based language? Is it functional?

In addition to typeclasses, Rust has discriminated unions (ergo algebraic datatypes), structural pattern matching, first-class functions, local type inference, and an exclusive/nonexclusive dichotomy of references which serves as a useful proxy for mutability.

Re: Why we switched from Python to Go

#213
post #65

Earlier quoted context omitted.

elaborate?

I've occasionally had things spontaneously break. Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, which somehow prevented the AMI I was using from installing some of its requirements. Had to add those packages to my project requirements. Also some of the data analysis packages don't work with virtualenv.

> Most recently the cryptography package just stopped installing on deployment. Had to add a pip upgrade on deploy, [...]

Erm... Why the heck are you running pip when deploying software? O_o It should be a build step, not a deployment step.

Re: Why we switched from Python to Go

#214
post #205

Earlier quoted context omitted.

IMO Go has poor primitives that make even straightforward code needlessly complicated. Slices are probably the worst. Compare Python's way to inserting a value into a list: a.insert(i, x) With the way that the Go docs suggest: a = append(a[:i], append([]T{x}, a[i:]...)...) Sorting and for-range loops are other examples.

I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.

WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.

Re: Why we switched from Python to Go

#215
post #161

Earlier quoted context omitted.

I tried using Go this weekend and basically just abandoned it when I learned that it only had 'generic's for three built-in types and other than that you are forced to essentially dynamic cast everywhere. I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.

It seems like the domains where Go is used often don't make heavy use of custom containers or data structures, so that makes the pressure on the language makers lower than it would otherwise be.

Or the other way around.

Re: Why we switched from Python to Go

#216
post #68

Earlier quoted context omitted.

The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application. My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and buil…

Yeah, plus even if performance is important, the app layer isn't necessarily the best place to optimize. It doesn't really matter how fast you sprint between database calls if the database and its IO dominate your site's performance profile, which they often do...

If that's really the case, why do people spawn multiple instances of their app?

A python application can be anywhere from 10x to 50x slower than a native application. It also probably consumes at least 5x more memory.

Writing the same app in a compiled language is not even an optimization. It's just baseline work to ensure the code is not super slow.

Like, if you know you will sort a list of 10 items, choosing quicksort from the stdlib instead of bubble sort is not even an optimization. It's just common sense.

Re: Why we switched from Python to Go

#217

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…

Agreed completely. We're in the process of porting our Python 'shim' (aka agent, at https://Userify.com - plug SSH/sudo key management) to Nim right now, so that we can provide a fully static shim for CoreOS and other minimal distros, and eventually Windows; there are a few languages that can do this cleanly, such as Go, Ocaml, and Lua, but Nim is just blindingly fast and actually pretty fun to code in. Great stuff.

Can you please add your company here? :) https://github.com/nim-lang/Nim/wiki/Companies-using-Nim

There are some companies using Nim, but they're not in this list

Re: Why we switched from Python to Go

#218
I'm surprised to see that people choose anything other than C++ if they care about performance. Are you really trying to profile and optimise python and go? It will never be worth it! Just write the same thing in good modern C++ and you get an automatic 100x speed up for most cases. Then optimise to reach the absolute limits of the hardware. Python and go it seems!

Re: Why we switched from Python to Go

#219
post #205

Earlier quoted context omitted.

I prefer to the Go way. The python way gives people the impression that the insert operation is cheap. In fact, it is not.

WTF?! Isn't the point of an abstraction to make simple what is complex? Insert into a list should always be like the python example. If go's standard list doesn't have that, maybe it's time for someone to write a better library.

The insertion operation on slices is expensive and is not recommended to be used frequently. If you use it frequently, please rethink and redesign your data structure, for example, use a list instead.

Re: Why we switched from Python to Go

#220
post #183

Wait just one minute, Thierry... Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python. You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've…

It reads like a reasonable rationale for why they switched to Go. Uninteresting maybe, but certainly no village burning. You sound indignant for some reason that isn't related to the content of the article.
Post reply on HN