Rust feels more like Perl 6 (always on the horizon) or Ada (the do everything language), while Go already is already specified, being improved, and out in production.
Oh, come on. Rust started as an open-source project in 2010 (with the release of the preliminary design and OCaml compiler that Graydon had written as a hobby project). At that time, work started on the self-hosting compiler, leading to its initial 0.1 release eight months ago, and proceeding with releases every few months and steady progress toward the remaining goals on the 1.0 roadmap [1]. Just because Go was developed earlier doesn't mean that Rust isn't getting done. And it's not noticeably more complex than it was in the initial design; in some ways it's simpler.
(By contrast, Perl 6 has been in development for over a decade, with a half-dozen implementations in various stages of completion.)
I've attended a few Go meetups here in SF already, and I haven't even seen any Rust meetups on the radar.
At these Go meetups, companies are presenting what they're using Go for in production already, with great success. Go is not difficult to program in, Go is functional, Go is performant, Go is developer friendly.
That is not to say that Go doesn't have warts, it does (32-bit garbage collecting anyone? or the slow regular expression engine?), but people from Ruby, people from Python, and people from JavaScript are gravitating toward Go and _enjoying_ it.
Go also has excellent stewardship in the form of Pike et al.
In my mind, at least, the gap between Rust and Go is pretty big at this point. This is why Rust feels like vaporware (especially compared to Go).
People like to compare Go and Rust, and I think the comparison is pretty natural. The difference is that Go already has "boots on the ground."
If Rust releases something awesome in the next few months, the gap between Go and Rust could rapidly close (depending on developer adoption). But, in my mind, the longer Rust takes to iron out the quirks of it's syntax (not implementation, syntax!), the wider that gap will get.
When Go was announced it had a spec, a significantly larger standard library than Rust, two compilers (and a parser in the standard library), and much, much better documentation. While the language had changed until the Go 1 release from a few months ago, it had changed less in two years than Rust changed in a few months. Go also introduced a tool that would automatically rewrite your old code to adapt to the new language changes.
All that means is that Go was announced much later in the development process than Rust was. If Rust had been developed like Go, it wouldn't have been made public yet. But that's not the way Mozilla does things.
In nine months, Rust has gone from version 0.1 (its first public release) to version 0.4 (expected next week). Much of the work in that time has involved removing (!!!) features from the language and polishing what's left. Version 1.0 is anticipated in the first half of next year.
If you really feel the need to compare with Go, measure the time from Go's first public release (2009) to its first production release (2012).
I don't know if this is a fair criticism. Rust has not been stuck in eternal development for many years like Perl 6. Rust is less mature than Go just because it started (in earnest) later and it's a little more ambitious. Go was immature not that long ago.
> I don't think it's like that. I think they're just developing it through usage.
What's shipping with it?
I have a bit of the same impression that the other poster has, that it's always in development without something stable. I hope that gets dispelled sooner or later, because, for better or worse, fuzzy marketing type things like that matter.
Your impression is completely accurate; the language is in development and is not ready to use yet. It shouldn't be used in any shipping products. There's nothing to "dispel" here until the 1.0 syntax is is finalized; fortunately that should happen in months rather than years.
From a pure marketing perspective, sure, maybe it would be better to finish more of the design and implementation before talking about it publicly. But Mozilla's pretty committed to working in the open, and that has its own benefits. For example, significant parts of the Rust implementation were created by contributors who were not paid Mozilla staff, including a Google employee (in her spare time).
(Disclosure: I'm a Mozilla employee but not part of the Rust team; I've contributed a little bit to the Rust compiler in my free time.)
As annoying as it is, it makes sense that some web developers would choose this option. Although, limiting the experience for everyone just because one mobile browser has a bug? I'm pretty sure something similar happened with a certain browser called ie6. From the link you gave, it looks like you can just detect an iPad and disable zooming in that case (although, that requires some javascript or server side programming).
So, which version of iOS do they plan on fixing this (or did fix this)? But then, that doesn't factor the people who don't know about OS updates and never sync.
>This is "the guest you sent me destroyed my home and sense of safety."
Not to mention the theft of personal documents and potential theft of identity. The (very real) potential of being bushwhacked by additional fraud years down the line due to this incident is pretty horrifying.
Basically they're letting people create "slashtags" that restrict a search to a customized list of sites.
Eg) I have one for /objc that searches a half-dozen high-quality, good signal-to-noise, non-spammy objective-c related sites, so that if I search for "timers /objc" I get only quality content and no farmed spam.
There's a lot more to it but they've essentially farmed out the job of whitelisting the non-spammy parts of the internet to their users.
Edit: and more to the point of what you were desribing, you can easily use other people's public slashtags, and it will detect and suggest relevant ones as you use it. It's totally worth playing around with.
