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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

221–230 of 301 posts

Re: The struggle with Rust

#221

Post by gravypod »

junke wrote: post #207
gravypod wrote: post #92

Earlier quoted context omitted.

> Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part. I think there are two solutions to that problem. The first is to involve HCI people in the development in the language to see how they can improve the ou…

This example works in SBCL, where types (possible disjoint sets of values) are treated as assertions. By default I always set "safety" and "debug" to 3 (the max), which helps. ;; Giving names to abstract things a little (deftype zero () `(eql 0)) (deftype non-zero () `(and number (not zero))) ;; Declaration (declaim (ftype (function (number non-zero) number) divide)) ;; Definition (defun divide (n d) (/ n d)) ;; Test…

Yes that is exactly what I'd like but I'd like something that's grown past just type checking. There are many more bugs that I know can be caught by a theorem prover.

Edit: I want to clarify. I think just type checking should be written as "Just type checking".

Re: The struggle with Rust

#222

Post by rbehrends »

codygman wrote: post #220
rbehrends wrote: post #212

Earlier quoted context omitted.

> Great! I believe, by that definition, your assertion that "good" typesystems don't reduce expressiveness is false, at least for common type systems such as Haskell's, Java's, ML's, etc. Haskell is not very good at extensible runtime polymorphism (one of its weaknesses). Try OCaml's polymorphic variants.

After quickly scanning https://realworldocaml.org/v1/en/html/variants.html , isn't the same thing accomplished by GADTs?

The point of polymorphic variants is that the entire type doesn't have to be fully defined in one place; you can have partial definitions in a module and those definitions can even overlap. You can have (say) [ `Int of int | `String of string ] in one module and [ `String of string | `Char of char ] in another, and the typechecker will handle intersections and unions of these types.

Re: The struggle with Rust

#223

Post by braveo »

AsyncAwait wrote: post #179
braveo wrote: post #169

Earlier quoted context omitted.

> My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust. As someone who learned C++ first and later Rust, no it isn't. Rust's learning curve is a hell of a lot higher than C++'s. This reminds me of when Java was trying to compete with C++, you would have all these Java people making claims that HotSpot was going to take over the world and…

> Rust's learning curve is a hell of a lot higher than C++'s I had the exact opposite experience, i.e. Rust allows me to not worry about memory safety and allows me to think on a much closer level of abstraction to my problem domain than C++.

using != learning.

Re: The struggle with Rust

#224

Post by braveo »

kibwen wrote: post #191
braveo wrote: post #169

Earlier quoted context omitted.

> My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust. As someone who learned C++ first and later Rust, no it isn't. Rust's learning curve is a hell of a lot higher than C++'s. This reminds me of when Java was trying to compete with C++, you would have all these Java people making claims that HotSpot was going to take over the world and…

If you just want to write code that runs but that will suddenly break without warning an unknowable time into the future, then C++ has a lower learning curve. If you want to code defensively and write software that isn't going to eat your laundry, then the learning curve for C++ surpasses Rust in steepness, because of the sheer number of things you have to learn not to do.

No student in any language learns by writing production ready code.

Anyone who thinks this is what it means to learn a language is attacking a strawman.

Re: The struggle with Rust

#225

Post by humanrebar »

braveo wrote: post #158
humanrebar wrote: post #138

Earlier quoted context omitted.

> No, unsafe would be overkill I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.

> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

Re: The struggle with Rust

#226

Post by braveo »

drbawb wrote: post #178
braveo wrote: post #166

Earlier quoted context omitted.

In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere. Which is what's being discussed.

>and if it's really that painful to do systems level things, then there's a problem somewhere. To me it's not a problem at all, Rust is working exactly as designed. When you start writing code in the style that Ayende has: its memory layout becomes entirely non-obvious. The structure definition no longer lines up with how that memory is actually being used. You'll need documentation of the sentinels & invariants, you…

> I would much rather be able to grep for `unsafe {}` and audit parts of a trie-map for memory safety, as opposed to auditing my entire program for memory safety violations.

you mean auditing the entire implementation of the trie data structure, not the entire program.

Guess what?

In rust, if you use unsafe, you also have to audit the implementation of the entire trie datastructure.

And if you think you don't, then I submit you don't understand Rust safety that well.

Re: The struggle with Rust

#227

Post by braveo »

Manishearth wrote: post #206
braveo wrote: post #166

Earlier quoted context omitted.

In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere. Which is what's being discussed.

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that wor…

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code.

If you're adding performance considerations I think the answer is going to be yes.

Re: The struggle with Rust

#228

Post by dbaupp »

steveklabnik wrote: post #175
zzzcpan wrote: post #104

Earlier quoted context omitted.

As I understand it, you can't disable just borrow checker somewhere where you don't need it.

It's subtle. Unsafe Rust is a superset of safe Rust; that is, all valid safe Rust code is valid unsafe Rust code. fn foo() { unsafe { let x = &5; // this is still going to get borrow checked } } Since it's a superset, it gives you access to new tools, that don't interact with the borrow checker, rather than "turning the borrow checker off". fn foo() { unsafe { let x = *const 5; // this is not going to get borrow chec…

(*const is not valid syntax: the way to not-borrow something is to coerce/cast it to an unsafe pointer within the statement, so that the borrow ends at the ;, e.g. give x an explicit raw pointer type in the first example.)

Re: The struggle with Rust

#229

Post by sfilargi »

pmoriarty wrote: post #190
gnuvince wrote: post #11

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

I never got past the pain-in-the-ass stage of dealing with the OCaml compiler. I hated wrestling with it for something simple. It really slowed me down to no end. I remember asking on freenode's #ocaml for help with a convoluted error message, and when I was told what it meant and how to fix it, I asked how the person who helped me knew what it meant. He told me he'd taken two semesters of type theory courses at uni.…

What helped me when starting with OCaml is always declaring the types in the function's arguments. The compiler errors started making a lot more sense.

Re: The struggle with Rust

#230

Post by steveklabnik »

dbaupp wrote: post #228
steveklabnik wrote: post #175

Earlier quoted context omitted.

It's subtle. Unsafe Rust is a superset of safe Rust; that is, all valid safe Rust code is valid unsafe Rust code. fn foo() { unsafe { let x = &5; // this is still going to get borrow checked } } Since it's a superset, it gives you access to new tools, that don't interact with the borrow checker, rather than "turning the borrow checker off". fn foo() { unsafe { let x = *const 5; // this is not going to get borrow chec…

(*const is not valid syntax: the way to not-borrow something is to coerce/cast it to an unsafe pointer within the statement, so that the borrow ends at the ;, e.g. give x an explicit raw pointer type in the first example.)

gah, i always mess this up, haha
Post reply on HN