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

141–150 of 406 posts

Re: Why we switched from Python to Go

#141

Post by seanpfeifer »

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 is possible in Go right now. Use "if thing, err := blah(); err != nil { ... }".

This is common for things like map access. See an example here https://play.golang.org/p/P3k5tgFLd2

Re: Why we switched from Python to Go

#142

Post by drej »

Instead of all the 'we replaced x with y', I'd like to for once read something along the lines of 'we started using x and y side by side, embracing the benefits of each'

I use both Python and Go regularly and the use cases rarely overlap. They are both fantastic languages and once you realise what you want to use each one for, you'll be one happy developer. (Applies to many other combinations of languages.)

Re: Why we switched from Python to Go

#143

Post by dragonwriter »

slackingoff2017 wrote: post #46

Why does anyone write web apps in Python? PHP? Ruby? Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faste…

> All the big companies are using Java and Go almost exclusively for high volume endpoints

Because mature companies in competitive markets live or die by operational cost effectiveness.

Growth-phase companies or one with moats live or die by other means; if they are around long enough and are targeting a valuable enough market, they'll eventually probably be a mature firm in a competitive market, but a good way not to get there is to focus on the needs that such a firm would have rather than the needs the firm they actually are now actually has.

Re: Why we switched from Python to Go

#145

Post by Erwin »

deathanatos wrote: post #106
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…

> On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail. In Python, one would need to supply the message argument to avoid that. But Go seems no different, really; you still have to supply the message. My understanding of the testing package is that Python's: self.assertEqual(expect, actual, f'expected ({expect!r} != ac…

py.test does the magic walking, and it does indeed make for much less verbose tests -- no need to remember which self.assertSomething method to call either:

    x = 1
    y = 2
    items = [4,5,6]
    assert (x+y) in items
Outputs this, replacing the variable names with values

    test.py:4: in 
        assert (x+y) in items
    E   assert (1 + 2) in [4, 5, 6]

Re: Why we switched from Python to Go

#146

Post by djsumdog »

disconnected wrote: post #33
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…

> conflicting system level packages In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages. If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.

Virtualenv is nice, but lately I've grown to use docker containers instead. You can use the official containers for go, python or ruby, feed it the gemfile or requirements.txt or whether, tag it, push it and you have a permanent snapshoted image.

Re: Why we switched from Python to Go

#147

Post by FreeFull »

crimsonalucard wrote: post #112
mmirate wrote: 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?

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.

Re: Why we switched from Python to Go

#149

Post by seunosewa »

> Go’s fast compile times are a major productivity win compared to languages like Java and C++ which are famous for sluggish compilation speed.

C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it’s a simple language.

Re: Why we switched from Python to Go

#150

Post by raverbashing »

seunosewa wrote: post #149

> Go’s fast compile times are a major productivity win compared to languages like Java and C++ which are famous for sluggish compilation speed. C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it’s a simple language.

Java is not a simple language, period

Now, if you mean "simple" as in, needs an IDE to figure out what other languages figure out in runtime/compile time automatically, then yes, it's a dumb language

Not to mention the library, which is a jigsaw puzzle composed of barely fitting parts that need to be connected in non-obvious ways to work and made by people who want to prove they know several design patterns and can apply then to any situation instead of something that's rational and straightforward

Post reply on HN