j-james

I think this is all true. Though with regard to your earlier example, it should be noted that Nim, too, has an extraordinarily powerful compile-time programming system: but it takes the form of typed macros and generics (as opposed to Zig's dislike for such abstractions).

It will not emit warnings saying it did that. The static analysis is not very transparent. (If you can get the right incantation of flags working to do so and it works, let me know! The last time I did that it was quite bugged.)

Writing an equivalent program is a bit weird because: 1) Nim does not distinguish between owned and borrowed types in the parameters (except wrt. lent which is bugged and only for optimizations), 2) Nim copies all structures smaller than $THRESHOLD regardless (the threshold is only slightly larger than a pointer but definitely includes all integer types - it's somewhere in the manual) and 3) similarly, not having a way to explicitly return borrows cuts out much of the complexity of lifetimes regardless, since it'll just fall back on reference counting. The TL;DR here though is no, unless I'm mistaken, Nim will fall back on reference counting here (were points 1 and 2 changed).

For clarity as to Nim's memory model: it can be thought of as ownership-optimized reference counting. It's basically the same model as Koka (a research language from Microsoft). If you want to learn more about it, because it is very neat and an exceptionally good tradeoff between performance/ease of use/determinism IMO, I would suggest reading the papers on Perseus as the Nim implementation is not very well-documented. (IIRC the main difference between Koka and Nim's implementation is that Nim frees at the end of scope while Koka frees at the point of last use.)

That relies upon the benevolence of corporations to much more of an extent than I am comfortable with. 20 years of social media has convinced me that that's a bad idea. And, I think, it removes much of the benefits of federation: if the only way to sustainably moderate is to rely upon gifts from BlueSky Inc., moderation is going to be necessarily dependent upon them.

I cannot see how BlueSky's moderation system can ever work. Decoupling moderation and hosting means there's no onus to do the moderation that they describe: which makes me think it will be BlueSky Inc., and only other corporations, that have resources to throw employees at a now thankless, Facebook-style moderation job. And instances have to moderate anyway, in order to not host illegal content.

Ah, I was referring to disruptek. I don't know why you two hated each other's guts, mostly due to being less active back then indeed. For what it's worth I didn't think the banning was undeserved: but the interactions you two had always struck me as strangely animus, and not anything like anything I've ever seen between him and anybody else, and certainly not between any other nimskull developers and anyone, ever.

It is perhaps notable that the nimskull project has a Code of Conduct (and a rather good one at that). I think it is indicative of serious intention to make a welcoming community, and I don't think that contributing members having had in the past what really struck me as personal grievances turning into open-air malice undermines that: particularly, such behavior would fall under the Code of Conduct itself. But again, I have not seen such behavior - quite the opposite! - outside of what happened between you two.

Some context: dom96 here was the BDFL-in-2nd-command of Nim for quite some time. There is personal beef between dom96 and some of the primary nimskull contributors, which mostly involved a lot of name-calling, personal insults, and critiques of leadership and leadership effectiveness, that eventually lead to dom96 banning one of the aforementioned contributors, stalling quite a lot of interesting compiler work and partially sparking nimskull. It's all quite boring stuff.

dom96 eventually had a falling out with the Nim BDFL too (which I'm surprised did not happen earlier: the BDFL is... brusque, charitably) and so has been inactive in either Nim community because, well, obviously. But: in all my years involved with Nim, I have seen the nimskull developers to be pretty consistently great to work with? I think they handle things professionally, are not rude, and treat other's work with care (you will maybe notice they have a code of conduct exposing an explicit intent to do so). Which makes what happened between them and dom96 all the stranger in my eyes, but I was less active back then, and there is certainly context I am missing.

tl;dr meh

Well, they're not classes, they're interfaces, and so you can implement multiple interfaces for multiple types, and so you have to implement them separately from the type declaration. There's not too much of a way around that, I think.

I'd be a little interested to hear what you like about C++'s syntax! As a non-C++ programmer, I mostly think of the language as a pile of mistakes that kinda had to happen for other languages to learn from them, very much including syntax (ex. types preceding declarations, necessitating `auto` and complicating parsing) - and I actually think the ugliest parts of Rust copy those mistakes (ex. using <> for generics, which are ambiguous with less-than greater-than when used with no whitespace, necessitating the turbofish).

(I've heard plenty of complains about Rust syntax, so I'm less so interested in that than what C++ syntax gets right. Unless it's just a familiarity thing...)

Nim is particularly C-like. The automatic memory management is optional and exposes destructors, it exposes pointers and is quite usable on embedded systems (see: Futhark, Ratel), there are a wide variety of design decisions made to ease interop with C... I do not know about D.

Koka is garbage collected. There are several terminology ambiguities in play: the documentation takes "garbage collection" to refer to tracing garbage collection as opposed to runtime cost of any sort, which while common in some circles seems less so common as a whole (this is extremely confusing, all the time). This runtime overhead is reference counting and so is going to be a whole lot nicer to deal with (especially re: C FFI) than tracing, but it does exist.

The reason Koka's GC is interesting despite being based on reference counting is that its ownership system eliminates most of these reference checks at compile time - and additionally can tell whether to use atomic RC (slow but threadsafe for shared data) or non-atomic RC (fast but only threadsafe when data is moved across threads, not shared). This ownership analysis is very similar to what some other languages like Nim do (except Nim differs in not allowing atomic RC at all).

The other strange terminology that is occasionally tossed around in Koka documentation is "garbage free": Koka takes this to mean that at any given point in the program, there is no memory waiting to be freed. This is because the ownership analysis lets the compiler know exactly where the last use (or possible last use) is and insert destructors accordingly. All of that has made Koka's GC algorithm fast and low-overhead enough that it's competitive with state-of-the-art tracing GCs (specifically, OCaml's GC). I haven't seen benchmarks comparing it to manual memory management or strict ownership systems but that's not terribly the point - manual memory management is unsafe and strict ownership is complicated + inexpressive on occasion. Koka's system might just be the best you can get, with those tradeoffs in mind.

Anyway, this doesn't answer your question at all. Sorry. I hope it's interesting, though.

The downsides of this approach are unfortunately that it makes wrapping certain low-level libraries an absolute pain in the ass (especially anything to do with keyboards). But overall it's a non-issue, tooling recognizes both styles and you don't notice it.