[zerofan]

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever'

I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, and many other things.

If I tried to advocate Rust in my office, many of my coworkers would simply say, "I didn't have to do that in Fortran, and Fortran runs just as fast. Why are you wasting my time?!"

[yawaramin]

Almost everything you mentioned as 'clever' is trying to achieve either type-safety or memory-safety. To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

[zerofan]

I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity. Rust deserves credit for it's good ideas, but these aren't those, and I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists [1].

> To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

They don't really care about memory deallocations - the program will finish soon anyways, and the operating system will cleanup the mess. Sorry, they've already excused you from the office and have gotten back to getting their work done.

Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... (yes, most people disregard benchmarks, but you need someway to discuss performance)

[yawaramin]

> I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity.

Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental, or in fact how some of them are worse than the exact same features in Swift, which you mentioned.

> ... I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists....

Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Also, you have to look at the quality of the compilers themselves. Rust is universally acknowledged to be a high-quality compiler, while Swift (especially together with Xcode) are often bemoaned as buggy and crashy.

> They don't really care about memory deallocations ... the operating system will cleanup the mess.

Well, I have to say they are an extremely lucky bunch. Most systems programmers don't have the luxuxy of writing script-sized programs which use the OS as their garbage collector.

> Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

I was specifically replying to your Fortran example, but for the sake of argument, to C++ programmers I'd ask, 'Would you like to do high-performance concurrency with statically guaranteed no data races?'

[kibwen]

> a multitude of string types

There are two string types in Rust, `String` (growable and heap-allocated) and `&str` (a reference to string data). Anything else is just a shim for FFI.

[zerofan]

> There are two string types in Rust, `String` [...] Anything else is just a shim for FFI.

I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.

[kibwen]

I think it's especially hasty to criticize Rust's string types in the context of C++, given the standardization of string_view in C++ as an analogue of Rust's &str :P

[zerofan]

To me, Rust's &str seems a lot more like const char* (with a size tacked on for bounds checking). But you're the expert, so if I did agree they were the same, then C++ adopting it in the STL is practically proof it's a mistake in Rust.

You never addressed my other "too clever" items in Rust. Does that mean, other than strings, we agree?

[kibwen]

> Does that mean, other than strings, we agree?

Not necessarily. :P Features exist, and I'm not about to dictate where others draw the cleverness line.