7 ms·

Perhaps someone will answer this related Q.. Having coded in Python for years, I'm underwhelmed by claims of Go's simplicity. Python, with its batteries includ

by nickd2001 5y ago

Perhaps someone will answer this related Q.. Having coded in Python for years, I'm underwhelmed by claims of Go's simplicity. Python, with its batteries included, seems to me simpler to code in and for understanding existing code, and easier to produce more maintainable code in as far as I can see. (this may partly reflect my prior experience to be fair) When I looked at Go, it looks like one has to do acrobatics and write a load of code to get around missing basic libraries and features in the language. So, I can see Go is useful for being very lightweight, and a good replacement for C++ for many things, but as for it being simple.... well, really? I guess does "simple" mean, relative to the likes of C++ ?

emmanueloga_ 5y ago
There's a talk called "Simple made Easy" by Rich Hickey (you can find it in YouTube) that talks about the difference between simple and easy in software development. Under those definitions, I agree some things in Go are not necessarily as easy to solve as in Python, but Go is definitely simpler.
- tharne 5y ago
  That talk should be at the top of every programmer's list. At the risk of sounding cliché, it actually will change how you think about program design.
  - Calamitous 5y ago
    Most of Rich Hickey's talks fall into that category.
- Scarbutt 5y ago
  You have it backwards, Go gives you the illusion that is easy (easy to start with, quick to start coding something in it) but is no simple. Writing simple systems is hard and Go works against you here.
luxurytent 5y ago
There's a few notes in the article that touch on why Go is simple. FWIW, Go comes with plenty of batteries included and as a day-time Go developer, most of what we build doesn't require external libraries (generally logging, database modules, etc. are external) Also what makes Go simple? This (From the article): > If it worked ten years ago, it works now. I have a collection of blog posts from the Go blog and other sources which I revisit from time to time and many are from indeed, ten years ago. Less cognitive overhead on figuring out what's from version x or y, if it's been deprecated, etc.
benhoyt 5y ago
I was just recently writing a somewhat complex websocket client API in both Go and Python. They were both a bit tricky, but Go's support for goroutines and channels as the concurrency primitives right in the language made the solution much more obvious. With Python, I had to figure out how to do concurrency and communication: threads, async/await, queue.Queue, something else? Go also has much better interfaces for I/O with its io.Reader and io.Writer, whereas in Python you have a "file-like object" or maybe types.TextIO if you're lucky (but is the file-like object a reader or a writer?). So even though neither Python nor Go have websocket support in their standard libraries, it was much more obvious in Go how to do concurrency and what form the readers/writers should take. In short, Go has good concurrency primitives baked into the language, and a much better-designed and cohesive standard library (Python's was designed over the past 30 years by a much larger collection of people; it's more bazaar than cathedral, with all the pros and cons that come with that).
- bestinterest 5y ago
  I'm looking forward to Java getting Project Loom for the concurrency aspect inspired by Go I believe. It will be a nice middle ground between the extremes of Python and Go.
  - hactually 5y ago
    Been hearing about loom for what seems like years. Keen to know what extremes you're seeing in Python and Go unless you're referring to the static vs dynamic typing?
  - Cthulhu_ 5y ago
    The thing with Java - and by extension Scala - compared to Go is that Loom adds yet another concurrency and language mechanism - so developers have yet another thing to decide and choose from, and a risk of mixing styles together. Whereas in Go there's only one way and that's it. pretty much. Oversimplified maybe, but my point is, 'bigger' languages offer options, and options increase overhead. I support having simplified subsets of languages - or rules in a company, whatever - that sets standards as to which language, stdlib and library features to use. Less options reduces complexity. At the cost of code volume maybe, but code volume is not and never has been the problem - complexity is.
