Ah that brings back memories. Around the same time Midori was announced we started working on the MOSA Project[1], with the similar goal to create an operating system and accompanying toolchain, completely written in C#.
Because hello_world returns an IronResult, which in turn is just a simple Result type from Rust. Note that the status::Ok is different from the Ok(...).
Iron::new expects a function that returns a Result type, so it has to be there.
Also, because it is a Result it forces the caller to either handle the error or explicitly panic on it, right? They can't ignore it? (which is awesome!)
Yes, because it is a Result, the caller cannot access the success value without acknowledging the existence of an error -- via match , unwrap, or try.
If the caller does not want to use the success value (esp. in cases which return Result<(),E>, i.e. return an optional error), there is a lint which tries to ensure that the error value is handled, though as steve says you can circumvent it (which is done in an explicit way so that it's pretty obvious that there is an error being ignored).
But without the let, there's a warning. And culturally speaking, let _ is discouraged for this reason. If I want to ignore an error condition, I unwrap() instead, so at least my dumb decision will blow up in my face later instead of faint silently.
I think they were talking about the compiler-enforced exhaustive match, not must_use.
The fact that you must acknowledge the existence of the error value before accessing the meaty success value (either with a match, an unwrap, or a try) is a great feature in Rust.
must_use forcing you to handle errors for things you don't need the meaty success value of is just icing on the cake.
That statement isn't constructive either and also tends towards zero signal. Even if "du-jour" languages don't end up being used in production, some of them add really nice new concepts/ideas. Take for example Rust and its compile time borrow/ownership checking.
Judging by your argument, we all should've sticked with C and wouldn't even need C++.
Taking a look beyond the current horizon sometimes ends up being useful.
Judging by your argument, we all should've sticked with C and wouldn't even need C++.
Perhaps I was unclear.
My argument is that you should use the right tool for the situation, given all the context of that situation.
Simply stating that language X simply shouldn't be used anymore is an utter nonsense. We absolutely should not have stuck with C. That's crazy, and you know that's not what I was suggesting; please drop that passive-aggressive nonsense. We're not children and we don't need it.
New languages (barring toy languages that are written for the fun of it, such as Ook!) arrive to meet particular needs that particular people have in particular situations, be that to explore something in programming or for actual application. That's a lot of specific context. To take a new language and declare that because this new language exists an existing one should now be simply dropped is to ignore all the context and, as a bonus, reveal oneself to be very inexperienced or to hold a very narrow view of programming. If such people are lucky, someone will contend their point. If they're unlucky, the people around them will simply say nothing.
That depends on your clustering algorithms. If it is for example based on shared-neighbor information, then you end up with the same clusters as you did before scaling.
And in your example, I get: (A, B) < (B, C) < (A, C) before
and (A, B) < (B, C) < (A, C) after scaling.
So the order is preserved. It really depends on your clustering algorithm. DBSCAN for example could end up with a different result due to its epsilon-range parameter.
You can get around the curse a little bit by using shared nearest-neighbor methods, but that only helps you a little bit.
Although, the curse of dimensionality is no precise. The real problem is due to intrinsic dimensionality. There's a nice paper on how to estimate it http://www.nii.ac.jp/TechReports/14-001E.pdf
Can't agree more. XMonad is what I based my Rust window manager on. Nice, clean, easy to understand code base. No other window manager gave me so many insights into how a WM works.
Really looking forward to the articles.
[1] http://mosa-project.org