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

251–260 of 260 posts

Re: Why is Rust difficult?

#251

Post by bonesss »

Rapzid wrote: post #234
carlmr wrote: post #186

Earlier quoted context omitted.

I agree. I just wish more other people knew F# so I could use it for more projects. I've also almost stopped using Python for my scripting purposes. F# is just so much more elegant, and if the scope of the script grows, I can grow it to a proper project. The only reason why I still use Python every once in a while is pandas. If I have to analyze some big tables, it's still far ahead of anything in any other language…

F# is my language crush. Been following it and hoping to use it for a long time. I'm in a leadership position and could MAYBE push to standardize on it however the current more likely scenario is TypeScript(I know, I know) due to my having already successfully pushed that out haha. Unfortunately the ship is already a bit far from shore. Trying to move us completely away from Python for infra due to its tooling/langua…

Big bang transitions never work, IME, but step-by-step is viable :)

Maybe you've seen it before, but if you're looking for conservative ways to introduce F#: https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use...

Re: Why is Rust difficult?

#252

Post by smaddox »

marcosdumay wrote: post #158
singularity2001 wrote: post #81

(for newcomers) nothing works out of the box or as expected program[0]="+"; | ^^^^^^^^^^ the type `str` cannot be mutably indexed by `{integer}` error: use of unstable library feature 'collections': needs investigation to see if to_string() can match perf error: borrowed value does not live long enough reference must be valid for the block suffix following statement 0 When you use an index operator ([]) you get the a…

Ouch. I still couldn't wrap my mind to that string traversing gets intuitive in Rust. The entire iterator thing seems completely counter-intuitive.

Isn't it basically the same in Go?

Re: Why is Rust difficult?

#253

Post by steveklabnik »

frankzinger wrote: post #246
steveklabnik wrote: post #177

Earlier quoted context omitted.

Where are you seeing these kinds of comments? Can you link me to them? I’d like to tell them to cut it out.

It's calmed down the past year or so but before that it was so insane (especially here on HN) that the impression will be hard to erase for those who were around to see it.

I was around, but still didn't actually see it. I see people complaining about it more than I actually see the comments themselves. That's why I always ask for concrete examples, and people never actually show them to me.

Re: Why is Rust difficult?

#254

Post by smaddox »

onli wrote: post #32
ohazi wrote: post #10

Earlier quoted context omitted.

"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's really not hard to get code past the borrow checker anymore. Maybe every thousand lines or so you'll need to add a block or pull a temporary variable out of a one-liner, but the compiler basically tells you exactly what to do when something like that is releva…

Oh, I'd love if that were true. But in my limited experience with Rust it was still the borrow checker that absolutely made writing in the language hard. That was in 2017. My mental model of what should be safe was not at all the model the borrow checker had. And I really read the documentation about that part of the language. I guess a confirmation that there were problems there is that they tried to improve the bor…

Were you writing functions/procedures under the implicit assumption that they would be executed under a single threaded context? Because Rust does not allow this assumption without using "unsafe". I've run into this before, and it can be a bit irritating, but if there's even a small chance you'll later want to execute the code in a multithreaded context, it will more than pay for the inconvenience. And if you're sure you won't, then you can just throw the data into an UnsafeCell and call it a day.

Re: Why is Rust difficult?

#255

Post by steveklabnik »

smaddox wrote: post #254
onli wrote: post #32

Earlier quoted context omitted.

Oh, I'd love if that were true. But in my limited experience with Rust it was still the borrow checker that absolutely made writing in the language hard. That was in 2017. My mental model of what should be safe was not at all the model the borrow checker had. And I really read the documentation about that part of the language. I guess a confirmation that there were problems there is that they tried to improve the bor…

Were you writing functions/procedures under the implicit assumption that they would be executed under a single threaded context? Because Rust does not allow this assumption without using "unsafe". I've run into this before, and it can be a bit irritating, but if there's even a small chance you'll later want to execute the code in a multithreaded context, it will more than pay for the inconvenience. And if you're sure…

It's not even inherently about multi-threading https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

Re: Why is Rust difficult?

#256

Post by barrkel »

quodlibetor wrote: post #157
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…

The nice thing about Rust not having Async IO built into the language is that arbitrary third-party implementations are possible on a level playing field with the async framework being developed by the core team. For example, there is the May[1] concurrency library. It provides alternative implementations of the standard library's IO interface, but does Go's automatic suspend/resume, so it still looks like blocking c…

"Batteries included" is almost always better than "level playing field" because of network effects. The larger the set of common types / protocols available, the higher up the abstraction stack interfacing between two unrelated third party components can be. Minimalist environments have to pay taxes in the form of glue code and adapters for different ways of representing the same underlying concepts (though the costs are reduced in duck-typed languages). Even worse things happen when you try and use two third-party components and they share different versions of a common dependency - sometimes there's no easy way out.

Inferior approaches sometimes do get baked in to standard libraries. Having a culture of versioning, deprecating, migrating, is better IMO. But it's even better again to do a really good job first time around. Not easy, but I didn't say it was!

Re: Why is Rust difficult?

#257

Post by [deleted] »

pjmlp wrote: post #67
adwn wrote: post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

[deleted]

Re: Why is Rust difficult?

#258

Post by jwhite »

GolDDranks wrote: post #63
bluejekyll wrote: post #61

Earlier quoted context omitted.

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

I think they mean something like what proof assistants like Cog and Irdis do. ATS is another language that enables proofs, and it's more geared to the systems programming use case, as it's similar to C. Note that unit tests prove only that the code works for those inputs and those code paths tested. Mathematical proofs are supposed to be exhaustive.

Sorry this comment is so late; ATS is also interesting because it has linear types that allow compile-time resource tracking similar to Rust's ownership and lifetime tracking. If you use linear types you can opt out of the garbage collector. That makes it very attractive for systems programming, and in particular embedded systems. I believe there is a demo of ATS running on an Arduino of some sort.

I haven't had the time to learn it yet, though I would like to.

Re: Why is Rust difficult?

#259

Post by marcosdumay »

smaddox wrote: post #252
marcosdumay wrote: post #158

Earlier quoted context omitted.

Ouch. I still couldn't wrap my mind to that string traversing gets intuitive in Rust. The entire iterator thing seems completely counter-intuitive.

Isn't it basically the same in Go?

I don't know Go, so I can't really tell.

Re: Why is Rust difficult?

#260

Post by [deleted] »

AnimalMuppet wrote: post #223
pjmlp wrote: post #218

Earlier quoted context omitted.

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.

You're sounding like a propagandist - like you want to just argue your talking points, rather than actually have a conversation where you listen to what the other side is actually saying. It makes you a real pain to talk to. Just in case you're actually trying to engage in good faith, though, I'll try this one more time. If I have a compiler that is less-than-100% standards compliant, I may not be able to use a few f…

[deleted]
Post reply on HN