vidarh 5y ago
Go for me is simple in the wrong ways. I'm torn on this article. On one hand I love the simplicity of Wirth's languages. Oberon-07's language spec is 17 pages, including a 1.5 page BNF specifying the syntax of the entire language. On the other hand my current preference in terms of language is Ruby, and while I dislike Python I'd pick Python over Go any day if I had to choose between them. My impression of Go is similar to yours - it's a better C or C++, and it's conceptually simple-ish, but on one hand it doesn't match the simplicity in terms of syntax and semantics of Oberon, so if I wanted Wirth-like simplicity Go wouldn't even make the list, while it doesn't match the simplicity of use of Ruby or Python. And if I had to pick a C/C++ replacement today, I'd probably opt for Rust over Go.
makapuf 5y ago
Python used to be simple. V3 cleaned it even more (adding incompatibilities and the whole drama). The recent additions are not much but there are many that you need to know to be able to understand code using it: walrus operator, type annotations, pattern matching, the whole possibilities of pasding parameters (non optional named parameters), ... each of those in isolation are not so complex, useful and welcomed by the community. But simple... less and less so.
- mhd 5y ago
  I'm still not sure that list comprehensions in Python 2 were the right move...
  - makapuf 5y ago
    this one I love, and is very useful and clear, but I'm sure each one of the c++ features are dear to someone...
  - kortex 5y ago
    Nah, list, and even moreso, dict comprehensions, are one of my favorite python features. Any time you can avoid state-in-flight (e.g. mutating stuff inside a for loop) is a win in my book. Maybe if you aren't used to the syntax, there is some mental overhead, but that goes away after (at most) a few months of writing python.
    - mhd 5y ago
      Back in the days, I was seeing Python basically as the anti-Perl, where "There's More Than One Way of Doing Things" is the core mantra. Sure, a for loop is a blunt tool, but there's something to be said about not having too many different ways to approach things. Python as the new Basic. Back then, that was a unique selling point of the language for me. These days, those are quite diffrent.
Philip-J-Fry 5y ago
If you've coded in Python for years then you probably haven't been exposed to the problems that Go was designed to solve. It's a systems programming language, like C. It's designed to be high performance and highly concurrent without sacrificing readability or overcomplicating the syntax. You can think of it as C with type safety and easy concurrency. That's it really. Python is very "hackable", as in you throw something together very quickly. If that's what simplicity is to you then Python is simple. I don't think Python is that simple though, there's a lot of hidden behaviours due to things like operator overloading. It's not type safe and type hints are relatively new. Shipping a Python application is an exercise in itself. What's worse is downloading a Python project, running it, and then getting a random crash 10 minutes later at runtime only to find that you're using the wrong version of Python. I can code Go as fast as I could code Python. I find Go simpler than Python. There's very little hidden behaviour and the behaviour that does feel weird is easily explainable. Shipping a Go application is as easy as sharing an executable. I'd pick Go over Python for all of my problems today because it's what I like, and there's many tasks where Python would be slightly better, but I don't think Python is well suited/well-rounded to all the tasks Go is good at. Like I wouldn't program a high performance websocket server in Python.
- mozey 5y ago
  > Shipping a Python application is an exercise in itself This, good cross platform support and single file executables. I use https://www.py2exe.org https://www.py2exe.org, and it works great once you've figured out how to set it up. However, doing the same thing in go is simply `GOOS=windows GOARCH=amd64 go build ./cmd/...`
  - nickd2001 5y ago
    Python I find a lot nicer to deploy on *nix. When on Windows I agree it could be painful ;)
- nickd2001 5y ago
  Thanks for the helpful explanation :). C++ was my "first love" that I got paid to code in and enjoyed, and I really felt shocked at lack of classes in Go. With C++ you could happily code C style without classes if that suited better, but you could use classes nicely (e:g like in Qt, well IMHO anyway..) or badly as I'm sure many people did. Regarding deployment, I've never found that too bad with Python, but I only use *nix. Agree Python seems pita to deploy on Windows (like many things on windows), I generally use docker, have used conda in the past, so don't particularly feel a lot of effort difference deploying Python vs Go , but different people have different skills and backgrounds, perhaps I'm better at jumping through hoops for Python so don't even notice.
hughrr 5y ago
Go is really simple. Took me a while to get that. The issue is it forces you to deal with things that need to be dealt with rather than leave them as an exceptional case (pun intended).
- masklinn 5y ago
  > The issue is it forces you to deal with things that need to be dealt with Except for all the times where it does not, which is most of them. It won’t force you to deal with errors (generally, it will in some cases as a side-effect of erroring on unused variable but there’s plenty of case where that’s going to be suppressed or irrelevant), it won’t force you to deal with nullable pointers (which is all of them), it won’t force you to deal with unsynchronised shared mutables (which is easy to do unwittingly, just send a map or a pointer over a channel), it won’t force you to lock the right mutex before manipulating those when you’ve thought of having one, it won’t force you to properly use debatable APIs like `append`, it won’t force you to deal with the possibility of typed nils, etc… It will force you to remove or explicitly silence unused import though, because, you know, that’s what’s important.
