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

Why is Rust difficult?

vorner.github.io

Post reply on HN
Print view View original

211–220 of 260 posts

Re: Why is Rust difficult?

#211

Post by pjmlp »

pmarcelll wrote: post #201
pjmlp wrote: post #71

Earlier quoted context omitted.

> Callbacks by definition create multiple paths to the data. How come, when you have a struct method, accessing field members only visible to that specific method. Something that is very easy to do with moving in lambda contexts in C++.

The quoted sentence is not true, but most practical callbacks will create multiple paths to objects via borrows. Or you can move your structs into closures (like in C++). But I think what you originally wrote (using callbacks without Rc/RefCell) is fundamentally hard. You have to guarantee somehow that the struct is still alive when you access it though the borrow in the callback, otherwise you have a memory safety p…

The situation I was having issues is explicitly acknowledged by the NLL RFC as being an issue.

It is related to closure desugaring.

https://github.com/nikomatsakis/nll-rfc/blob/master/0000-non...

Re: Why is Rust difficult?

#212

Post by wasted_intel »

k__ wrote: post #104

Because it forces you to handle edge cases. Java is also harder than JavaScript because of this. Yes, the edge cases Rust forces you to handle are different than those of Java and probably make more sense to solve, but I think this is still the root of the "problem". While edge cases are part of "the rule" they feel like exceptions of it. Most of the time you write 80% of the program code in 20% of the time and the r…

You can also opt to skip handling these edge cases by either copying (decreasing performance) or unwrapping (decreasing reliability). The great thing is that Rust gives you the choice.

Re: Why is Rust difficult?

#213

Post by AnimalMuppet »

pjmlp wrote: post #124
vardump wrote: post #113

Earlier quoted context omitted.

I think you're nitpicking. That's close enough in my book. Those MCUs are tricky targets and I can certainly live for example with not being able to pass structs as return values. Or without re-entrancy. Perfectly understandable once you take into account limited IRAM space, 128 or 256 bytes, where stack, register banks and most of your temporaries and globals need to reside.

Which validates my point of using C on 8 bit CPUs being a challenge.

"Less than absolutely total standard compliance" != "a significant challenge compared to absolutely total standard compliance", especially if the differences are clearly documented.

Re: Why is Rust difficult?

#214

Post by kqr »

goldfire wrote: post #209
kqr wrote: post #128

Earlier quoted context omitted.

Second the Ada note. That language is so well constructed and thought out on many levels. ...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.) It's a shame because - Ada generic packages are exactly what C++ templates should have been - Derived types and record extension is inheritance that m…

The thing that kept me from trying Ada (back a couple of years ago when I was writing firmware and so was kind of on its home turf) was a lack of good resources for learning it. I got a copy of the book "Programming in Ada" by Barnes, and did not find it very helpful. Often the advice seems to be to go read the Reference Manual, which I agree is highly readable for a language standard, but it's not aimed at users of…

> it's not aimed at users of the language.

Is it not? It doesnt contain recipes, no, but it fully documents the fundanental units of the language youll express your solution in.

Re: Why is Rust difficult?

#215

Post by stmw »

majewsky wrote: post #98
tatterdemalion wrote: post #16

Earlier quoted context omitted.

What we could do better than we do today - and your comment about ergonomics alludes to our work to improve this - is ease the onboarding of that complexity we have to be "honest" about. Its a design constraint of Rust that it must maximize user control, but that does not imply that users have to be faced with all of those choices as soon as they first try to write Rust. In some respects I think this article is an at…

I would like a language that has knobs (e.g. file-level pragmas) for strictness, which you could turn all to one side (to get something as strict as Rust) or all the way to the other side (to get something like Ruby) or somewhere in between. For example, a REPL would be pretty non-strict: When you define a function, you don't have to annotate types on the arguments, and everything gets passed around as generic object…

So Rust has a lot of that, both in turning off some checks and in ability to write whole blocks of unsafe code.

Re: Why is Rust difficult?

#216

Post by AnimalMuppet »

pjmlp wrote: post #143
kqr wrote: post #128

Earlier quoted context omitted.

Second the Ada note. That language is so well constructed and thought out on many levels. ...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.) It's a shame because - Ada generic packages are exactly what C++ templates should have been - Derived types and record extension is inheritance that m…

And the STL first implementation was actually done in Ada. :)

Yes and no.

Yes, Stepanov's first attempt at writing something like the STL was done in Ada. But no, it wasn't "the STL" - it was neither Standard nor Template.

And Stepanov abandoned Ada for C++, because Ada wasn't expressive enough for what Stepanov was trying to write.

Re: Why is Rust difficult?

#217

Post by pjmlp »

AnimalMuppet wrote: post #216
pjmlp wrote: post #143

Earlier quoted context omitted.

And the STL first implementation was actually done in Ada. :)

Yes and no. Yes, Stepanov's first attempt at writing something like the STL was done in Ada. But no, it wasn't "the STL" - it was neither Standard nor Template. And Stepanov abandoned Ada for C++, because Ada wasn't expressive enough for what Stepanov was trying to write.

Meaning if Stepanov had not played with Ada for its first implementation, followed by Bjarne advocating him to use C++ instead, the STL would never happened in its form.

And yes, it wasn't quite the STL, we had quite a few variations of it, the most well known coming from SGI, until things kind of settled at ANSI.

Re: Why is Rust difficult?

#218

Post by pjmlp »

AnimalMuppet wrote: post #213
pjmlp wrote: post #124

Earlier quoted context omitted.

Which validates my point of using C on 8 bit CPUs being a challenge.

"Less than absolutely total standard compliance" != "a significant challenge compared to absolutely total standard compliance", especially if the differences are clearly documented.

The challenge is not being able to write idiomatic ANSI C, rather trying to tame the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

Re: Why is Rust difficult?

#219

Post by pjmlp »

wott wrote: post #191
pjmlp wrote: post #124

Earlier quoted context omitted.

Which validates my point of using C on 8 bit CPUs being a challenge.

It is not a challenge, it is by far the most common way to program them.

Yeah not being able to write idiomatic ANSI C, rather trying to convince the compiler to produce code comparable to hand tuned Assembly to fit into those processors, the majority of time using compiler specific extensions.

Re: Why is Rust difficult?

#220

Post by Too »

bluejekyll wrote: post #61
jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I would normally define 'correctness' to include rigorous mathematical proofs. Do you have an example of a language that does what you're looking for? On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. > Go works wonderfully Go does work wonderfully, you should definitely use what you like. For me personally, though,…

C# Code Contracts can specify constraints (like range check, nullability, list sizes, etc) on inputs/outputs of functions and enforces these statically based on the code inside the function.
Post reply on HN