I think when Fish shell announced the Rust rewrite, they especially highlit that, in the form of "being more attractive to contributors" as one of the reasons.

> I'm not 100% clear on what you mean here

The core of their complaint is that if you use `jj edit` it's not obvious how to get a diff of what you did. The answer, of course, is that you can use `jj evolog -p`.

Ah, yes that reading of the “work is invisible” is likely.

I think a part of the point is to question the need for things like that. Do your users actually need all of these bells and whistles?

Nothing changed, you need to know that host:port first, and that's where the problems with the official serverlist being flooded with fake entries become apparent.

That really is not a solution.

Third party servers used to host plenty of non-standard gamemodes that Valve does not provide. Retakes, mentioned in the blogpost, is one of those modes.

of course! But there isn't much else to do so I'm just giving a solution that works for me

Could it be that it gets no credit for things it got right because it got barely anything right?

I think you make a pretty bad case for how embedding a Scheme interpreter is going to help with the pain points of async. Listing "stack traces full of tokio code" and then seemingly proposing to solve that by adding more glue to pollute the stack traces is especially weird.

Not an interpreter! A compiler :-)

Have you seen a stack trace originating from somewhere within tokio? Nearly all useful information is lost. My contention is that by isolating the functions that are required to be written in Rust and then doing orchestration, spawning, etc in Scheme the additional debug information at runtime will make the source of errors much more clear.

I could be wrong! But hey there’s other reasons too. Being able to debug Rust functions dynamically is pretty cool, as well as being able to start/stop them like daemons.

On the other hand, you might wind up with an impressive Scheme implementation.

luajit gets you almost all of scheme features except macros. Speed of luajit is very close to native C.

Sounds like Greenspun's tenth rule.

Well, unlike Lisp & Scheme, Lua and Luajit are used in production, millions of video game consoles, embedded systems, etc.

Isn't this very website written is some sort of lispy goodness?

It seems like the intended application is live debugging. Lisp and Smalltalk have a rather nice history here. C, C++ boost and Rust tend more to be lands of contrasts.

Chris Kohlhepp has a great write up of embedding ECL in C++. The trick is to know about the C++ configure flag for building ECL. [0 with terminal screenshots, 1 on web archive without terminal screenshots]

Haskell people seem to like Lua. Just look at pandoc.

[0] https://isocpp.org/blog/2014/09/embedding-lisp

[1] https://web.archive.org/web/20200307212433/https://chriskohl...

I thought the same thing. It's a hard pivot from "async rust is hard" to "but if we add in Scheme it will be good!" With no real justification for it. I'm not a Scheme guy but I don't see the connection.

Coming right after profiles are done, probably?

I understood your joke, but we just found out a few hours ago what happened in Hamburg, and while neither of these features made it yet, they're seemingly going in opposite directions:

pattern matching had a poll in forwarding to the CWG, and it was mostly in favor, though enough were against it to not reach consensus

profiles had a poll in forwarding to the CWG, and it was split down the line in terms of for/against.

Given the previous votes on profiles being nearly unanimously for, I'm interested to see what people have to say about what went on.

One has nothing to with the other.

That is the thing with committee driven languages, with multiple vendor implementations.

Not everyone is on the same room voting for the same features, and not everyone is implementing the features in any specific order.

By the way, I would rather have Safe C++ than profiles, but do not vote, so whatever.

I'm not saying they are related, just saying that the committee committeing is going to take half a decade at least for both.

Yes.