potta_coffee 5y ago
I came to Go from Python and while I know they're not exactly similar, I view Go as a "better Python" for certain tasks. I also continue to use Python for many things. One aspect of Go I love is how it handles concurrency. To try to get the same benefit from Python is just not worth it.
throwaway894345 5y ago
FWIW, I have 15 years of experience with Python and only 10 with Go. In my opinion, Go is simpler in general, but the most important "domains" in which it is simpler are as follows: 1. Tooling. Things like package management, single-binary deployment, profiling, etc are far simpler in Go than Python. 2. Performance. Optimizing Python is a painful endeavor. And the usual platitudes (e.g., "just rewrite the slow parts in C!") have significant caveats. Naive Go tends to be hundreds of times faster than optimized Python, and when you must optimize Go, it's typically just moving allocations outside of a hot loop or something trivial by comparison. 3. Concurrency. Python's async framework leaves a lot to be desired. If anyone calls a library that makes a sync call under the hood or uses too much compute, the whole process gets hosed and it's really difficult to identify the culprit. I also regularly see people forget to await the result of an async function--yeah, these are type errors and yes if you have the forethought and unlimited time you can write tests for any kind of type error, but this isn't a good use of anyone's time. 4. Rails. Go guides people toward good code. It guides people away from the kind of code that dynamic typing purists tend to write. For example, in the Python standard library, the type of an object returned by the `open()` API varies based on the value of an input parameter. Similarly, matplotlib, pandas, sqlalchemy, etc do silly things like this (although specific APIs aren't coming to mind). And of course there's a whole universe of junior engineers who try to emulate these things. As an aside, these rails are largely a matter of static typing, which also means automatic documentation (compared with Python's "x is a file-like object" with no information about what "file-like" actually means--does it support read? write? close? seek? truncate?) and great static analysis tooling.
- Karrot_Kream 5y ago
  FWIW I agree with you on most of this except for scientific computing libraries like matplotlib and pandas. A lot of these are used for exploration so the weird dynamic typing going on is specifically for the ergonomics of exploration. Everything else I agree with. I also think that Python is a particularly deplorable example of this though because of its longevity and its use by people who aren't career programmers.
  - throwaway894345 5y ago
