Readit NewsWait, how does that work? For example, take the following Rust function with insufficient lifetime specifiers:
pub fn lt(x: &i32, y: &i32) -> &i32 {
if x < y { x } else { y }
}
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.)
I am not sure if it will succeed or fail, but I am interested to see how it plays out.
You'll want to read:
* "Composable Moderation," this is the core conceptual idea: https://bsky.social/about/blog/4-13-2023-moderation
* "Moderation in a Public Commons," which describes specific features that were added in pursuit of the previously-described goal https://bsky.social/about/blog/6-23-2023-moderation-proposal...
* "Bluesky 2023 Moderation Report," which discusses specifically how (what is now) the main instance was moderated last year https://bsky.social/about/blog/01-16-2024-moderation-2023
[0] https://livebook.manning.com/book/nim-in-action/chapter-8/60
The C FFI Nim library lineage goes c2nim --> nimterop --> something i forgot --> futhark.
My many years of involvement with Nim is what I believe qualifies me to speak on the individuals in the forked project. That being said, I am no longer involved with Nim. I don't want to get reinvolved. I just want to warn people about individuals who were abusive to me (and others) for many years.
I banned very few people during my time in the Nim community, and never without good reason. I don't know who you could be referring to here. I'm sure you left this comment with the best of intentions, but you say it yourself, you were less active back then and have had minimal interactions with me on the subject.
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.
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
One thing I think Rust gets wrong is classes. I absolutely don't understand why you would require a separate `impl` block to provide methods. C++ has a reasonable syntax of providing methods in the class.
Deleted Comment
The difference here is that Nim compiles to C and you can turn the garbage collector off: Zig compiles C and there's no garbage collector. That means the entire standard library is available when generating object code. It's also trivial to opt-in to the C ABI on a fine-grained basis, by defining a function or struct with the extern keyword.
I believe this is still fairly current about the difficulties of building Nim dylibs for C programs: https://peterme.net/dynamic-libraries-in-nim.html
I expect Nim will stabilize about where D has: it will have a dialect of the language which, with relatively painless accommodations, is able to produce object code which speaks C ABI. Zig is different. The language is relentlessly focused on providing a better alternative to C while occupying the same niche, and a lot of design time has been spent on making it practical to take an existing C program and start writing the new parts of it in Zig.
It's a good language, Nim, and getting better. I'd recommend it for someone who is considering Go, for example.