This post makes me extremely happy. :D<p>> among the sites of its peers, only Ruby is similarly localized. Given that several prominent Rustaceans like Steve Klabnik and Carol Nichols came from the Ruby community, it would not be unreasonable to guess that they brought this globally inclusive view with them.<p>Not just that, I actually looked at how Ruby's website did it in order to bring it to our site. This has... issues. But it's served us fairly well.<p>Additionally, while there's so much more I could say about this post, one thing:<p>> my naive Rust was ~32% faster than my carefully implemented C.<p><i>This</i> is a metric I'm more interested in, far more interested than classic benchmarks, where various experts eke every last little bit out of an example. What's the <i>average</i> case here?<p>It is, of course, much much harder to get numbers for these kinds of things...
For what it's worth, these observations track closely with my own experience. I like that Cantrill emphasizes values rather than simply technical decisions. The Rust community, I believe, tries to get things right.<p>There's a learning curve, but with much experience, I find myself naturally thinking and writing in Rust code. I can get in the flow, and it feels just as high level and productive as languages prized for those qualities. I'm happy to see other very talented programmers have similar experiences.
I've been on something of a language tour recently - trying out C++, Typescript, OCaml each for a couple of weeks just to get a taste of living in each ecosystem. I haven't been actively following Rust beyond reading Hacker News articles (of which there are many) about people liking the language.<p>One of my pet peeves with several "newer" languages that I've looked at is that users don't usually talk about the ugly parts. You can try out C++ for a week visiting forums and r/cpp and you find out fairly quickly what the pain points are and what typical workarounds look like. At that point, it is up to you to decide to what extent you can live with those downsides and where to tread lightly. Same for C, Python, OCaml etc.<p>To be clear, I don't mean that you should go looking for the bad parts in a language but I do believe you should be aware of them before you invest a lot of your time in it. Unfortunately, a lot of the language love blog posts do not talk about the pain points of the language and what kind of problems it isn't well suited for.<p>I like Rust and I love several features that Bryan talks about (algebraic data types being one of them) but I would love to read a more balanced evaluation of the language - focusing on aspects which are rough around the edges and expected future improvements.
Honestly watching Brian talk about Rust
<a href="https://www.youtube.com/watch?v=LjFM8vw3pbU" rel="nofollow">https://www.youtube.com/watch?v=LjFM8vw3pbU</a>
is what finally inspired me to get the books and give it a go.
I like that the author threads in so many other concepts with links to other blogs that explain those concepts.<p>I really need to get my hands dirty with Rust. A lot of very smart engineers have been throwing projects my direction seeking opinions and I've never been able to properly offer any. The folks working on the language and projects around the language are really sharp.<p>Recently I haven't had any personal projects that aren't a conglomeration of API requests and simple data storage. Rust is more than capable of doing this kind of work but I'd really like to find a pet project that would take advantage of it's performance capabilities.
I'm happy that error handling landed in first place; I feel the same way. Rust is the first language I've used with ADTs, and they're incredibly expressive. It allows the error system to be a set of idioms built atop an expressive type system (okay, so the ? operator does add a <i>little</i> sugar), rather than a discrete language feature, like with exceptions. It brings error handling to the forefront, and it's a <i>big</i> reason why people tend to say "if it compiles, it works" when talking about Rust.
One thing I've been missing in starting with Rust, is a basic GUI library. Conrod looks promising, but the apparent lack of documentation, coupled with being very new to the language, makes for a very steep learning curve.<p>Could anyone suggest where to start developing a cross-platform GUI program in Rust?
It's kind of weird to say m:n threading is terrible when it seems to work okay in Go.<p>It wasn't the right choice for Rust, but that doesn't mean Go's choice was wrong.
>"Over a decade ago, I worked on a technology to which a competitor paid the highest possible compliment: they tried to implement their own knockoff."<p>Could someone share who the competitor and what the knock off was?
This is great sign for Rust, as it is getting adopted by actual OSes.<p>All successful systems programming languages got OS adoption at a given moment on their history.<p>As addendum, even if off-topic, Microsoft is also making use of it on Azure IoT Edge and possibly on Azure Sphere, but the later remains to be confirmed.
My thoughts on the philosophical aspects of the article don't really relate to Rust.<p>> These values reflect a deeper sense within me: that software can be permanent<p>Maybe it <i>can</i> be permanent, but it <i>shouldn't</i> be. Software is disposable and all the time developers are mistakenly fighting this aspect of its nature instead of embracing it. Great software is malleable and develops, over time, to adapt to the human that is using it. But it is impermanent--parts are snipped off here, fleshed out there, nothing stays the same, it is obsolete as soon as it is released. Don't delude yourself that your software will run for a thousand years, be like Warhol and celebrate the ephemera that is pretty much every program ever written.<p>> I have believed (and continue to believe) that we are living in a Golden Age of software, one that will produce artifacts that will endure for generations<p>Museum pieces, sure, but do we still want to be using generations-old software in the years to come? Hope not. Times change, needs change, and software that doesn't change is replaced by software that does, and quick. What about such monumental artifacts as 'cc', 'awk', or even the UNIX kernel? For years they have dominated the landscape, they are the Ozymandias, the King of Kings. If we are still clinging to these titans in another 20, 50 years, is that a good thing?
One of the things that's turned me off about Rust is that a lot of code seems().to().chain().lots().of().operators()<p>Is this idiomatic? It seems powerfully indecipherable/illegible
Maybe Rust has passed through its dark time and come out the other side. There was a long period during which error handling was a mess. First it was too verbose. Then came "try!", which was kind of a hack to return from functions on error. Now there's "?", and a reasonable structure around how to use it.
This resonated with me a lot:<p>> These values reflect a deeper sense within me: that software can be permanent — that software’s unique duality as both information and machine afford a timeless perfection and utility that stand apart from other human endeavor.
nit: the author describes the '?' operator as both not-magic and magical.<p>IMO an operator that returns is pretty magical. What do others think about '?'? It's certainly more ergonomic than pattern matching / monads etc, but it also seems easy to miss if it's buried in the middle of an expression.<p>I think Swift's try is a bit nicer to use, because it comes at the beginning of the statement, provides more flexibility in how the error should be handled, and supports multiple expressions that may generate errors. On the other hand Swift's error handling is an addition to its type system, instead of being built inside it like Rust.
Watch the Apple - Think Different commercial at <a href="https://www.youtube.com/watch?v=cFEarBzelBs" rel="nofollow">https://www.youtube.com/watch?v=cFEarBzelBs</a> , and pay attention to the script/words. It's as if it was purpose-written for Rust.<p>In fact, there's even a callout to Result<> "..but the only thing you can't do, is ignore them" . :)