111–120 of 206 posts
Earlier quoted context omitted.
What is this STL you are referring to? It's not something familiar to me. Or do you mean the standard library (std)?
In C++, the "STL" is the "standard template library", which was a large inspiration for the standard library, but not actually the same project. Due to this history, some folks still call the standard library "the STL" even though it's not 100% accurate.
Earlier quoted context omitted.
As I understand it Rust is composed of 5 or 6 sub languages. I find it hard to believe that there's no way to get the benefits of Rust without 5 languages. Why can't a programming language be one language that does everything it needs to do? Seems crazy to me to have 5 or 6 sublanguages.
I think you might be referring to this: https://gist.github.com/brendanzab/d41c3ae485d66c07178749eae... In which there is: >Many sub-languages to learn, many with different syntaxes and semantics. For example: > the expression language > unsafe runtime language > safe runtime language > compile time language > the type language > the trait language > the macro language > the attribute language And was discussed (122…
My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…
Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0]. It turns out, they key is to move some checks to run-time [1] to reduce complexity, move other checks instead to compile-time [2] where it doesn't increase complexity, and then make the borrow checker "opt-in" instead of forcing it…
My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…
That's perfectly fine. However, without Rust, we cannot get there from here.
Say what you will, but Rust is the first language to crack the Linux kernel monolanguage (I don't see Ada in the Linux kernel, for example). That's a good thing as the tooling will then be in place so that RustEasier(tm) doesn't have to go through such a slog to get used in the kernel.
People forget that we went through a similar process with Linux on Alpha. The Alpha port cleaned up a lot of the x86-isms that allowed Linux to be ported to other architectures far more easily afterward.
My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…
This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…
I will say that the compiler got WAY better over the last couple of years.
The quality of the error messages went way up, and the number of times I had to do something stupid because the compiler couldn't infer something went way down.
To me, the compiler getting so much better was what finally got me over the hump.
Earlier quoted context omitted.
Unsafe Rust is a minimal superset of Safe Rust, proc macros aren't their own language, there's no such distinction between Rust and "the attribute language", and async Rust isn't its own distinct thing, it's all just Rust.
Unsafe Rust is, in the Rust Language book's own words, a "second hidden language" within Safe Rust[1]. You're absolutely right that it's a superset; that's what makes it distinct and therefore a unique language with unique semantics (even if the syntax is nearly identical). Procedural macros can be used to define new languages within Rust, which means that grokking them requires the developer to understand their expr…
Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. Which is to say, for any given expression that compiles with Safe Rust, if you wrap that expression in an unsafe block it will have precisely the same semantics. For the book to describe it as a "second, hidden language" is being a bit fanciful on its part; it later goes on to clarify that it just gives you a handful of extra powers.
> Procedural macros can be used to define new languages within Rust
Sure, but by that logic, Rust (and every other language that supports DSLs) has infinite languages inside of it, which does not amount to a particularly useful distinction; either a language supports crafting DSLs or it doesn't. To suggest that this means that the language itself has infinite sublanguages obscures its actual sublanguages, such as the built-in macro-rules DSL.
> Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust
This is a misunderstanding of the reference manual (which is itself non-normative and fairly ad-hoc in structure); most pages contain their own grammar specification, e.g. the syntax for items is described at https://doc.rust-lang.org/reference/items.html , but there is no user-facing item sublanguage in the same way that there is no user-facing attribute sublanguage. Attributes are attributes, they're just a part of Rust.
Rust is so simple and elegant.
Was it simple and elegant from the beginning, or did it click at some point? I started learning it from the O'Reily book yesterday, and so far it's easily the steepest learning curve for a language.
Earlier quoted context omitted.
This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…
> Rust isn't really all that hard. You don't find it hard. Many do.
The question at the end of the day is whether that "hardness" is required or accidental. My gut feel is that Rust does have some accidental complexity--poor support for static/globals, poor support for placement new and alternate allocators, inability to transmute equivalent types well, etc.
However, my gut feel is also that a lot of Rust's "difficulty" is the fact that people really don't know how to program C/C++ even remotely correctly, and Rust is simply slapping them in the face with that fact.
Earlier quoted context omitted.
This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…
In my experience learning Rust (and in watching others learn Rust) that first "aha!" moment is actually rather misleading. That moment comes when one learns how to technically accomplish any task in Rust. One knows the minimum set of tools needed to refactor enough to work around the borrow checker's limitations. Learning what the borrow checker prefers becomes second nature and, as you say, becomes natural. However,…
You don't need to feel bad about "working outside" the borrow checker, and maybe that's a signal that needs boosting. I've been using Rust for ages and I'm not averse to cloning things when I need to. It's cool that you can create zero-allocation libraries by threading lifetimes everywhere, and I certainly appreciate all the library authors who go the extra mile by doing so internally to their libraries, but in my application code it's easy to tell that a given thing isn't going to be a bottleneck and isn't going to be negatively impacted by a little copying and allocating.
Earlier quoted context omitted.
> Rust isn't really all that hard. You don't find it hard. Many do.
> You don't find it hard. Many do. The question at the end of the day is whether that "hardness" is required or accidental. My gut feel is that Rust does have some accidental complexity--poor support for static/globals, poor support for placement new and alternate allocators, inability to transmute equivalent types well, etc. However, my gut feel is also that a lot of Rust's "difficulty" is the fact that people reall…
I'll agree with your other things, but discouraging global state is an aspect that reduces ultimate complexity, rather than increasing it. :P