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

241–250 of 406 posts

Re: Why we switched from Python to Go

#241

Post by systems »

Jyaif wrote: post #233
Dowwie wrote: 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…

facebook, php ∎

and they are now seem invested in Ocaml/Reason (which are a lot less popular compared to Go)

i guess after companies reach a certain size, they can go beyond choosing a programming platform for its ecosystem

Re: Why we switched from Python to Go

#243

Post by dguaraglia »

seanpfeifer wrote: post #141
dguaraglia wrote: post #119

Earlier quoted context omitted.

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

Wait! Is this a go 1.9 thing? I've been using 1.83 all this time.

Re: Why we switched from Python to Go

#244

Post by majewsky »

oblio wrote: post #158
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…

I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight). So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html ). Soun…

So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P

Re: Why we switched from Python to Go

#245

Post by majewsky »

pritambaral wrote: post #131
curun1r wrote: post #107

Earlier quoted context omitted.

Or anyone who's used a language where errors aren't as stringly-typed as Go and where the compiler can enforce error handling. Exceptions have benefits and drawbacks, but any language that can return a Result type will have better error handling than Go in basically every way.

In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.

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

Re: Why we switched from Python to Go

#246

Post by hasenj »

dingo_bat wrote: post #214
tapirl wrote: 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.

That's one of the things in my original comment.

Although I agree with you about some basic things in Go such as insertion being somewhat crazy, but there's a point I want to make about abstractions.

Abstractions that hide too many things away are not always a good thing.

If an abstraction makes something easier to write, but harder to read, that's not a very good thing.

Unfortunately Go does not exactly hit the sweet spot. It errs on the side of less expressive power.

EDIT:

Actually, for inserting into a list, the code can be simple, although the line will be split into three lines, and creates a new temporary list

// insert number 10 into position 2 var b []int b = append(b, a[0:2]...) b = append(b, 10) b = append(b, a[2:]...)

https://play.golang.com/p/ommopBd3io

Now, that _is_ overly verbose, but I don't think it's too off putting. I don't like it but I guess it's a quirk of go I'm willing to put up with.

Re: Why we switched from Python to Go

#247

Post by baq »

mmargerum wrote: post #226
closeparen wrote: post #151

Earlier quoted context omitted.

Nope! And that's most people's main problem with it.

Wrong. Go has templating.

yeah, maybe, if what you want is to fill some strings in a template and not to create a type that's generic over other types.

Re: Why we switched from Python to Go

#248

Post by jamiesonbecker »

Tiberium wrote: post #217
jamiesonbecker wrote: post #35

Earlier quoted context omitted.

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

Absolutely - will do!

Re: Why we switched from Python to Go

#249

Post by rockostrich »

wruza wrote: post #42

>Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on. I’m not criticizing Go since I have no LoC in it, but in other restricted-and-flat languages and areas our company’s expertise quickly (read: in half a decade) went to the limit with no chance to turn the lang partly into dsl and level up. It is like playing rpg where you stuck to level 5 a…

I understand what you mean by "inability to create something that only your team can use and understand", but the article doesn't say anything about that and isn't really addressing developing new code in Go. The article is about Python not matching their needs after a few tries at optimization and Go having a similar development time (although if the code was already implemented in Python then I assume the Go code was almost trivial to write so I'm not sure that was a valid point).

As for "'there is only one opinionated way to do it' seems to fit better on average tasks", from the Zen of Python: "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." And Python has been used to do plenty of above average tasks.

Re: Why we switched from Python to Go

#250

Post by hasenj »

dozzie wrote: post #213
jon_richards wrote: post #138

Earlier quoted context omitted.

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.

Most deploy scripts I've seen tend to do this. Which is insane in my opinion, but the python toolset encourage this kind of approach by making it the default easy thing to do.

That's one of the things I prefer about Go: the compiler can cross-compile, so I can compile the entire codebase on my osx machine and produce a single statically linked linux binary that I can just copy over scp to the server. Deployment becomes infinitely simpler.

Post reply on HN