Why we switched from Python to Go • Hacker News Board

Re: Why we switched from Python to Go

#311

Post by igouy » Wed, Oct 18, 2017, 3:40 PM UTC

riku_iki wrote: post #70

jaequery wrote: post #64

Earlier quoted context omitted.

well then why go with any of them when erlang and elixir has them all beat in terms of performance AND stability? let alone the power of concurrent processes it can handle that none of those languages can hold a candle to. why? :)

Because your statements are very challengeable. Erlang is much slower in raw performance than both go and jvm: https://benchmarksgame.alioth.debian.org/u64q/erlang.html Async approache similar to Erlang was reproduced for Java and Go already: https://akka.io

> … slower in raw performance…

… and "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."

FAQ 1.4 What sort of problems is Erlang not particularly suitable for?

http://erlang.org/faq/introduction.html#idp32150096

Re: Why we switched from Python to Go

#312

Post by alien_at_work » Wed, Oct 18, 2017, 3:42 PM UTC

it wrote: post #91

I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've s…

The reason I, personally, don't like it is it's basically a slight improvement over C's error handling when everyone else has substancially improved. In C, basically every function could fail and you needed to check the return code. In some cases you'd need to make up an impossible value to return to signal error and in some cases (e.g. functions returning binary data) you would need some other global variable to be tested. So Go fixed all the error signalling issues bit still has the problem of needing to check every function return... which no one is going to do. In C, if printf fails that's usually just going to happen without the program noticing. In any language with more modern error handling (note: not just exceptions) printing can't silently fail.

Re: Why we switched from Python to Go

#313

Post by igouy » Wed, Oct 18, 2017, 3:43 PM UTC

elcritch wrote: post #156

riku_iki wrote: post #70

Earlier quoted context omitted.

Because your statements are very challengeable. Erlang is much slower in raw performance than both go and jvm: https://benchmarksgame.alioth.debian.org/u64q/erlang.html Async approache similar to Erlang was reproduced for Java and Go already: https://akka.io

You're right that Go/Java have async style similar to Erlang. But the majority of production systems today that these languages run is some sort of web application. In this area, the Erlang VM holds its own pretty well, especially for websockets [1]. In that study Elixir's memory usage is higher, but total connections were almost identical to Go. It'd be great if there were better benchmarks for common use cases of v…

> It'd be great if there were better benchmarks for common use cases of various languages

Somebody should make those.

(People may have different ideas about which use cases are common).

Re: Why we switched from Python to Go

#314

Post by curun1r » Wed, Oct 18, 2017, 3:47 PM UTC

tshannon wrote: post #260

majewsky wrote: post #245

Earlier quoted context omitted.

Yeah, but 99% of libs won't return anything with additional accessible structure.

Yeah I think the point is, errors shouldn't be overloaded with too much extra structure. They should be errors. If additional structure is needed, it should probably be sent separately via the common multiple returns idiom in Go.

Additional structure like, say, a numeric error code? An HttpError could definitely contain the corresponding status code.

But I think the bigger point is that, for libraries, errors should be an enumerated set of possible error conditions, not strings. You say "additional structure", I say the duplicate filename, the invalid email address or, crucially, the error that caused the error...chaining errors is very useful. The multiple returns idiom in Go may make this possible, but it's hacky and strictly worse than languages that can utilize generics and a more richly-typed set of errors.

Re: Why we switched from Python to Go

#315

Post by ngrilly » Wed, Oct 18, 2017, 4:05 PM UTC

the_mitsuhiko wrote: post #263

it wrote: post #91

I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've s…

> I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. The biggest reason for me is the inability to get stacktraces to where an error comes from.

Work is in progress to improve that: https://research.swtch.com/go2017#error

Re: Why we switched from Python to Go

#316

Post by ngrilly » Wed, Oct 18, 2017, 4:07 PM UTC

piinbinary wrote: post #97

it wrote: post #91

I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've s…

I think the semantics of Go's error handling is pretty good, but the syntax could use work.

There is an ongoing reflexion on making error handling less verbose, but as you can see in the link below, there are tradeoffs, as always:

https://github.com/golang/go/issues/21161

Re: Why we switched from Python to Go

#317

Post by Can_Not » Wed, Oct 18, 2017, 4:09 PM UTC

JelteF wrote: post #257

3pt14159 wrote: post #238

Earlier quoted context omitted.

Hey Jelte, quick question: Did you guys try Numba or Cython? Or did you guys figure that the language simplification that Go provides would be worth it even if the performance considerations were similar?

No, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us. Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite…

Did you ever consider Elixir?

Re: Why we switched from Python to Go

#318

Post by ngrilly » Wed, Oct 18, 2017, 4:11 PM UTC

dguaraglia wrote: post #119

piinbinary wrote: post #97

Earlier quoted context omitted.

I think the semantics of Go's error handling is pretty good, but the syntax could use work.

Something as simple as allowing the use of multi-result calls in if statements would make a huge difference. Being able to write "if err := blah(); err != nil { ... }" is great (although it does kind of hide the original call.)

This has been possible for years ;-)

Re: Why we switched from Python to Go

#319

Post by steveklabnik » Wed, Oct 18, 2017, 4:26 PM UTC

StavrosK wrote: post #301

sjellis wrote: post #139

Earlier quoted context omitted.

For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example. I won't say that Go is mainstream yet, but it feels very "production-rea…

Django's ecosystem has spoilt me so much that it's very hard to switch to another language, at least as far as web apps are concerned. I would love to play with Rust/Nim more, but most of the side-projects I'm passionate about involve at least a few things that Python has a lib for that would be a huge time sink to rewrite in another language.

What libraries are you most missing for Rust?

Re: Why we switched from Python to Go

#320

Post by steveklabnik » Wed, Oct 18, 2017, 4:26 PM UTC

_hyn3 wrote: post #273

nimmer wrote: post #198

Earlier quoted context omitted.

Would you kindly share you experience on using Nim for that project?

For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afai…

Rust can do what you asked, as far as I know.