291–300 of 360 posts
Earlier quoted context omitted.
A type is much denser, than a textual description, and in most cases sufficient.
Depends the type, it can be quite long and complicated. I always have a lot of issues trying to read return types from templated functions in C++ because they look really messy.
Earlier quoted context omitted.
Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.
That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)
This style of coding is so bad, that it turns out the example has a syntax error. Good luck finding it without the compiler or a quality editor though. Worse, the example doesn't actually work due to further bugs.
Anyway, rust by itself may be ok. Some of the core concepts are good, but the way people are using it is leading to inpenteratble messes of code. Code like the above combined with what seems excessive/unnecessary use of generics create problems for more advanced usage when it comes to learning and modifying a piece of code. Some people have blamed this on the language's learning curve, but I'm not sure that is appropriate. By itself the language is fairly straightforward, the difficulties occur when people are working around the language and pile in masses of write only code.
That particular code block IMHO is why rust is going to have a hard time truly gaining widespread usage. Even as someone somewhat familiar with rust, moving the example into a program, and modifying it in fairly trivial ways took me the better part of a day.
Earlier quoted context omitted.
The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…
I'm glad that Rust has no `auto`. I find this: fn map (it: I) -> impl Iterator where I: Iterator , U: From { it.map(|t| From::from(t)) } infinitely more readable than fn map (it: I) -> auto where I: Iterator , U: From { it.map(|t| From::from(t)) } The type signature of the first one clearly tells me that the return type is an `Iterator `, even though the actual type cannot be named because of the anonymous closure. T…
Having auto is a boon for certain design aspects. As system level programming language D offers everything in betterC mode. Of course it can offer more. But a small community can do only so much.
Earlier quoted context omitted.
D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".
What is the difference between the two?
In D, the ""borrow checker"" is being tacked on as an after thought, in an attempt to copy Rust. This means that it doesn't play nice with existing features and makes it difficult if not impossible to guarantee that memory isn't leaked or used after it was free'd. For example with exceptions. The checker doesn't check for exceptions and if memory is free'd correctly if an exception is thrown. This isn't a problem in Rust because it doesn't have exceptions so it doesn't have to worry about checking them so it can maintain its strong guarantee.
Earlier quoted context omitted.
That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)
Which helps out the documentation side, but destroys code readability. Particularly since rust users appear to really like creating long method call chains, frequently with a closure or two sprinkled in. Take this "example" https://github.com/diwic/dbus-rs#server . For a beginning user of the library that is nearly impenetrable without breaking each of those calls apart. Even if your pretty familiar with rust you sti…
Maybe this is just me misreading your phrasing, but why would you actually have to break it apart into `let` statements? You can look up the types without modifying the program. Or are you talking about asking the compiler for the types with the `let _: () = ...` (or similar) trick? At that point you can just ask an IDE, also without modifying the program.
Earlier quoted context omitted.
I’ve always liked the idea of Ada, but never had a place to use it. Though someone on HN pointed out that NVidia was using Spark for secure code sections. Quite interesting! Personally while D seems a great tool, I really keep running into situations where a language that lives on top of C/C++ is useful. So I’ve been trying out Nim for those use case, using the ARC GC which appears to work well for embedded. It’s det…
> I really keep running into situations where a language that lives on top of C/C++ is useful. > the biggest advantage is being able to directly interface with any C or C++ natively. D/Rust both seem to have difficulty being 100% onboard with C++ I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?
For libraries with a large API that can be an annoyance.
Earlier quoted context omitted.
D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".
Yes, you do create accounts to follow D around and complain about it.
Earlier quoted context omitted.
> I really keep running into situations where a language that lives on top of C/C++ is useful. > the biggest advantage is being able to directly interface with any C or C++ natively. D/Rust both seem to have difficulty being 100% onboard with C++ I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?
You just need to do a bit of tiresome explicit declarations to statically link the code. For libraries with a large API that can be an annoyance.
Earlier quoted context omitted.
That's the salient point of this thread though; Rust doesn't have type inference in any position that shows up in API documentation. (The closest thing Rust has is return types of `impl Trait`, but even that imposes a contract that the caller must adhere to and that the callee cannot see through.)
Which helps out the documentation side, but destroys code readability. Particularly since rust users appear to really like creating long method call chains, frequently with a closure or two sprinkled in. Take this "example" https://github.com/diwic/dbus-rs#server . For a beginning user of the library that is nearly impenetrable without breaking each of those calls apart. Even if your pretty familiar with rust you sti…
Most code samples get automatically tested, but READMEs currently do not.