4 ms·

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you g

by monus 7y ago

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too. Python is easy but when you do advanced stuff, often without realizing, you start to grok many complex details to make it work or make it work in a performant way. On the other hand, Go (and Rust supposedly, but I don't have experience) is simple. It doesn't let you do many things and that results in fewer ways of doing a specific task but when you do it, you feel safer because in the end, it does look and feel simple although you spent 1+ hour than you'd normally spend compared to coding in Python (this assumes you're doing some advanced stuff, not quick start).

tsimionescu 7y ago
Go is actually a pretty complex language, more so than Java for example, in my opinion. It has all sorts of primitives that you need to get used to, special rules for how the built-in types work, there are all sorts of rules to see what creates a copy of a struct and what doesn't, pointers have at least three completely different use-cases (optionality, mutability, and avoiding copies), several rules for what can and can't be addressed etc. And this is all before looking at the standard library.
- monus 7y ago
  I think concrete things you listed like the case for pointers is not much different than Java. While why you use a pointer changes, it's simply pointer in the end, just like Java. I'd say Go is able to put so much meaning to those fundamentals because 1. they have to, there isn't many other mechanisms 2. they can because it's still early in the evolution of the language. After some adoption and wildly different use-cases that users wants to be addressed, those patterns start to disappear and people end up with lowest common denominators, pointers being just pointers in this case.
- XorNot 7y ago
  I do wonder what the trade off would've been in Go if something like: a := b was guaranteed, under all expressible circumstances, to create a completely new copy - regardless of the content of b, unless it was explicitly a pointer. It does frequently feel like this could've been solved by making basic slice assignment always go as a := b[:], and adding some type of syntax and checker where you needed to confirm that you were doing a not-completely immutable copy.
