Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

231–240 of 277 posts

Re: Announcing Rust 1.20

#231

Post by mikebenfield »

everheardofc wrote: post #198
mikebenfield wrote: post #113

Earlier quoted context omitted.

> What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too. So if I just take C's structs and add the ability to associate structs with functions using a "struct.function" notation, I now have classes? If so, a class isn't a very powerful concept, is it? Here's an easy way to s…

Because nobody bothers with "OOP" or "FP" because there is not a single cannonical implementation of these that everyone agrees on. What you're talking about has nothing to do with neither. Any language that has generics can have self types or whatever you want to call them. It's a matter of whether the language has a strong static typesystem and most FP-style languages have these and a minority of OOP-style language…

You seem to be trying to argue with me, but the points you're making are pretty much orthogonal to the ones I made. If you think OOP is not a meaningful concept, you should be arguing with the comment I was replying to, not me.

Re: Announcing Rust 1.20

#232

Post by dbaupp »

sanxiyn wrote: post #209
dbaupp wrote: post #21

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.…

That's a great point and one I hadn't considered, thanks!

Re: Announcing Rust 1.20

#233

Post by steveklabnik »

chrismorgan wrote: post #190
steveklabnik wrote: post #172

Earlier quoted context omitted.

It's not really about that; the post is almost done, and you should see it soon. It was a lot of work to go through.

While thinking about such things—what happened to https://underhanded.rs/ ?

Results post should be up soonish; I know it's being worked on.

Re: Announcing Rust 1.20

#234

Post by staticassertion »

jacobush wrote: post #202
alphaalpha101 wrote: post #193

Earlier quoted context omitted.

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…

Here have an upvote. Can someone else comment/refute this?

Sure...

* Most developers are not writing data structures, so optimizing for that seems unnecessary.

* There is work and research going into verifying unsafe code

* I think historically we can see that most memory safety vulnerabilities are not going to be in some lower level data structure, which is well encapsulated and likely already built by someone else, but in the use of that data structure. In particular - sharing references and also invalidating data safely without leaving references to that data. Rust helps you here, and this seems like the far better target.

* Even if your rust code uses unsafe, you still have benefits - you know where to audit for unsafety, you know where to pay extra close attention, and you can still write a large portion of your code in safe rust.

Re: Announcing Rust 1.20

#235

Post by dmix »

Animats wrote: post #183
dmix wrote: post #161

Earlier quoted context omitted.

Is that a fancy system that nobody will understand or use properly? (Honest question)

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 really changed the way I viewed/approached math.

The use-case analogies for formal verification can probably best be drawn from automated testing and TDD. Which is another 'optional' part of programming with varying degrees of usage - although with a lower barrier to entry.

Types/proofs seem to have a positive influence on the 'best practice' part as well, as it promotes a programming style which force you to really consider the implementations you're coding. Very similar to testing.

At the moment formal proofs tools today seems to me like a rabbit hole with questionable practical ROI so I've been hesitant to try out the current state-of-the-art.

Assuming it does get built in to the language, even if it doesn't get used by the user they will likely benefit just by being able to build on layers beneath that were proven in the standard/popular libraries. I felt a similar feeling of assurance when building on top of well-typed Haskell libraries.

Re: Announcing Rust 1.20

#236

Post by a_t48 »

cesarb wrote: post #230
a_t48 wrote: post #153

Earlier quoted context omitted.

A hashmap being implemented on top of vectors is a pretty common implementation. Not sure what Rust uses though.

IIRC, Rust's HashMap uses a single raw vector containing for each entry its hash code, its key, and its value; empty entries have a special hash code as a marker, with the key/value left uninitialized. Also, the hashes are kept together (separate from the rest) for better cache behavior during the linear probing.

Wouldn't that be two parallel vectors? (Side note: nobody ever thinks to bring up cache behavior in interviews where I ask about how a hash map could be implemented - it's nice to know that the library writers care :) )

How does that special hash marker work? What happens when something actually hashes to it? Just silently increment the hash?

Re: Announcing Rust 1.20

#237

Post by ComputerGuru »

skariel1 wrote: post #90
fish_fan wrote: post #81

Earlier quoted context omitted.

While it may be simpler, it also removes any safety that rust adds. I'd imagine you'd get more mileage out of just using pointers and unsafe blocks liberally to get lifetime checking where you can.

It is still safer than c, as it will not allow any segfaults. The only thing that can happen is a runtime error but no memory corruption so it is more akin to say Java or Go

You are describing the behavior of standard, safe rust code.

Using unsafe blocks throws all that away.

Re: Announcing Rust 1.20

#238

Post by ComputerGuru »

hashmal wrote: post #121
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Quite often in Rust, the way to make it easier is to go one step back: instead of thinking about how to make a tree right, you might want to think about why you want a tree in the first place. Sometimes it's the right thing to do, sometimes there is another approach that fits Rust's paradigm better. Speaking of paradigms, although Rust definitely looks "imperative", the ownership system makes it bloody different. Try…

> instead of thinking about how to make a tree right, you might want to think about why you want a tree in the first place.

Sure. But that's true for every programming languages, at least in my experience.

Anyway, someone, somewhere will actually want/need that tree. And they'll run into the aforementioned problems.

Re: Announcing Rust 1.20

#239

Post by ComputerGuru »

slavik81 wrote: post #89
GolDDranks wrote: post #30

Earlier quoted context omitted.

Yes, it is, for 32-bit floats. However, most of the time you don't need to specify that, because it will be inferred from the context. (And if it isn't you can introduce hints like `let growth_rate: f32 = 50.0/140.0`) Also, Rust supports having _ anywhere in number literals. Some may argue that it makes things even noisier, but it helps to separate the suffix from the value itself: `100.0_f32`.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference: Rust: fn main() { let a: f32 = 1e7 + 0.5 + 0.5; let b: f32 = 1e7f32 + 0.5f32 + 0.5f32; println!("{}", a==c); // true } C: #include int main() { float a = 1e7 + 0.5 + 0.5; float b = 1e7f + 0.5f + 0.5f; printf("%s\n", a==b ? "true" : "false"); // false } That's awesome. I'm tot…

The reason this works the way it does is that rust does not provide any cross-type arithmetic operators; as in you can't multiply a signed int and unsigned int or a float and an u8 without casting one of them to the same type as the other.

That means for the example you posted works is because the only valid operation that line of code can be resolved to as-is would be the case where all untyped values are inferred to be float by the inference engine.

Re: Announcing Rust 1.20

#240

Post by ComputerGuru »

knz42 wrote: post #146
kbenson wrote: post #120

Earlier quoted context omitted.

> While f might be a nicer suffice than f32, no suffix is even better. Well, isn't float in C and C++ platform dependent, and just usually 4 bytes on common platforms? I like the idea of being explicit in the storage type, even if it's slightly more verbose.

No. ISO C has standardized "float" to 32 bits and "double" to 64 bits. The one that's platform-dependent is "long double".

And, oxymoronically, plain, old long.

In particular, everything but MSVC treats long as 64 bits, but MSVC treats it as 32 bits for backwards compatibility.

However, I haven't used int or long or long long in ten years or so. Thanks to stdint.h support finally making its way to all platforms, it's exclusively sized types like int32_t and uint16_t for me.

Post reply on HN