midrus 5y ago
Can't agree more with you. I've seen people trying to write web applications and web services with Go going crazy reinventing the wheel (hand written validations, shell scripts for migrations, raw sql because "who needs ORMs, ThEYaReSloW", etc for thinks that with Python and a any of its battle tested frameworks you'd be done in a fraction of the time. Go can be a great replacement for C, C++, maybe some Java stuff. Not for what you'd otherwise use Python, Ruby, PHP, etc.... right tool for the job. The "But channels are amazing and concurrency and speed and memory" argument doesn't matter as much for 90% of projects using it.

emmanueloga_ 5y ago

There's a talk called "Simple made Easy" by Rich Hickey (you can find it in YouTube) that talks about the difference between simple and easy in software development. Under those definitions, I agree some things in Go are not necessarily as easy to solve as in Python, but Go is definitely simpler.

tharne 5y ago
That talk should be at the top of every programmer's list. At the risk of sounding cliché, it actually will change how you think about program design.
- Calamitous 5y ago
  Most of Rich Hickey's talks fall into that category.
Scarbutt 5y ago
You have it backwards, Go gives you the illusion that is easy (easy to start with, quick to start coding something in it) but is no simple. Writing simple systems is hard and Go works against you here.

luxurytent 5y ago

There's a few notes in the article that touch on why Go is simple. FWIW, Go comes with plenty of batteries included and as a day-time Go developer, most of what we build doesn't require external libraries (generally logging, database modules, etc. are external) Also what makes Go simple? This (From the article): > If it worked ten years ago, it works now. I have a collection of blog posts from the Go blog and other sources which I revisit from time to time and many are from indeed, ten years ago. Less cognitive overhead on figuring out what's from version x or y, if it's been deprecated, etc.

benhoyt 5y ago

I was just recently writing a somewhat complex websocket client API in both Go and Python. They were both a bit tricky, but Go's support for goroutines and channels as the concurrency primitives right in the language made the solution much more obvious. With Python, I had to figure out how to do concurrency and communication: threads, async/await, queue.Queue, something else? Go also has much better interfaces for I/O with its io.Reader and io.Writer, whereas in Python you have a "file-like object" or maybe types.TextIO if you're lucky (but is the file-like object a reader or a writer?). So even though neither Python nor Go have websocket support in their standard libraries, it was much more obvious in Go how to do concurrency and what form the readers/writers should take. In short, Go has good concurrency primitives baked into the language, and a much better-designed and cohesive standard library (Python's was designed over the past 30 years by a much larger collection of people; it's more bazaar than cathedral, with all the pros and cons that come with that).

bestinterest 5y ago
I'm looking forward to Java getting Project Loom for the concurrency aspect inspired by Go I believe. It will be a nice middle ground between the extremes of Python and Go.
- hactually 5y ago
  Been hearing about loom for what seems like years. Keen to know what extremes you're seeing in Python and Go unless you're referring to the static vs dynamic typing?
- Cthulhu_ 5y ago
  The thing with Java - and by extension Scala - compared to Go is that Loom adds yet another concurrency and language mechanism - so developers have yet another thing to decide and choose from, and a risk of mixing styles together. Whereas in Go there's only one way and that's it. pretty much. Oversimplified maybe, but my point is, 'bigger' languages offer options, and options increase overhead. I support having simplified subsets of languages - or rules in a company, whatever - that sets standards as to which language, stdlib and library features to use. Less options reduces complexity. At the cost of code volume maybe, but code volume is not and never has been the problem - complexity is.

vidarh 5y ago

Go for me is simple in the wrong ways. I'm torn on this article. On one hand I love the simplicity of Wirth's languages. Oberon-07's language spec is 17 pages, including a 1.5 page BNF specifying the syntax of the entire language. On the other hand my current preference in terms of language is Ruby, and while I dislike Python I'd pick Python over Go any day if I had to choose between them. My impression of Go is similar to yours - it's a better C or C++, and it's conceptually simple-ish, but on one hand it doesn't match the simplicity in terms of syntax and semantics of Oberon, so if I wanted Wirth-like simplicity Go wouldn't even make the list, while it doesn't match the simplicity of use of Ruby or Python. And if I had to pick a C/C++ replacement today, I'd probably opt for Rust over Go.

makapuf 5y ago

Python used to be simple. V3 cleaned it even more (adding incompatibilities and the whole drama). The recent additions are not much but there are many that you need to know to be able to understand code using it: walrus operator, type annotations, pattern matching, the whole possibilities of pasding parameters (non optional named parameters), ... each of those in isolation are not so complex, useful and welcomed by the community. But simple... less and less so.

mhd 5y ago
I'm still not sure that list comprehensions in Python 2 were the right move...
- makapuf 5y ago
  this one I love, and is very useful and clear, but I'm sure each one of the c++ features are dear to someone...
- kortex 5y ago
  Nah, list, and even moreso, dict comprehensions, are one of my favorite python features. Any time you can avoid state-in-flight (e.g. mutating stuff inside a for loop) is a win in my book. Maybe if you aren't used to the syntax, there is some mental overhead, but that goes away after (at most) a few months of writing python.
  - mhd 5y ago
    Back in the days, I was seeing Python basically as the anti-Perl, where "There's More Than One Way of Doing Things" is the core mantra. Sure, a for loop is a blunt tool, but there's something to be said about not having too many different ways to approach things. Python as the new Basic. Back then, that was a unique selling point of the language for me. These days, those are quite diffrent.

Philip-J-Fry 5y ago

If you've coded in Python for years then you probably haven't been exposed to the problems that Go was designed to solve. It's a systems programming language, like C. It's designed to be high performance and highly concurrent without sacrificing readability or overcomplicating the syntax. You can think of it as C with type safety and easy concurrency. That's it really. Python is very "hackable", as in you throw something together very quickly. If that's what simplicity is to you then Python is simple. I don't think Python is that simple though, there's a lot of hidden behaviours due to things like operator overloading. It's not type safe and type hints are relatively new. Shipping a Python application is an exercise in itself. What's worse is downloading a Python project, running it, and then getting a random crash 10 minutes later at runtime only to find that you're using the wrong version of Python. I can code Go as fast as I could code Python. I find Go simpler than Python. There's very little hidden behaviour and the behaviour that does feel weird is easily explainable. Shipping a Go application is as easy as sharing an executable. I'd pick Go over Python for all of my problems today because it's what I like, and there's many tasks where Python would be slightly better, but I don't think Python is well suited/well-rounded to all the tasks Go is good at. Like I wouldn't program a high performance websocket server in Python.

mozey 5y ago
> Shipping a Python application is an exercise in itself This, good cross platform support and single file executables. I use https://www.py2exe.org https://www.py2exe.org, and it works great once you've figured out how to set it up. However, doing the same thing in go is simply `GOOS=windows GOARCH=amd64 go build ./cmd/...`
- nickd2001 5y ago
  Python I find a lot nicer to deploy on *nix. When on Windows I agree it could be painful ;)
