331–340 of 523 posts
Earlier quoted context omitted.
Lifetimes only work because they are very restrictive - the moment you can’t decide that you end up with a non-safe language.
Soundness, Completeness, Saftey -- I care about these far less than Safe, Sound, Complete 99.999% of the time; a joy to use 100% of the time
Earlier quoted context omitted.
Rust does make compromises of performance. That is not always bad so long as the compromises are minor. Fortunately Rust can do most of the checking at compile time, but it if you read from an empty vector Rust doesn't have undefined behavior and that means there is a runtime check of some sort in at least some cases. The trick is to find the right place to compromise so the cost is minimal overall even if it isn't z…
The thing is, although the check looks like work, a correct C++ solution almost always needs to do the same work. There are real world cases where it doesn't, but lots more where in C++ we need to explicitly do the work or our program malfunctions, sometimes in subtle ways - while in Rust we get this right by default.
I do agree though, the cost of the check is so small that it doesn't matter in most cases.
> Library-defined containers, iteration and smart pointers. Containers, iteration and indirect-access operations (along with arithmetic) comprise the inner loops of most programs and so optimizing their performance is fairly paramount; if you make them all do slow dispatch through user code the language will never go fast. If user code is involved at all, then, it has to be inlined aggressively. The other option, whi…
Personally I'm happy Rust took the C++ route, it makes things more interesting, but I can see his point.
Over the evolution of Rust, I've been increasingly despairing about many of the things Graydon here dislikes. I assumed the present "syntactical insanity" was, somehow, intended; it seems, really, it wasn't. I find Rust basically unusable -- at the level of abstraction I want to write code, basic definitions break line limits. Rust seems to be a repetition of C++'s mistake: a language which conspires you to pretend i…
Rust is a low-level programming language meant to control everything about the code’s execution. It will by almost definition, be complex. You seem to want contradictory things — if you don’t need that level of control just use any of the litany of high level languages with nice syntaxes. I don’t think we can eat this cake anytime.
The fact that it is a law-level language best fit for system programing came much later. Late enough that there are people here and there still trying to use it for the original use-cases.
Earlier quoted context omitted.
> This "two syntaxes, one for the runtime and one for the compiler" approach -- has swamped Rust as it aims for greater expressiveness. Not least, because it has a third syntax: one for unsafe. What are you referencing, concretely? For example, "unsafe" doesn't add or remove syntax.
Split the syntax into whether it 1) emits no code (compiler-facing); 2) emits weakly-related code (eg., macros, etc.); 3) emits code close to what's written abstractly (eg., value operations); 4) emits code close to what the machine needs (eg., unsafe code) -- etc. And you'll find about "4 languages" all mixed together.
Most "syntax" in AOT, statically typed languages does not directly generate machine code, but it does directly impact what machine code is generated. So there's not a clear distinction in practice.
For example, a lot of the syntax is used to control method selection and verification - that's not a "different" syntax or language by most folks' definitions.
Earlier quoted context omitted.
Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…
You can't evaluate a future in normal rust as there's no default executor, you need to pull in some library to even make blocking calls to async functions. IMO, this is even worse than function coloring.
Earlier quoted context omitted.
Blocking in Loom is primarily about waiting for network traffic, possibly with extensions to file IO in future - it doesn't suspend if you do file IO today. Loom does get rid of coloring, or rather, doesn't introduce more of it and lets you phase out what exists, so I'm not sure what exactly you mean by that. Kotlin suspend funs do not tell you they're about to touch network disk, that's the reason they use "suspend"…
> possibly with extensions to file IO in future - it doesn't suspend if you do file IO today Wasn’t basically all of the JDK’s file APIs rewritten to io_uring-like calls to support Loom? I have thought that IO was definitely something that Loom handled.
Earlier quoted context omitted.
Soundness, Completeness, Saftey -- I care about these far less than Safe, Sound, Complete 99.999% of the time; a joy to use 100% of the time
Then you are not the target audience of a low-level language that supposed to run without a runtime, but still safely. Don’t try to change the tool, when you could just choose a more fitting one.
Earlier quoted context omitted.
> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.
I'm interested in more on this. What can I do in C++ that I can't do in Rust?
Earlier quoted context omitted.
With a dodgy 2->3 migration pathway and far too many package managers.
And despite that, still a top 3 most popular programming language on the planet. And another in that top 3 is the universally-derided Javascript. There's a lesson in there to learn. Its unfortunate that the people who need to learn it most likely won't.
(That said, JS is actually a very versatile and almost-great language, getting better all the time)