I've read the Rust guide like 5 times and I still don't get it. Systems programming is hard. I guess it's a trade off.
Name:
Anonymous2015-01-21 0:32
Noisy, unreadable code, obsessed with ownership, may give rise to whole new classes of errors that otherwise won't be there. Good that someone experimented with building a language around ownership, but for me it all demonstrates that the idea is not viable. I tried to read 10 tutorials already, each leaving me more confused than ever before.
Some serious voodoo science is going on here, with a good chance to become a next fad. Programming is difficult as it is, but apparently not difficult enough for someone's taste.
"mut f" means you can assign to "f". "f: &mut" means you can mutate through "f", for example assigning to "f.buffer". You can't assign to "f", to do that use "mut f: &mut". This is exactly same as distinction of "const T * v" and "T * const v" in C. The former is written "v: &mut T", the later "mut v: &T". "T * v" is written "mut v: &mut T". This will not change.
Name:
Anonymous2015-01-21 3:08
>>2,3,5 Were these copy pasted from reddit? (no offense if not)
What I like: - ownership system - no forced GC (GC is shit.) - fast - good compile time error checking capability - no memory related errors in non-unsafe blocks
It is almost perfect language. Only thing that's not perfect is the syntax and event that doens't suck too bad.
Name:
Anonymous2015-01-21 17:23
>>3 Just cause you don't understand something doesn't mean it's not viable. You don't understand the Universe, for instance, but it sure as hell is viable.
yeah it never got that far. as soon as people realized Option and Result were monads the devs derailed the higher-kinds train and proclaimed "Rust is not HASKAL."
an admin even changed the subreddit title to "The Rust Programming Language Does Not Have Monads" when it became apparent the devs were afraid of monads despite having decided they were the best fit in some places without actually realizing they were monads.
Name:
Anonymous2015-01-21 21:54
>>17 Except that higher-kinded polymorphism is useful for all sorts of type constructors that aren't even monads.
Name:
Anonymous2015-01-21 22:08
>>18 it isn't about monads it's about HASKAL. HASKAL has monads so rust better not have them. higher-kinded what now? oh helllll no.
HKT might actually come along someday but only if we all promise to never ever use it for do notation or anything else you find in HASKAL.
>>22 The syntax is clearly Sepples-inspired and I remember a core developer stating that they want the Sepples audience. I think it was even the reason why things like HKTs were rejected: To not scare away this crowd.
Name:
Anonymous2015-01-22 3:38
>>24 That has nothing to do with man-or-boy. If you could read you would know C++ does a fine job of the test and Rust wouldn't do such a poor job if it were more like C++. You're confusing syntax with semantics. You probably don't even know how the code in >>20 works.
FYI HKTs were not rejected, and I'll save you some time: nor were effects or dependent types.
>>20 <- man or boy test implementation in Rust >>21 <- “>>20 This is why you don't pander to Sepples programmers.” >>22 <- don't argue with muh dubs. >>24 <- arguing with mah dubs. etc.
>>24 So they are making a language that is almost exactly like Sepples but it's not Sepples, and hope that the Sepples crowd abandons Sepples in favor of another Sepples with a slightly different syntax? Good luck with that.
Should've just added borrow analysis to C++ and called it a day. Nobody needs all this hype about a "new language" that is actually just Sepples in disguise.
Should've just added borrow analysis to C++ and called it a day.
So you're calling for yet more crap piled onto C++ which would be incompatible with most of the crap that already exists in C++? What do you propose to do about lifetime annotations?