modo_mario 7y ago
>On the other hand, Go (and Rust supposedly, but I don't have experience) is simple. I was reading most if this yesterday which seems to disagree: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/ https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...
- mplanchard 7y ago
  I really enjoyed this article. Thanks for linking it! It’s interesting to see the relative naïveté in some of the implementations of what seem to be relatively key builtin libraries like file pathing. I also have never had to deal with cross platform support in Go, so I’d never seen the magic compilation comments/suffixes.
- arunix 7y ago
  Discussed here recently: https://news.ycombinator.com/item?id=22443363 https://news.ycombinator.com/item?id=22443363
lallysingh 7y ago
No comment on Go. One pattern I've seen are tools that make easy things easier, but make hard things impossible. Which is fine until the built system needs to grow. Then the pain hits.
jniedrauer 7y ago
In real life, there are monsters lurking behind Go's "simplicity." An example: errors as values. It forces you to deal with errors as they come up, right? Not exactly... People just start ignoring errors. The extremely opinionated linter doesn't care if you just assign an error to _, or even just don't handle the return values at all. And it's not something you can easily spot in a pull request either. Then you end up with nil pointers or spaghetti errors that only show up at runtime and can be quite difficult to trace, where a Python exception would make debugging trivial. This isn't necessarily a knock on Go. I've enjoyed working in it full time for several years now. I don't think there's a such thing as a simple programming language. Go just hides the complexity from initial inspection.
- hartzell 7y ago
  > Go just hides the complexity from initial inspection. If you (parent, other readers) haven't seen it, Rob Pike's "Simplicity is complicated" is a good discussion of just this point. video: https://youtu.be/rFejpH_tAHM https://youtu.be/rFejpH_tAHM slides: https://talks.golang.org/2015/simplicity-is-complicated.slide#1 https://talks.golang.org/2015/simplicity-is-complicated.slid...
- courtf 7y ago
  I think there are multiple levels to this phenomenon. With Go in particular, after having used it in some high performance scenarios (10k request per second for images that are rendered on the fly by GPUs, on systems holding 200GB of binary radar imagery in memory, that also need to ingest 50MB per second of new radar data), I've seen that the simplicity of the language is not a hindrance in these areas. Edit: if you find yourself spending most of your time trying to come up with the perfect abstraction, Go may really piss you off, I won't deny that, it's not a strength. You have to be satisfied with 'good enough' and move on, solving edge if/when they arise. Go often encourages moving toward the concrete, and you can solve generic problems in really basic ways sometimes. As an example, I was writing a DAG server last year, and coming up with ways to move data between vertices in the graph in a general way. Rather than getting out my abstractions, I just pass around []byte, and leave the interpretation of those bytes up to each vertex (often just a type cast). I personally find this refreshing, and while there are costs to doing it this way, with a few basic helper funcs, you can get 95% of what you want from a generic server like this without doing a lot of modeling.
hartzell 7y ago
> [...] easy is confused with being simple [...] The first half of Rich Hickey's "Simple Made Easy" presentation does a great job of defining easy/hard and simple/complex axes and distinguishing them. video: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/ It has been discussed before on Hacker News: https://news.ycombinator.com/item?id=4173854 https://news.ycombinator.com/item?id=4173854

by monus 7y ago

tsimionescu 7y ago

Go is actually a pretty complex language, more so than Java for example, in my opinion. It has all sorts of primitives that you need to get used to, special rules for how the built-in types work, there are all sorts of rules to see what creates a copy of a struct and what doesn't, pointers have at least three completely different use-cases (optionality, mutability, and avoiding copies), several rules for what can and can't be addressed etc. And this is all before looking at the standard library.

monus 7y ago
I think concrete things you listed like the case for pointers is not much different than Java. While why you use a pointer changes, it's simply pointer in the end, just like Java. I'd say Go is able to put so much meaning to those fundamentals because 1. they have to, there isn't many other mechanisms 2. they can because it's still early in the evolution of the language. After some adoption and wildly different use-cases that users wants to be addressed, those patterns start to disappear and people end up with lowest common denominators, pointers being just pointers in this case.
XorNot 7y ago
I do wonder what the trade off would've been in Go if something like: a := b was guaranteed, under all expressible circumstances, to create a completely new copy - regardless of the content of b, unless it was explicitly a pointer. It does frequently feel like this could've been solved by making basic slice assignment always go as a := b[:], and adding some type of syntax and checker where you needed to confirm that you were doing a not-completely immutable copy.

modo_mario 7y ago

>On the other hand, Go (and Rust supposedly, but I don't have experience) is simple. I was reading most if this yesterday which seems to disagree: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/ https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

mplanchard 7y ago
I really enjoyed this article. Thanks for linking it! It’s interesting to see the relative naïveté in some of the implementations of what seem to be relatively key builtin libraries like file pathing. I also have never had to deal with cross platform support in Go, so I’d never seen the magic compilation comments/suffixes.
arunix 7y ago
Discussed here recently: https://news.ycombinator.com/item?id=22443363 https://news.ycombinator.com/item?id=22443363

lallysingh 7y ago

No comment on Go. One pattern I've seen are tools that make easy things easier, but make hard things impossible. Which is fine until the built system needs to grow. Then the pain hits.

jniedrauer 7y ago

In real life, there are monsters lurking behind Go's "simplicity." An example: errors as values. It forces you to deal with errors as they come up, right? Not exactly... People just start ignoring errors. The extremely opinionated linter doesn't care if you just assign an error to _, or even just don't handle the return values at all. And it's not something you can easily spot in a pull request either. Then you end up with nil pointers or spaghetti errors that only show up at runtime and can be quite difficult to trace, where a Python exception would make debugging trivial. This isn't necessarily a knock on Go. I've enjoyed working in it full time for several years now. I don't think there's a such thing as a simple programming language. Go just hides the complexity from initial inspection.

hartzell 7y ago
> Go just hides the complexity from initial inspection. If you (parent, other readers) haven't seen it, Rob Pike's "Simplicity is complicated" is a good discussion of just this point. video: https://youtu.be/rFejpH_tAHM https://youtu.be/rFejpH_tAHM slides: https://talks.golang.org/2015/simplicity-is-complicated.slide#1 https://talks.golang.org/2015/simplicity-is-complicated.slid...
courtf 7y ago
I think there are multiple levels to this phenomenon. With Go in particular, after having used it in some high performance scenarios (10k request per second for images that are rendered on the fly by GPUs, on systems holding 200GB of binary radar imagery in memory, that also need to ingest 50MB per second of new radar data), I've seen that the simplicity of the language is not a hindrance in these areas. Edit: if you find yourself spending most of your time trying to come up with the perfect abstraction, Go may really piss you off, I won't deny that, it's not a strength. You have to be satisfied with 'good enough' and move on, solving edge if/when they arise. Go often encourages moving toward the concrete, and you can solve generic problems in really basic ways sometimes. As an example, I was writing a DAG server last year, and coming up with ways to move data between vertices in the graph in a general way. Rather than getting out my abstractions, I just pass around []byte, and leave the interpretation of those bytes up to each vertex (often just a type cast). I personally find this refreshing, and while there are costs to doing it this way, with a few basic helper funcs, you can get 95% of what you want from a generic server like this without doing a lot of modeling.

hartzell 7y ago

> [...] easy is confused with being simple [...] The first half of Rich Hickey's "Simple Made Easy" presentation does a great job of defining easy/hard and simple/complex axes and distinguishing them. video: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/ It has been discussed before on Hacker News: https://news.ycombinator.com/item?id=4173854 https://news.ycombinator.com/item?id=4173854