nickd2001 5y ago
Thanks for the helpful explanation :). C++ was my "first love" that I got paid to code in and enjoyed, and I really felt shocked at lack of classes in Go. With C++ you could happily code C style without classes if that suited better, but you could use classes nicely (e:g like in Qt, well IMHO anyway..) or badly as I'm sure many people did. Regarding deployment, I've never found that too bad with Python, but I only use *nix. Agree Python seems pita to deploy on Windows (like many things on windows), I generally use docker, have used conda in the past, so don't particularly feel a lot of effort difference deploying Python vs Go , but different people have different skills and backgrounds, perhaps I'm better at jumping through hoops for Python so don't even notice.

hughrr 5y ago

Go is really simple. Took me a while to get that. The issue is it forces you to deal with things that need to be dealt with rather than leave them as an exceptional case (pun intended).

masklinn 5y ago
> The issue is it forces you to deal with things that need to be dealt with Except for all the times where it does not, which is most of them. It won’t force you to deal with errors (generally, it will in some cases as a side-effect of erroring on unused variable but there’s plenty of case where that’s going to be suppressed or irrelevant), it won’t force you to deal with nullable pointers (which is all of them), it won’t force you to deal with unsynchronised shared mutables (which is easy to do unwittingly, just send a map or a pointer over a channel), it won’t force you to lock the right mutex before manipulating those when you’ve thought of having one, it won’t force you to properly use debatable APIs like `append`, it won’t force you to deal with the possibility of typed nils, etc… It will force you to remove or explicitly silence unused import though, because, you know, that’s what’s important.

potta_coffee 5y ago

I came to Go from Python and while I know they're not exactly similar, I view Go as a "better Python" for certain tasks. I also continue to use Python for many things. One aspect of Go I love is how it handles concurrency. To try to get the same benefit from Python is just not worth it.

throwaway894345 5y ago

FWIW, I have 15 years of experience with Python and only 10 with Go. In my opinion, Go is simpler in general, but the most important "domains" in which it is simpler are as follows: 1. Tooling. Things like package management, single-binary deployment, profiling, etc are far simpler in Go than Python. 2. Performance. Optimizing Python is a painful endeavor. And the usual platitudes (e.g., "just rewrite the slow parts in C!") have significant caveats. Naive Go tends to be hundreds of times faster than optimized Python, and when you must optimize Go, it's typically just moving allocations outside of a hot loop or something trivial by comparison. 3. Concurrency. Python's async framework leaves a lot to be desired. If anyone calls a library that makes a sync call under the hood or uses too much compute, the whole process gets hosed and it's really difficult to identify the culprit. I also regularly see people forget to await the result of an async function--yeah, these are type errors and yes if you have the forethought and unlimited time you can write tests for any kind of type error, but this isn't a good use of anyone's time. 4. Rails. Go guides people toward good code. It guides people away from the kind of code that dynamic typing purists tend to write. For example, in the Python standard library, the type of an object returned by the `open()` API varies based on the value of an input parameter. Similarly, matplotlib, pandas, sqlalchemy, etc do silly things like this (although specific APIs aren't coming to mind). And of course there's a whole universe of junior engineers who try to emulate these things. As an aside, these rails are largely a matter of static typing, which also means automatic documentation (compared with Python's "x is a file-like object" with no information about what "file-like" actually means--does it support read? write? close? seek? truncate?) and great static analysis tooling.

Karrot_Kream 5y ago
FWIW I agree with you on most of this except for scientific computing libraries like matplotlib and pandas. A lot of these are used for exploration so the weird dynamic typing going on is specifically for the ergonomics of exploration. Everything else I agree with. I also think that Python is a particularly deplorable example of this though because of its longevity and its use by people who aren't career programmers.
- throwaway894345 5y ago

midrus 5y ago

Can't agree more with you. I've seen people trying to write web applications and web services with Go going crazy reinventing the wheel (hand written validations, shell scripts for migrations, raw sql because "who needs ORMs, ThEYaReSloW", etc for thinks that with Python and a any of its battle tested frameworks you'd be done in a fraction of the time. Go can be a great replacement for C, C++, maybe some Java stuff. Not for what you'd otherwise use Python, Ruby, PHP, etc.... right tool for the job. The "But channels are amazing and concurrency and speed and memory" argument doesn't matter as much for 90% of projects using it.