zlacker

[return to "A Look at Rust from 2012"]
1. assbut+OOl[view] [source] 2025-12-03 14:17:11
>>todsac+(OP)
Very interesting to see the ML influences like ~ for unary minus, unscoped enums, mut on specific struct fields...

It seems like over time, a lot of that was replaced with C++-style syntax and semantics. Presumably to make the language appeal more to C++ devs

◧◩
2. echelo+IVl[view] [source] 2025-12-03 14:53:00
>>assbut+OOl
Rust looks nothing like C++.

It looks like Ruby.

The generics look like Java.

◧◩◪
3. tialar+2dm[view] [source] 2025-12-03 16:16:00
>>echelo+IVl
How do you feel the generics "look like" Java ?

Implementation-wise they're the same trick as C++, monomorphization.

Stylistically they're not very like either, however the effect is more like C++ because Rust idiomatically prefers to constrain functions not types so e.g. it's fine to talk about HashMap<f32, f32> a hypothetical hash table of floating point numbers mapped to other floating point numbers - even though we can't use such a type because if we try to insert into it we'll be told that insert requires its key parameter to implement Eq and Hash, which f32 doesn't because of NaN.

In both C++ and Java as I understand it these constraints live on the type not the functions associated with that type, although C++ does not have the same constraint here and is perfectly willing to try to make a hash table of floats... but where a constraint lives on a function in C++ it would behave similarly to Rust due to SFINAE - the function won't match so your diagnostics say there's no such function, probably worse diagnostics than Rust but that's par for the course in C++.

[go to top]