And they want your phone number :)
471 karma · joined April 9, 2009
Do you have examples for that?
Edit: I'm not doubting you, but having precedent of things that were rejected due to breakage it causes might be helpful in some current/future discussions :)
> Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change.
My fear is that this is currently changing. There are a couple of threads on the internals forum currently collecting ideas of what people want changed in future epochs. To me, that's a shift to a different mode of operation. From "editions allow breakage as last resort" to "editions make breakage no longer a big issue".
> It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway)
Here is one mention of it: https://github.com/rust-lang/rfcs/pull/2005#issuecomment-305...
The idea also seemed like a big hit in #rust-lang at the time. People were quite gleeful that `ref` could go away at some point.
I'm happy it's no longer on the table, but having to fight for the ability to destructure into mutable and immutable felt wrong.
Same thing with the modules redesign. Having to fight that hard for your existing workflows and use-cases not to be broken through multiple RFCs felt wrong as well.
Having some constructs auto-convert their final result value seems certain at this point.
> but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
I've been following Rust since 0.10 or so, so I've been there quite a while as well. I was there for the uint wars, the battle of match ergonomics, and of course the big module rework skirmish.
I'm sure nobody is acting out of malice, my fears are more that with a certain community size, it is easy to be drowned out if you have different needs or opinions.
An example would be the talk about removing the ability to declare reference bindings with `ref` and `ref mut` and always inherit whatever the source mode was.
Edit: There is also talk about changing the prelude, so I would assume the standard library is also fair game.
The interesting (and to me frustrating) part is that often good improvements (or intentions to solve actual problems) come together with far-reaching changes in an all-or-nothing kind of way. Some examples:
* I'm still of the opinion that moving `&mut T` to `&uniq T` pre-1.0 failed because it also proposed getting rid of `mut` alltogether and be mutable by default.
* Everything that relates to errors often also tends to accumulate a push to make things look more like exceptions. That applies to `?` short-ciruiting, the current discussion about limiting the scope of that short-circuiting, and anytime auto-converting final-value result types comes up. (and it currently looks like that short-circuit construct will auto convert its final value when it arrives).
* Making paths saner and modules and visibility more intuitive first started out proposing completely removing the option of being explicit about project structure, and it took multiple rounds of RFCs to keep that control.
* The match ergonomics discussions hinted at a wish by some to get rid of `ref` and `ref mut` patterns which is what allows destructuring a mutable reference into mutable and immutable bindings.
* `?` can propagate values/short circuit control flow, but it also contains a hidden type conversion. The target needs to be a known type for it to compile.
* A proposed `catch` construct will include implicit type conversion for its result value.
Some things that came up in the past but met resistance:
* Removing project structure from in-code to being defined by the filesystem.
* Hiding `Result` types in signatures with special syntax.
* Dropping immutable by default, though this was pre-1.0.
Also, `Rc` and `Arc` are good examples for this. They do seem trivial, but having them auto-clone would mean:
* Every newcomer who writes `fn foo(val: Arc<Bar>) {}` instead of `fn foo(val: &Arc<Bar>) {}` or `fn foo(val: &Bar) {}` will get an implicit atomic increment/decrement at every function call.
* It also makes it a lot harder to reason about code if you want to use a clone-on-mutation-unless-not-shared strategy.
Yes, in the end the changes don't sacrifice long-term maintainability over learnability/marketing, but that was a hard fight. And given editions will allow radical changes to the language and ecosystem every 3 years, I'm not sure how long that resistance is sustainable.
These addons (tree style tabs, tab open/close control) already have webextension versions, but are extremely buggy for me, and I believe that is unfixable because the asynchronous nature of webextensions is fundamentally incompatible with changing browser behavior on that level.
It's now up to a point where I dread opening a new page, and it takes a couple of tries before a tab is in the right position in the tree, if it works at all. Sometimes they just land wherever, not even forming a correct tree anymore, old tabs reappear, and on an extension restart the whole tree is jumbled up.
So, to me, the whole Quantum era has been kind of a big disappointment.
let (a, b) = c[..16..];What about "X encoding thread-safety through the type-system is an improvement over the C++ way" and similar? This is how I usually read these kinds of statements.
Why would I need a good understanding of C++ to consider these built-in facilities or the ones that just happen due to the type system as safer?
Inspired by an Outer Limits episode.
Personally, I interpret the focus on memory safety as a response to "memory issues aren't a big deal" or "memory issues only come from incompetence" viewpoints.
This does seem to come up sometimes. I'm wondering if it makes sense to add a "end-vision for GC-less D" section to the D GC documentation, now that there are various undertakings to make it easier. Might also help with finding volunteers that care about @nogc to help out with various bits.
Again from an outside perspective, it also seems that these camps talk about their viewpoints to outsiders more than to each other.
Personally, I always thought the reality is probably closer to "Not adding generics prematurely is a design feature, and it hasn't moved forward yet since the core team doesn't need it enough, and no proposal developed critical mass of community support to consider it appropriately vetted."
Preface: I don't use D, but I've lurked on the forums for a while now since I've started looking for a low-level programming language.
I would agree that this (manpower and delegation) is the main issue D is facing, and many others flow from it. Walter and Andrei are spread way too thin, while still being the main conduits and gatekeepers for all things D.
For example, sometimes their responses can seem curt or dismissive, but I've come to the conclusion that they're just busy people, and for many back-and-forth communications short responses are fine if not better.
My personal opinion is that what D really needs is more bureaucracy. Pre-defined processes where even casual contributors and other interested parties can follow along. I believe the "study" subforum was a good start, but is a bit too ad-hoc (and underused). The issue discussed in the original (stdlib coupling, integration of D built libraries into other systems) would be perfect for a study group. Start out with a Goals/Requirements document, come out with strategies, hindrances. Even when no solution is found or no consensus is reached, the archived discussion would be valuable in itself, for example as basis for a "Reasoning and Alternatives" document for the specific issue or mentioned use-cases.
A more complex situation would be the optional GC. It is very much wanted, and lots of work is going into that (all the RC integration/experimentation, the scope annotation system, to just name the ones visible to a lurker like me). But I couldn't tell you the full plan, I'm unsure where D wants to end up (from a current standpoint) with regard to being usable without GC.
From my point of view, there are still issues to be sorted out with closures, exceptions, arrays and slices, plus I'm unsure about how GC, RC and manual memory management are supposed to interact in the end. Now, from examples on the forums I can tell that using D without GC is doable and useful, so I would assume once you start doing it you find a way. But this is all harder to see from the outside.
Which brings me to another point: Publicity. D could do with a lot more blog posts showcasing its more unique parts like great use-cases for the compile-time power D has: The memory management strategies, how to effectively use the safety system, how to do D concurrency and parellelism "right".
I apologize this got a bit longer, I guess I waited for a cue to give some feedback on D, since I never felt like it was my place as a biased outsider to weigh in on their forums.
In effect, I believe manpower is one of the biggest issues to get where they want to go. What I find interesting is that in my view it is non-development manpower that they actually need. Or rather, more efficient ways to attract it, or maybe even just more efficient ways to include the ones already there.
The drawing abstraction is actually my current big hurdle, and I hadn't thought of looking at how CSS is rendered yet. So, thanks for that hint!