I mean, If you ignore the advances in engineering and computer research of the last half century and just go with something new, different and unproven because a friend told you so, can you really blame technology?
You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.
No need to get personal. I was talking about all the features in all the languages, not the ones in Go. And yes, we don't need more new features, we have plenty.
However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do. And humans have brains. And brains are limited in their ability to do some thing while keeping other things in mind. And if among other things types happen to be present and mistake was made, than one could say types added to that mistake. And if types were not something programmer needed to think than type system certainly didn't add to that mistake. Things are not as simple as most programmers tend to think. Features don't matter how they think they matter. And research in language design was broken since the beginning of times and, sadly, still is.
(if you read "no silver bullet", "out of the tar pit" papers and couple of recent ones on bugs you should get the idea of how bad things are with mistake-making research)
Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.
Go seems to be an iteration of Rob Pike's previous languages, Limbo and Newsqueak - perhaps with a sprinkling of other ideas, but not much.
Rust on the other hand has been a far more ambitious project, with very lofty goals. This has meant that the Rust team has needed to do a huge amount of experimentation and iteration, culminating in the tight set of core semantics that you see in the language today. It's not been an easy journey for the them, but a great deal has been learned in the process, and even if Rust never 'makes it' into widespread usage, its contributions to the field of programming language design will be felt for years to come.
This is not to diminish the efforts of the Go team - they have produced a really tight, polished language, with an excellent set of bundled libraries. All I'm saying is that they weren't starting from scratch, and had different goals to the Rust team. That has meant they could get to a stable language much faster.
Rob Pike's keynote at GopherCon 2014 does a great walkthrough of the evolution of the design of the language, where ideas were borrowed from and why: https://www.youtube.com/watch?v=VoS7DsT1rdM
That looks a lot like today's Go. All of the major design decisions were made, distinctive Go concepts (slices, maps, interfaces, goroutines, switching on concrete type, etc.) are all present. Most of the code examples would compile today with only a few tweaks (if any).
Suffice it to say that Rust was not in that state in 2010. It was barely in that state by 2014. Go was released as a beta; Rust was released as a pre-alpha. That isn't a judgment of either language or community.
Externally, it certainly seems that Go was open sourced in a far more finished state, with only relatively small tweaks after the initial release, while Rust was quite raw and has had most of its fundamental design work done in the open (with significant contribution from volunteers, both code and design) after being placed on github in 2010.
Rust 0.1 came out in the beginning of 2012, about 3 months before Go 1.0 game out (or go1). In the meantime, Rust has changed a lot and is only now close to a 1.0 release.
I am from the state of Michoacan, Mex. There is this dish done with the pig´s blood and intestine, it might not look like the most appetitizing dish but it´s pretty good. Its called "Soricua" by the way. We might be speaking about the same dish.
It's been opensourced which as far as I can tell, means that the developers wash their hands now and leave to move on to new, easier and more fun things than writing a decent text editor. They delivered half of what they promised 1 year overdue. But I guess if you want something done now you're free to write it yourself ;)
So you're unwilling to learn something potentially better because you're were offended by a (surely) tiny portion of its userbase? Lose the childish attitude. You owe it to your craft and users to keep learning and using better tools.
Heh, might as well just use another language at this time. Guido himself seemed to be very pissed off at the common lispers for being forced to add some functional language features. You can see it from the crappy implementations of single-arity lambdas, non lazy map, filter, reduce, etc. The language will never catch up to the times, as evident in the lame feature list in python 3. Most python users seem blissfuly ignorant of modern languages and Guido doesn't seem to like learning new stuff either.
> Most python users seem blissfuly ignorant of modern languages
It's really not that. The Python users I know, including myself, enjoy learning new languages. The issue is that there's extremely few which are "Pythonic" - a form of beauty in its pragmatism, readability, and usability.
If you come at most Pythonic Python code, it's remarkably readable, and it's easy to understand what's going on even without much domain knowledge regarding whatever it is the code does. There's no need to understand abstract branches of maths to understand how a Python program works, no need to understand some program's own DSL, no need for special text editors, it's all just a pragmatic language.
In some ways, it's really the Java of the current generation. That's not a terrible thing - it's a simple, beautiful language which works for developing reasonably complex applications. It's possibly to write code in all sorts of architectures without having to bend the language too much, or invent sublanguages.
IMHO, Rust is going to be a massive language for current Python users. It's extremely unmagical, readable, and opposed to the idea of "DSLs for everything" that some popular languages have, while having a very nice and usable type system. Code that I've seen in Rust also tends to meet the Zen of Python, even better than code in Go (another language currently popular among Python users).
It's not lazy, it returns iterator. There is a difference, you can't slice or index its result anymore. Compare to Clojure or Haskell map, which are truly lazy.
It's not represented in head normal form, but it's still lazy.
The limitations you mentioned are not an artifact of the implementation being eager(because it's not eager), but instead are an artifact of the representation used.
