People tend to underestimate how much effort it takes to a) learn how to be a good programmer, and b) learn a given programming language. Sometimes they confuse the two.
Go is not an easy language (2021)
11–20 of 37 posts
Re: Go is not an easy language (2021)
#12I was writing a more involved change in golang for the first time and was surprised to find golang didn't support higher order functions like map and filter. It's not a big deal to have to implement them in a custom for loop but for a language that sells on simplicity, I was surprised to find these missing. I guess I have a different idea of simple than the golang team.
Higher order functions are not easy to grasp for beginners, but once you do, they simplify reasoning about the code a lot. Go is targeted at system programming, which is a domain in which you need pretty advanced developers. But the language feature seems to favor use by absolute programming beginners. It's a trade-off which seems somehow inverted.
Go was designed to be easy to learn for inexperienced developers.
Is it actually intended for systems programming? Its main (and intended) use seems to be a faster and better at concurrency and parallelism alternative to Python, Ruby etc.
Re: Go is not an easy language (2021)
#13People tend to underestimate how much effort it takes to a) learn how to be a good programmer, and b) learn a given programming language. Sometimes they confuse the two.
Yeah. Tons of people claim to be able to pick up languages within a week, or a month. I’m convinced it takes at least a year to get out of beginner status, even for simple languages. I’m including things like knowing the ecosystem and popular libraries (http server and clients, ORMs, testing frameworks, …) in that.
Re: Go is not an easy language (2021)
#14Just a side note, Golang has generics now: https://go.dev/doc/tutorial/generics
Google says that only since Feb 2022, and the article was written in 2021, but I think it was a planned feature and if the author did some research, he'd realize that generics are coming.
Re: Go is not an easy language (2021)
#15This has been my argument since I started using it. It's definitely simple but the easiest stuff can be such a pain.
It's really the other way around : it's simple, which makes it not easy to use.
The way Arch Linux defines simplicity is "Arch Linux defines simplicity as without unnecessary additions or modifications."[0]
Go is simple because it only really has what you NEED. People complain about wanting this and that feature, but they don't really NEED it, it would just make writing code easier.
Personally I love that because if there's a billion ways to do something, I waste all my time trying to figure out the best way to do it instead of working on the original problem, but I can see why people who are not like me would prefer more features.
Re: Go is not an easy language (2021)
#16I was writing a more involved change in golang for the first time and was surprised to find golang didn't support higher order functions like map and filter. It's not a big deal to have to implement them in a custom for loop but for a language that sells on simplicity, I was surprised to find these missing. I guess I have a different idea of simple than the golang team.
There’s a talk by Rob Pike where he mentions that it would have been difficult for code using map, filter, etc. to be as fast as the equivalent code using a for loop without a sufficiently smart compiler.
So I think the motivation was more implementation simplicity . But if they had tried to add zero cost iterators it probably would have leaked complexity into the language too.
Re: Go is not an easy language (2021)
#17Go is simple like C is simple. Add a garbage collector and concurrency and it’s easier to do some things but the simplicity of the language means you have to intimately understand more of the runtime to not shoot yourself in the foot.
Re: Go is not an easy language (2021)
#18Earlier quoted context omitted.
This was my impression coming to Go as well (from Python and PHP) but since then I've changed my mind and somehow find it easier to unpack a small for loop than a HOF with a lambda function argument. When you introduce lambdas/closures/HOF you immediately have to think about scope rules, non-local references etc. Meanwhile, a foor loop is just a for loop.
Until you spawn a goroutine from a loop and suddenly you have to think about scope rules, nonlocal references, etc... (It doesn't bother me, just noting the same complexities do come up pretty often).
BTW this is actually being addressed, specifically the for loop now essentially captures by value instead of by reference. I believe no real working programs were affected by the change, except for maybe fixing bugs in them.
Re: Go is not an easy language (2021)
#19I was writing a more involved change in golang for the first time and was surprised to find golang didn't support higher order functions like map and filter. It's not a big deal to have to implement them in a custom for loop but for a language that sells on simplicity, I was surprised to find these missing. I guess I have a different idea of simple than the golang team.
Generic iterators are included in go 1.22 behind an experimental feature flag and will most likely be in 1.23 by default. Once that's done you will probably see some support functions like map and filter in the standard library. Russ Cox already has a proposal for an experimental package xiter that includes Map/Filter/Reduce/Zip etc.
Re: Go is not an easy language (2021)
#20pop() would have been a much better example, as ruby providing delete_at is a mistake IMO, since it runs in O(n), chances are that you're using the wrong data structure. Go providing append but not pop is inexplicable