81–90 of 523 posts
I’m very glad expressivity won out. I would like our profession to stop accepting tools that waste effort. I’ve always seen safety and lifetimes and borrowing as the main value prop, so I was surprised to see he was sort of aiming at an ML without GC, rather than a C++ that doesn’t blow up.
> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and…
This is an interesting read, because I read it as "I would have done all these things which would have kept the language more pure to my vision but less accessible". I also found this bit interesting: "It's easier to work with than C++, but that's fairly faint praise". I see this kind of thing in my own personal projects all the time. I'm thinking "oh it would be really cool if I built X" when in reality most of the…
I'm not sure it would be less accessible. I think the trade-offs would lean towards simplicity, and perhaps less familiarity. But with the right mental models, I think this could enhance accessibility (less "magic", or strange edge-cases). For example, see the discussion on not minding if users have to write something in a more verbose way if it preserves the language's principles. This type of trade-off is something…
Isn't that a matter of self selection? A language which developed around those priorities would have a community sharing those priorities now.
The point is if that community would be as large as the current one, larger, smaller.
Earlier quoted context omitted.
> it may become less attractive for other use cases. For instance, I find it highly questionable to develop a web app in Rust... I mean who'd want to and why bother trying to support that use case? Basically none of Rust's value proposition exists for a web app while nearly every single one of the downsides do.
Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great . Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather tha…
Earlier quoted context omitted.
Not knowing about function coloring is a stupid dream and has terrible implications on the performance of your code, which is infinitely more important than you losing 2 minutes having to figure out that you really want to `runBlocking { callThatBlocksForADamnLongTime() }`. The insight that function coloring gives you is terribly important. Roman Elizarov (of Jetbrains, author of Kotlin and lead on Kotlin Coroutines)…
Async doesn't solve that problem. What you're asking for is some sort of expression in the type system of expected performance, but there's no tech that can do this. Consider that modern NVMe SSDs can do disk reads faster than many calculations over the content of what was just read. A function that changes its algorithm to have worse time complexity won't be marked as async but could break your app, adding a single…
Blocking has meaning in a lot more contexts, and being a consultant on JVM related topics, you should know that: it's the entire purpose of Project Loom, and Loom doesn't entirely get rid of colour coding either explicitly for that purpose. Loom wasn't made because the guys at Oracle have a deep love for JavaFX, but rather takes into account the server world, where you really want to know that you're going into another context, another computer, etc. The only time where the existence of async doesn't make sense is if your entire language and ecosystem expects everything to already be distributed. In which case, you've just switched the default color to async.
Finally, you chose to read async as the current JS/C# abomination implementation, but most of the sensible languages have implemented it as an effect: Kotlin has suspend funs, they don't return a Promise, but they tell you two things: they're going to touch something like the disk or the network, and if you really want to have them in a non-suspend context, you can either get a Deferred out of them (and find another thread to run it on, and handle synchronization yourself), or run them on the current thread (and block everything).
Earlier quoted context omitted.
Importing a trait into scope can silently materialize methods on other types, with no syntax at the method call site pointing to which import statement created the methods, requiring you to ask the compiler/IDE. This can also mean that removing a use statement with no references to the type being used in the entire rest of the source file, can make code suddenly stop compiling. I've worked around this by strictly con…
There's worse. When your trait adds function foo and your code does obj.foo(), if the underlying type later adds a foo method, compilation breaks. This is very common with traits that usefully add useful methods that are missing in libstd... which break when said method is finally added there.
(some_integer).div_ceil(&2)
^^^^^^^^
= warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue #48919
= help: call with fully qualified syntax `num::Integer::div_ceil(...)` to keep using the current method
= note: `#[warn(unstable_name_collisions)]` on by default
The article starts with "In a recent podcast about Rust leadership, the BDFL question came up again" What it BDFL?
> The priorities I had while working on the language are broadly not the revealed priorities of the community that's developed around the language in the years since Isn't that a matter of self selection? A language which developed around those priorities would have a community sharing those priorities now. The point is if that community would be as large as the current one, larger, smaller.
Interestingly like Graydon suggests this and 'tis something D has, you can only have `ref` for function parameters. This is something the users sometimes complain about, but I guess it has positives.