5 ms·

I believe it's called Rust :)

The_rationalist 7y ago
Sadly rust lack some big features that c++ has like polymorphic inheritance, function overriding and function overloading.
- SaxonRobber 7y ago
  I think that is for the best. I prefer less implicit behaviour in my code, even if it means my identifiers get longer.
  - NotCamelCase 7y ago
    Rust doesn't have function/operator overloading yet or it won't have it at all? I am vastly for clarity and simplicity over vague, implicit stuff but doing e.g vector operations can get very unreadable very quickly without it.
    - pjmlp 7y ago
      Rust has operator overloading, https://doc.rust-lang.org/rust-by-example/trait/ops.html https://doc.rust-lang.org/rust-by-example/trait/ops.html
    - SaxonRobber 7y ago
      Vector operations are one of the few cases where I think operator overloading is sometimes a good idea.
  - adev_ 7y ago
    That's a design choice. Less implicit means safer but also more verbose and more cumbersome to write. Rust priorities safety over everything else, also over productivity too in some case. Absence of function overloading and automatic type conversion is a good example of that in Rust. Is it the right choice ? Only time and multi-million line codebase will tell us.
- the_why_of_y 7y ago
  Rust has "function overloading: the good parts" in the form of traits, inspired by Haskell's typeclasses. Rust does not provide the facility to strategically obfuscate code at scale like C++-style function overloading does.
Koshkin 7y ago
“fn... fn...” - No, that doesn’t sound like C++, at all.
- dtolnay 7y ago
  Fn is spelled differently than auto but it sounds more like C++ than you might think. // C++ auto f() -> int32_t { return 1; } // Rust fn f() -> i32 { return 1; }
- Iwan-Zotow 7y ago
  #define fn auto
  - Koshkin 7y ago
    Not a good idea: fn i = 0;
vaylian 7y ago
Rust is definitely a contender in the space. But philosophy-wise I think Walter Bright's D comes much closer.
zrm 7y ago
> I believe it's called Rust :) Yes, but no. When people design a language which they know is going to be incompatible, they tend to go all the way with it. If we're breaking it anyway then might as well do a better standard library interface than the stuff designed in the 90s and all that sort of thing, right? And that's good to have for new projects. But there is a benefit in having something which makes the smallest possible compatibility-breaking change to fix the defect in the original. So you have a "new language" with a borrow checker, but the standard library functions all have the same names and the same purpose and time complexity as the C and C++ ones, which would allow people to run the existing code through a transpiler which for 80% of the lines can be translated directly to working code in the new language, and produces diagnostic errors for the other 20% that explain what needs to be changed. Which removes 80% of the work from transitioning an existing codebase to the new language. And then more people do that.

Sadly rust lack some big features that c++ has like polymorphic inheritance, function overriding and function overloading.

SaxonRobber 7y ago
I think that is for the best. I prefer less implicit behaviour in my code, even if it means my identifiers get longer.
- NotCamelCase 7y ago
  Rust doesn't have function/operator overloading yet or it won't have it at all? I am vastly for clarity and simplicity over vague, implicit stuff but doing e.g vector operations can get very unreadable very quickly without it.
  - pjmlp 7y ago
    Rust has operator overloading, https://doc.rust-lang.org/rust-by-example/trait/ops.html https://doc.rust-lang.org/rust-by-example/trait/ops.html
  - SaxonRobber 7y ago
    Vector operations are one of the few cases where I think operator overloading is sometimes a good idea.
- adev_ 7y ago
  That's a design choice. Less implicit means safer but also more verbose and more cumbersome to write. Rust priorities safety over everything else, also over productivity too in some case. Absence of function overloading and automatic type conversion is a good example of that in Rust. Is it the right choice ? Only time and multi-million line codebase will tell us.
the_why_of_y 7y ago
Rust has "function overloading: the good parts" in the form of traits, inspired by Haskell's typeclasses. Rust does not provide the facility to strategically obfuscate code at scale like C++-style function overloading does.

Koshkin 7y ago

“fn... fn...” - No, that doesn’t sound like C++, at all.

dtolnay 7y ago
Fn is spelled differently than auto but it sounds more like C++ than you might think. // C++ auto f() -> int32_t { return 1; } // Rust fn f() -> i32 { return 1; }
Iwan-Zotow 7y ago
#define fn auto
- Koshkin 7y ago
  Not a good idea: fn i = 0;

vaylian 7y ago

Rust is definitely a contender in the space. But philosophy-wise I think Walter Bright's D comes much closer.

zrm 7y ago

> I believe it's called Rust :) Yes, but no. When people design a language which they know is going to be incompatible, they tend to go all the way with it. If we're breaking it anyway then might as well do a better standard library interface than the stuff designed in the 90s and all that sort of thing, right? And that's good to have for new projects. But there is a benefit in having something which makes the smallest possible compatibility-breaking change to fix the defect in the original. So you have a "new language" with a borrow checker, but the standard library functions all have the same names and the same purpose and time complexity as the C and C++ ones, which would allow people to run the existing code through a transpiler which for 80% of the lines can be translated directly to working code in the new language, and produces diagnostic errors for the other 20% that explain what needs to be changed. Which removes 80% of the work from transitioning an existing codebase to the new language. And then more people do that.