241–250 of 277 posts
Earlier quoted context omitted.
GLSL programmers may rejoice in learning that `1.` is accepted syntax too.
Having used Rust since pre-release I'm slightly embarrassed that I'm only learning about this today.
"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed that the above wasn't in Rust to begin with, though. Can't think of any other languages which has classes but no class methods/variables.
I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book ( https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht... ) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit in…
JavaScript code bases use a lot of classes, but while JavaScript supports inheritance, it's use isn't particularly idiomatic. What is idiomatic is duck typing (checking for the presence of method or property on an object). This is basically the same as using traits, except without compile time correctness guarantee. You even have things like `Symbol.iterator`[0], which allow an arbitrary object to work with a `for..of` loop, exactly like `impl Iterator` in Rust.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Earlier quoted context omitted.
I don't know, ensuring memory safety at compile time and safe concurrency is a pretty big win for me over C, I know many people who claim that they can write/debug C programs to be memory safe, however the real world would respectfully disagree.
Rust doesn't ensure memory safety or safe concurrency. It ensures memory safety - including data race safety, just one part of safe concurrency - assuming you never use any unsafe code and that the standard library is free of bugs. I'm happy to assume the standard library is free of memory safety bugs, because you have to trust something. But I'm not happy trusting that dependencies aren't using unsafe code, and I'm…
Earlier quoted context omitted.
Most of us write new, complex data-structures, that aren't part of the stdlib or a crate, like once a year, at most. Those are hard in Rust if they involve circular pointers. They're hard in C/C++ too, but in a different way (easier to write the code, harder to be sure it's correct). The idea that Rust would be no better than C/C++ because of the latter parts doesn't make much sense. This kind of work is unusual for…
It doesn't matter that it's 'kind of unusual', even though I contend that it isn't. Even if, for the sake of argument, we assume that it is, that doesn't change my point. My point is that the whole point of Rust is supposedly that it >is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. except that when you look at any of the examples of code that really would…
This seems to be the point of disagreement here, and I think evidence clearly shows that you are wrong. Sure, Rust doesn't help you when writing the implementation of e.g. circular data structures. But what it does do is provide, far beyond C or C++, the tools for the author of that data structure to enforce that it's used correctly.
And as mentioned upthread, most memory/concurrency (especially concurrency) bugs are not in the implementations of these structures, but in their use. So Rust is a fantastic win here, empirically speaking. Look at the rate of memory safety bugs in Rust programs vs C++ programs- Ripgrep vs grep, Servo/Quantum vs Firefox, etc.
Earlier quoted context omitted.
Are there any stats yet on improvements in memory safety within Firefox attributable to Rust. In theory, it could be as much as 50% fewer based on the original premise of Rust removing whole classes of programmer errors, but are there stats from Rust being in the wild? The CSS replacement reminded me that there should be something to compare.
> are there stats from Rust being in the wild? I don't know, but if I recall correctly, nobody has ever reported a memory safety bug to ripgrep, or even the underlying regex engine. I don't really know how many people use ripgrep, but it's not zero.
Earlier quoted context omitted.
You often don't need it at all; fn foo(x: f32) { println!("{}", x); } fn main() { let x = 5.0; foo(x); } It will look at the signature for foo, and infer that x must be f32.
Whoa! Isn't this kind of inference dangerous? It seems that whichever call comes first is used to infer the type, so a single added line of code can change the type of a variable… fn foo32(x: f32) { println!("{}", x); } fn foo64(x: f64) { println!("{}", x); } fn bar64() { let x = 5.0; // f64 foo64(x); foo32(x); } fn bar32() { let x = 5.0; // f32, not f64 foo32(x); foo64(x); }
fn foo32(x: f32) { println!("{}", x); }
fn foo64(x: f64) { println!("{}", x); }
fn bar64() {
let x = 5.0; // f64
foo64(x);
foo32(x as f32);
}
fn bar32() {
let x = 5.0; // f32, not f64
foo32(x);
foo64(x as f64);
}Earlier quoted context omitted.
Have you read "Learning Rust With Entirely Too Many Linked Lists"[1]? I think it will be quite helpful for these kind of situations. It walks you through all the possible tools in the language that is available to you, and at the end, if you just want to write it how you would in C, you could always do it "unsafely" with raw pointers (which is no worse than C). --- [1] http://cglab.ca/~abeinges/blah/too-many-lists/bo…
It's also really no better than C. Or at least no better than C++. This is my main issue with Rust. It doesn't seem to really solve the right problem. I feel like it solves the easy problems that I already know how to solve easily, but as soon as I get to something that really, truly feels like I want it, the best solution is unsafe. A complicated circular linked data structure is exactly where I want the language to…
Edit: or try something like Idris. But I think you're asking too much of today's rustc.
Is there a book on Programming Data Structures in Rust. Like from scratch. Trees, Graphs etc. I would expect the first 2 to 3 chapters to be on Rust pointer system and the rest of the book to be on implementing Data Structures using the pointer system. Similar to like Tanenbaum's book for Data Structures in C or Kruse, Leung and Tondo's book for Data Structures in C.
Earlier quoted context omitted.
Probably. I used to do formal proof of correctness work and headed a project to build a verifier.[1] That stuff is very hard. The partially initialized array thing is an issue of expressive power. You can't talk about that in Rust yet. This is a classic issue. The three big headaches in C around memory safety are "how big is it", "who owns it", and "who locks it". The language lacks the syntax to even talk about thos…
> Before you can even consider verifying something, you have to be able to talk about it in some formal language. Preferably the one you're programming in. I'd personally be excited too see a modern language implement this. I saw the potential for this type of verification in my (hobbyist) dabbling with Haskell. Which subsequently inspired me to relearn math, including a great book on proofs recommended on HN which r…
But Pascal was a small language. Getting this into today's bloated languages is tough. Back then, we looked at Ada, sized the project, and realized it was comparable to building an optimizing compiler for the language.
[1] http://www.animats.com/papers/verifier/verifiermanual.pdf
Earlier quoted context omitted.
Having aggregate data types and syntactically having methods seems like a very facile definition of "OOP", versus the conventional uses referring to Smalltalk style message passing or inheritance and overrides. Other than being able to call functions as x.foo() rather than foo(x) or foo x or similar, languages like Haskell and C seem to satisfy the requirements for being OOP, which seems to make "OOP" completely usel…
I actually think having syntactic methods is an important (if not the most important) part of "OOP". You compared x.foo() with foo(x), but that's the wrong comparison. The correct comparison is that when x if of type Tree, x.foo() vs tree_foo(x). Otherwise you get name clashes. That is, I think the essence of "OOP", OOP-as-used, not any theoretical OOP, is function name resolution depending on type. That and syntax.…
[obj doStuff: foo withBar: bar]
objc_msgSend(obj, NSSelectorFromString(@“doStuff:withBar:”), foo, bar)