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

241–250 of 301 posts

Re: The struggle with Rust

#241

Post by GolDDranks »

steveklabnik wrote: post #238
AstralStorm wrote: post #234

Earlier quoted context omitted.

First, Rust does not prevent data races, just makes them pain to write. Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds) This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug. You can write arenas in Rust.

Just to be clear about the terminology (since I'm not sure if the grandparent knows about the difference): Rust prevents data races but not race conditions (although it makes it easier to avoid them). Here's an explanation about the differences: http://blog.regehr.org/archives/490

Re: The struggle with Rust

#242

Post by webmaven »

kibwen wrote: post #232
sh_tinh_hair wrote: post #204

Earlier quoted context omitted.

Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.

> or use anything written in it As I often say on HN, I must be missing the sarcasm here...

I think "use" in this case is in the sense of a developer using code, rather than an end-user application.

Re: The struggle with Rust

#243

Post by junke »

gravypod wrote: post #221
junke wrote: post #207

Earlier quoted context omitted.

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

As a matter of fact, I agree.

Re: The struggle with Rust

#244

Post by rntz »

rbehrends wrote: post #212
rntz wrote: post #199

Earlier quoted context omitted.

EDIT: I've been chewing over the following: > This means that we can trivially translate a dynamically typed program into a statically typed program, though obviously we don't gain anything by that at this point (this is essentially an argument that Bob Harper has advanced before) and we pay for it in additional verbosity. This is exactly the opposite of the argument I advance below; you're claiming that there is a "…

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

Okay, then I can pick another example: A dictionary where the type of the values depends on the key they're inserted under. (For example, a representation of the closure of a function in a typed language.) Of course, then I can go to a dependently typed language, but are you really going to tell me that only dependently typed languages count as "good" static type systems?

Re: The struggle with Rust

#245

Post by braveo »

Manishearth wrote: post #240
braveo wrote: post #227

Earlier quoted context omitted.

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

> If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.

I find that unfair. C++ has new as well as other mechanisms such as perfect forwarding into smart objects, but no one seems to think C++ qualifies for the "you can do systems programming without malloc and pointers"?

You can't do systems programming without them, what you can do is minimize their use by building abstractions, which other languages, such as C++ and D, already do.

So this idea that people somehow think you have to use the actual malloc call throughout your code is a bit of a strawman.

Re: The struggle with Rust

#246

Post by mixedCase »

braveo wrote: post #224
kibwen wrote: post #191

Earlier quoted context omitted.

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.

Worked for me when learning Go.

Re: The struggle with Rust

#247

Post by dbaupp »

AstralStorm wrote: post #239
pjmlp wrote: post #216

Earlier quoted context omitted.

> 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? To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches. Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages. Thankfully new l…

However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sac…

Rust gets all your favourite kinds of atomics and barriers, exactly like C. Other things are indeed hard to get safe, which is why Rust has `unsafe`: it is possible to use them, marking out the dangerous regions precisely, rather than the whole program being `unsafe` just because a few places need niche features.

In any case, Rust is definitely not written with "I have one CPU" in mind. A slogan that is sometimes used for Rust is "safe. fast. concurrent.", and it's one of the headline features on the front page: http://rust-lang.org/ . Rust's abstractions allows writing extremely high performance libraries like rayon, which, had better performance than even highly optimised C libraries like Cilk, in one benchmark I heard about. Building out that parallelism ecosystem takes time, so it does not seem particularly surprising that there are more (unsafe!) libraries for the 40-year-old language, than (safe!) libraries in the less-than-2-year-old one.

Re: The struggle with Rust

#248

Post by flukus »

crdoconnor wrote: post #32
rubber_duck wrote: post #22

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

The clincher for me with respect to rust is that I see a steady stream of useful software being developed in it. I never really saw that in Haskell and I've heard people talking about it for at least 15 years. That indicates that something is missing.

It's been the same with lisp for 40/50 years. A lot of evangelists but not a lot of people doing useful things with it. Rails did more for FP than lisp evangelists ever did.

Re: The struggle with Rust

#249

Post by camus2 »

the_af wrote: post #110
camus2 wrote: post #85

Earlier quoted context omitted.

> I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language Because they are required to be productive fast. A professional usually doesn't learn a new language just for the sake of it. If the language doesn't yield instant benefits then most people aren't going to bother learning it. If a steep learning curve is e…

C++ has a pretty steep learning curve, yet people use it. Many things in tech are tradeoffs. Sometimes the additional tools a language brings to the table are worth the learning curve, sometimes they aren't. There are people in the industry for which FP (or Rust, or whatever) is worth it. For you it isn't. That's life.

> C++ has a pretty steep learning curve, yet people use it.

C++ has 30+ years of libraries, so does C. To even think you can compare Rust and C/C++ on that matter is not realistic.

Re: The struggle with Rust

#250

Post by Manishearth »

braveo wrote: post #245
Manishearth wrote: post #240

Earlier quoted context omitted.

> If you're adding performance considerations I think the answer is going to be yes. You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.

I find that unfair. C++ has new as well as other mechanisms such as perfect forwarding into smart objects, but no one seems to think C++ qualifies for the "you can do systems programming without malloc and pointers"? You can't do systems programming without them, what you can do is minimize their use by building abstractions, which other languages, such as C++ and D, already do. So this idea that people somehow think…

I do think that C++ qualifies for that. I don't think there is widespread use of this yet -- I'm talking about the vast majority of "systems" code in C or C++ -- most of it is older and doesn't tend to use abstractions, or has been written from a "C with goodies" perspective.

So yeah, (modern) C++ also contests this claim too. Rust contests a stronger claim about safety as well.

------

You're the one who said that "it's claimed to be a systems level language, and if it's really that painful to do systems level things," -- my point is that in both Rust and C++, "systems level things" don't need to involve pointer arithmetic and other similar things. They should be niche tools you reach for when the abstractions fail you, and the abstractions should not fail you that often. This is already true for both languages, I feel. It's not "niche" in C++ because the ecosystem needs time to evolve to that point, but for new code it probably works out.

Post reply on HN