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

201–210 of 260 posts

Re: Why is Rust difficult?

#201

Post by pmarcelll »

pjmlp wrote: post #71
Rusky wrote: post #68

Earlier quoted context omitted.

Callbacks by definition create multiple paths to the data. (You can also often get away with Cell rather than RefCell.)

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

Re: Why is Rust difficult?

#202

Post by smitherfield »

dolguldur wrote: post #162

Will Swift ever be able to span all the way down to enable Rust-like performance in places where it’s necessary? Or is it much more that it takes for a language to be a viable choice for starting new C++ type of projects with?

To (potentially) match Rust/C++ performance Swift needs

1. Stack and static-allocated arrays.

2. True pass-by-reference for value types.

3. A sufficiently-smarter compiler that's more often able to elide dynamic allocations, reference counting, bounds checks, vtables etc. (Lifetime semantics will help with this).

Re: Why is Rust difficult?

#203

Post by _pmf_ »

It's similar to learning Stateflow: it has a bigger upfront cost in program design, but once it's fully specified, the implementation will likely be correct (less degrees of freedom).

Re: Why is Rust difficult?

#204

Post by msla »

jonathanstrange wrote: post #123
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…

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

Ada is another non-C with odd semantics, so the problem is that it goes too far and not far enough: It's not enough like C to be familiar, but it's not far enough from C to be able to go head-to-head with Haskell. If I want something that's very safe and don't care about it being similar to C, I'm going all the way to Haskell and not bothering with half-measures.

Re: Why is Rust difficult?

#205

Post by blattimwind »

pjmlp wrote: post #78
blattimwind wrote: post #75

Earlier quoted context omitted.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge. C is the default and not a challenge on 8-bitters.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

Literally the whole industry doesn't care two bits about "100% ANSI C compliance", which I'd guess isn't even possible on a pure Harvard architecture like AVR or PIC.

Re: Why is Rust difficult?

#206

Post by Zalastax »

MaxBarraclough wrote: post #106
majewsky wrote: post #89

Earlier quoted context omitted.

> There's a lot of research that needs to be done before proven programs can become the norm. At least equally importantly, we need a new generation of developers to grow up with these tools before they can become the norm. In fact, the biggest contribution that academia could make to safe programs is to replace Java and C by Rust in all the programming courses, so that the next generation of developers is raised on…

As Zalastax was saying, by the standards of Coq, Rust doesn't have a strict mindset. Rust isn't the first language to emphasise correctness. We've had Ada for decades, but it's not taken over the world. Going to the extreme, full-bore formal methods will never be taught as introductory material on programming courses for the masses, but they will continue to be taught at good universities. I'm not sure this is a bad…

I hope we'll see more advanced type features added to languages. I find it very annoying when I can't be expressive enough and have to resort to comments and runtime errors. It's a very fine line to walk though. TypeScript is the language that I think is best at walking that line currently.

Re: Why is Rust difficult?

#207

Post by krylon »

josephg wrote: post #76
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…

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

> Pony is interesting but very new - there aren't a lot of libraries

The lack of libraries is what drove me away, too. The type system is gorgeous, though. I really hope Pony grows a decent library ecosystem soon, the language itself was very pleasant to use once I got past the initial learning curve.

Re: Why is Rust difficult?

#208

Post by shmerl »

jadbox wrote: post #31

I feel Go and Rust are great options for writing modern server side applications today, but they exist on two different ends of the spectrum. The Go language is highly minimal, constrained, and forces devopers to write unified code, that performs extremely fast idiomatically. This uniformity is helpful for open source collaboration. Rust is a much more robust language (eg generics), but is more complicated to pick up…

You contrast them only by complexity, but the actual reason for it goes further. Go achieves simplicity through a major trade off of using garbage collector. That's a price that you need to pay just for using Go. Rust on the other hand doesn't impose it, following the approach of letting you decide what you want to pay for. This results in higher complexity.

So it's good to remember that simplicity of Go doesn't come for free.

Re: Why is Rust difficult?

#209

Post by goldfire »

kqr wrote: post #128
jonathanstrange wrote: post #123

Earlier quoted context omitted.

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

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 the language. If anyone here has any other resources to recommend, I'd be happy to hear about them.

Re: Why is Rust difficult?

#210

Post by krylon »

unethical_ban wrote: post #175
josephg wrote: post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc. I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread…

> Why are generics such a critical component of a programming language that every thread about Go mentions it?

Personally, I do not feel that strongly about generics; it would be nice to have them, but for my purposes, I can live without them.

But still: generic container types would be very nice. I don't need to use it very often, but Go's sort.Sort is very uncomfortable to use. If Go had proper generics, it would be easier to define a "generic" interface to iterate over things - currently, Go's builtin slice and map types are privileged over user defined types. There are probably more issues I cannot think of right now.

None of those are deal breakers for me. Go is highly compatible with the way my mind works, to such a degree I can easily forgive it all the things I do not like about it. But I also work in C# from time to time, and seeing how the .Net framework uses generics makes me wish Go had them, too.

Post reply on HN