I used to be a Haskell type and now enjoy Go greatly for this reason.
There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.
People don't know how great the burden of trying to model their problem to fit a fancy language is until it's gone. I didn't.
I want generics and sum types, but I miss them less than I would have predicted.
This topic is more complicated than “for loops good, iterators bad.” I absolutely agree there’s a time and place for both; that’s why we included both in the language. But sometimes, iterators have less bounds checks than for loops do, so they can be more performant than a loop. Sometimes they’re the same. Depending on what you’re looking for, the details of what you’re doing, and your literacy with various combinations, different ways of expressing the same idea can be good. It all just dependents.
(Also, rust’s for loops are implemented in terms of iterators; they’re actually the more primitive construction in a language sense; a while loop with the Iterator library API.)
Sure, and then you ask how to fold over a tree or an infinite stream, and the answer is to reimplement all the HOFs from the “fancy languages” in a type-specific way, because otherwise every user of your ADT is having to write not just a for-loop, but an entire push-down automata.
I also write Go code without missing generics, but that’s because I’m also fluent in other languages, and tend to use those when I want something ill-suited to Go, rather than trying to force Go into that shape.
> I also write Go code without missing generics, but that’s because I’m also fluent in other languages, and tend to use those when I want something ill-suited to Go, rather than trying to force Go into that shape.
I think this should be the main takeaway from people learning go - it's not suited for everything. Technically you can write "World of Warcraft" in pure assembly, but it doesn't make sense to do - you're using the wrong tool for the job. My problem is I hear a lot of people advocating for golang with a one-size-fits-all, theres-nothing-better, sort of mantra.
I have things I absolutely reach to golang for, but the sweet spot I've found is to re-implement a prototype I've built in some other language (like Python) when I need the speed. Trying to actually create new things in golang is tedious and I end up fighting the tooling more than most other languages (sans maybe C++ or Java).
> There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.
I think it's hard to discern between "that overly-complex functional and declarative definition is unfamiliar to me" and "that is way over-complicated and should just use a for loop".
Any chance you can track down that example so others can compare the two examples as well?
I’ve seen a similar effect in myself and others at work but I don’t think it’s only a symptom of the language. After we switched from java 6 to 8 a handful of devs including myself went overboard modeling problems to be solved with streams API when it wasn’t necessary. These days it’s leveled out and use of the api is on a much more appropriate level.
I think this is a process of learning. While learning a new tool you start to model problems so you can practice, even though not necessary. Once comfortable you realize when to use the tool and when not.
There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.
People don't know how great the burden of trying to model their problem to fit a fancy language is until it's gone. I didn't.
I want generics and sum types, but I miss them less than I would have predicted.