Rust has gotten too fancy
By "templates" you mean macros? If so, how should a language implement the functionality that's currently delivered by macros?
I'm asking because I'm thinking about adding HKTs (higher-kinded types) to Rust.
> it's at least as complex as C++
- The functional control flow style, where everything involves closures, is much harder to understand than imperative control structures.
They're not opaque. Templates are more opaque because of the lack of self documenting bounds, perhaps (i still wouldn't call them opaque, just more so than Rust generics)
This is the millionth time you're repeating that garbage about imperative control flow. It boils down to a use of closures in a few stdlib functions. We've had this argument before, the essence of your point is that it is different from C. Of course there is a learning curve but that is there the other way too. Once you get used to it the control flow is pretty straightforward. And in most cases you can avoid the closures and write your if or loop manually.
Type Option. The 2014 version.[1] The 2016 version.[2]
(Coming soon, the "?" operator.[3])
Here's an example of excessive cleverness [4]:
fn main () {
let number: f64 = 20.;
// Perform a pipeline of options.
let result = Some(number)
.map(inverse)
.map(double)
.map(inverse)
.and_then(log)
.map(square)
.and_then(sqrt);
// Extract the result.
match result {
Some(x) => println!("Result was {}.", x),
None => println!("This failed.")
}
}
The designers of Go knew when to stop. The designers of Rust don't.
[1] https://web.archive.org/web/20140814230239/http://doc.rust-l...
[2] https://doc.rust-lang.org/std/option/enum.Option.html
Nor are you forced to use code like the excessively clever version you talk of. People who are used to monadic programming have the choice to.
You're making the same crappy arguments like a broken record. I'm not having the same tired old discussion again.
'.map' maps over the option. '.and_then' is the monadic bind operation, that you find in pretty much every modern programming language (frequently named 'flatMap'; even Java has this nowadays).
Yeah, i remember using the Mac OS written in Pascal. Strangely enough, i remember it being buggy as hell and crashing pretty often (no memory protection at all).
Also C standard library cannot be implemented without using Assembly, unless one makes use of extensions not defined in ANSI C.
If I was talking about inline Assembly, which Turbo Pascal supported and to this day still isn't part of ANSI C, I would have said so.
The only times I actually was forced to use inline Assembly was to optimize graphics rendering and create a mouse device driver.
Both of them were a one time project.
Once upon a time I used to have some fun asking C devs for features not available in Turbo Pascal, while at the same time showing off all the safety and large project features that Turbo Pascal had and C to this day still lacks.
Back on those MS-DOS and Windows 3.x days there wasn't any feature that C compilers had and Turbo Pascal didn't had a similar feature.
program demo;
uses Dos;
var
regs : Registers;
begin
regs.ah := $02;
regs.dl := $07;
MsDos (regs); { Beep! }
end.But this is up to you to enforce.
2) & 3) are pretty much covered in undergrad CS programs. If it hurts, you're doing it wrong - you don't have to dip that deeply in to OO to find excellent patterns for solving it, of you even need to go that far.
On certain platforms like the Win32 API, 2) &3) are hopeless by, it seems, design. Just do your best then :)
The latter sentence sounds like a non sequitur.
C has three fundamental issues:
1) How big is it?
2) Who owns it?
3) Who locks it?
C's lack of help in dealing with all three is the main cause of most memory-related program bugs. I once tried to fix #1 in a backwards compatible way. See [1]. After much discussion on some mailing lists, there was general agreement that this was technically feasible but not politically feasible.
(I once had hope that Rust would replace C, but Rust has gotten too fancy, with too much input from the functional programming people, the template enthusiasts, and the type theorists. Rust isn't bad, but it's at least as complex as C++.)
[1] http://www.animats.com/papers/languages/safearraysforc43.pdf