Continuing the discussion from Rust beginner notes & questions :
Quotes from the linked posts are given below.
Imagine for a second that you’re a beginner and trying to compare an OsString to a static constant &str . Your code has a 50:50 chance of compiling depending on which order you use your variables, which would lead you to incorrectly assume that this feature is unavailable in the standard library about half the time.
Rust, unfortunately it seems, is now stuck with the “difficult” moniker that plagues Haskell; a sad psychology that creates learning anxiety in people before they even start. Studies on math anxiety have shown this is a real and lasting effect, causing measurable stress. Props to the rust community for taking “usability” head on.
Ironically, I had the opposite experience when I did something similar a couple of years ago. What I looked up was the implementation for Box, expecting to see something quite simple and similar to C++ auto_ptr or unique_ptr. Perhaps if I looked again now that I have more experience, I would feel differently but at the time I felt that a significant amount of magic was being performed for what in C++ was quite straightforward.
Incidentally, the last time this came up on internals , we failed to come up with any use cases where a “partial borrows” feature in the core language would’ve actually helped. Specifically, it seemed like all the use cases could be worked around with some refactoring, and any core language change that did not require such refactoring would amount to turning a borrow check error into a silent API compatibility hazard, which seemed like a net loss.
So if anybody does know of a compelling use case where that argument doesn’t hold, please necro that thread!
Relevant links to the previous discussion:
As for issue #2, it’s definitely part of learning Rust. The heavy use of type inference in most Rust code makes things quite confusing for a beginner because things look a bit magical (as you hint at) until you learn what is actually going on. For iterators specifically, you can use the cloned() combinator to return values and not references (so long as the type implements Clone. To make functions abstract over owned or borrowed values, you can make use of AsRef or Borrow traits.
There are s…
The last paragraph "Imagine for a second that you’re a beginner and trying to compare an OsString to a static constant &str. " is relevant in the post below.
I see people reimplementing identically named but incompatible traits as a failure: dual_num::Zero - Rust
I know that sounds harsh and nit-picky, but I feel that it's a sign of things to come. This kind of thing will inevitably get worse as a consequence of stripping low-level abstractions out of std. The missing wheels will be reinvented, and it's going to be a huge, incompatible mess.
(To clarify: I'm not generally advocating for std to include all-encompassing implementations for things, b…
I applaud the poster and responders here. I see this as healthy critical discussion. I don't interpret Peter bertoks comments as "pissed"; I see it more as intense, which I think is good that a program language should evoke intense feelings.
As someone who took to rust a few years ago, lost traction, and am now coming back to evaluate I very much appreciate discussions like these. When I evaluate a tech for adoption, which has impacts on the success of my business and my livelihood, I want to k…
I'm not sure if this counts as a "pragmatic" program, but one of the things that won me over to total Rust fanboy status was when, only a few weeks after reading The Book for the first time, I looked at the implementation of std::arc::Arc... and I could understand it. Easily.
This is in contrast to my complete inability to read just about anything in a typical C++ std implementation, despite multiple years of experience being paid to write C++ code and reading plenty of books on C++ obscuritie…
I stepped into Rust by starting to rewrite a command line app which I had written previously in Perl.
Although the Rust learning cure is pretty steep (but manageable for my background) I'm very pleased with
the expressibility the language offers (comparing here to e.g. Go is an insult to Rust)
the speed programs run (especialy in comparison to many other languages)
the Rust Programming Language Forum here which is extremely helpful (quick and high quality answers)
the documentation which is v…
haha, totally agree.
to me, this is what peter_bertok is trying get at, and that in his view rust is already starting to slip into some bad habits that led to complicated c++, the latter of which has had many years to accumulate such cruft. Perhaps that just the nature of an aging programming language that has to evolve with other advances (we don't really know since this is all pretty new to us as humans, maybe it'll be normal in a few hundred years that programming languages just need to die…
A more accurate moniker is "difficult for beginners". Once you know the language, you are as fluid in it as any other (even more so in comparison with some like C++ where you have to stop and look over your shoulder every now and then).
Note that I consider this a far lower "cognitive tax" than having to run the borrow checker entirely in my own brain like I do in C++. As a result I'll at least try borrowing things (and .clone() if it gets awkward) in Rust where in C++ I'd just copy-construct from the get-go since it's so hard to be sure I didn't break something.
It's certainly true that designing in a way that best leverages the checks is something that needs to be learned, and that some things (certain kinds of graphs seem…
Some things can't be changed now, so there's no point in distressing about them. Some other things can be fixed or added with a deprecation. So my suggestion is to write down a very long list of the things you don't like, remove the ones you believe are impossible changes, and open a separate RFC for each of them for the Rust 2018 edition (or where possible even for Rust 2015). And then be humble when people tell you some practical problems. Most ideas will be closed or shot down, but if even v…
Rust has many warts. Its feature-set does appear less cohesive and consistent when compared to some languages (C# comes to mind). There are countless other problems mainly due to its youth. Then there's the borrow checker. So feeling negative emotions is almost a rite of passage for a Rust beginner. I don't want to belittle your feelings, but in my experience once you get past this initial despair and when you get to coding for production instead of doing toy programs is when you come to appreci…
C# uses a GC though (already mentioned)
C# is a very high bar, it's one of the best designed languages out there (still, I think Rust is better for my usages).
I love Rust - let me preface with that.
Unfortunately, I think the tears at the seams (i.e. seeming incohesion/inconsistency) are visible at both the early/beginner stage and also at a later stage, although they're for different reasons. I am very hopeful that, over time, they'll be ironed out to a point where they're barely noticeable.
That said, no language is perfect. Rust is doing something novel, certainly so for any language that can be called mainstream. I think it's understandable t…
Here thread generates Rust compared to C#
Yup. The rough edges don't really go away with experience. However, you kinda learn to live with them since you get so much in return.
It's definitely not all, but it's very close to it I think. Particularly if you generalize "memory management" to soundness. A lot of the difficulty is being a low level language trying to marry high level features while being sound at compile time. That's a very hefty (and praiseworthy!) goal.
Ironically, I had the opposite experience when I did something similar a couple of years ago. What I looked up was the implementation for Box, expecting to see something quite simple and similar to C++ auto_ptr or unique_ptr. Perhaps if I looked again now that I have more experience, I would feel differently but at the time I felt that a significant amount of magic was being performed for what in C++ was quite straightforward.
I suspect much of that magic is linked to support for Box<Trait>.
Incidentally, the last time this came up on internals , we failed to come up with any use cases where a "partial borrows" feature in the core language would've actually helped. Specifically, it seemed like all the use cases could be worked around with some refactoring, and any core language change that did not require such refactoring would amount to turning a borrow check error into a silent API compatibility hazard, which seemed like a net loss.
So if anybody does know of a compelling use cas…
Here thread generates Subsubtopic: Box<Trait>
Slight tangent but the sdl2 case linked in that discussion is very compelling. The issue of abstraction via methods vs running into borrowck issues comes up on this forum often as well. I think it’s easier to work around it in private APIs or code but it makes it harder to design APIs that you can’t change willy-nilly after release. This added design axis is definitely a challenge IMO.
The sdl blog I linked above has a compelling, IMO, case. They were also able to work around it with refactoring. And I agree that with sufficient thought and ability to move code around it’s probably doable. But this requires a lot of foresight to get right in a public API, where you can’t easily make breaking changes. This virtually guarantees breaking change churn or users needing workarounds, likely at a performance cost.
The fact you can do disjoint borrows of fields is virtually essen…
I think what might help here (as others have said) is some concrete code demonstrating what you want. I know I'm confused. It seems you have pointed out examples of what Rust should be doing, like C# Pipes, then only to back-track and say that no, that isn't what you thought it was. I think everyone (I know I am) confused by the insistence that it must be in core or std instead of on crates.io . I think the idea of a "Fat Standard Library" is wrong for a number of reasons (especially at this stag…
Thread generates thread:
A user has struggled to use certain aspects of rust, some of it is related to tooling (productivity), others are related to the implementation of the Rust language. Figure out which points have merit, then Feel free to create a new linked topic as you read through this aggregated feed.