frigid

You don't want nimterop, you want futhark (https://github.com/PMunch/futhark).

The C FFI Nim library lineage goes c2nim --> nimterop --> something i forgot --> futhark.

Well, it has a runtime. Checking and updating the reference count (more so the latter) is not zero-cost. This runtime is just deterministic. Of course, then do we have the same definition of runtime (I would take it to mean any extra memory or processor overhead at runtime that is not strictly necessary)... naming and consistent naming is an extremely hard problem in computer science.

It's in the same category as Swift, yes, but much improved: Swift does not do ownership analysis to get rid of counts (though I've heard they're looking at alternative region-based approaches), and their counts across threads are always atomic (and thus slow).

Reference counting has traditionally led to worse performance than tracing. So even though I get the desire to think of it as separate because it's just transparently replacing your allocator / deallocator with one that does a little bit more instead of having a whole separate tracing collector program, I'd still probably refer to both tracing and reference counting as "garbage collection", and then refer to them + ownership systems (+ regions + everything else new) as "memory management techniques".

The overlap in implementation techniques between tracing and reference counting is interesting. You might enjoy this paper: https://dl.acm.org/doi/10.1145/1028976.1028982

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.

(for inconsistent usage)

As background, style insensitivity was introduced so that codebases can use a consistent camelCase or snake_case regardless of the style used by upstream libraries.

It certainly adds (some, not many thanks to static analysis) runtime checks, but it's also fairly distinguished from typical tracing garbage collection by being deterministic. I believe ARC/ORC also works with a shared heap via "isolated" data.

It's a bunch of people who like working on the compiler, working on the compiler. Nim proper doesn't have as much flexibility to make breaking changes, and this has limited much-needed internal refactoring.

There was a falling out between some developers on the Discord that led to personal attacks and an eventual banning a while back. If I recall, nimskull started shortly after, and has attracted a few other compiler developers since.

One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic.

So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.

I particularly like, from the syntax side:

- Python-style syntax with significant indentation

- Uniform Function Call Syntax: a.len() == a.len == len(a)

- Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing

- All of the above makes code readable and succinct

And from a language features side:

- Compiles to C with all the architectural targets that come with it

- Compilation to C also allows for easy C interop: wrap function signatures and types and you're done

- This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top

- Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like

- Useful compile-time templates and macros that can directly change the AST

The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)

This is excellent. I think https://www.internetingishard.com/html-and-css/ complements it well as an introductory tutorial to HTML/CSS.

A lot of these can be easily done in Bash, too!

1. `mkcdir () { mkdir -- "$1" && cd -- "$1"; }`

2a. `bind '"\e[A":history-search-backward'; bind '"\e[B":history-search-forward'`

2b. Default behavior for Bash.

3. `shopt -s autocd`

4. `mmv`, `perl-rename`

5. `qalc` from libqalculate: https://github.com/Qalculate/libqalculate

8. Default behavior for Bash.

9. Default behavior for Bash.

Newgrounds has done a lot of work on preserving old Flash content. Some standouts are their own Flash player and an SWF to MP4 converter, but what I find most interesting is Ruffle.

Ruffle is a Flash emulator written in Rust that can be used as a browser extension, a desktop client, or a website polyfill. It's still a work in progress, but eventually websites with heavy use of Flash content (like many late-2000s webcomics, or even Newgrounds itself) could use the polyfill to replace Flash content with WASM blobs.

The roadmap was updated recently, and provides a good overview of Ruffle's current capabilities. There's also a demo instance that can run arbitary SWFs, with a few examples available.

https://www.newgrounds.com/flash/player

https://github.com/Herschel/Swivel

https://github.com/ruffle-rs/ruffle

Roadmap: https://github.com/ruffle-rs/ruffle/wiki/Roadmap

Demo: http://ruffle-rs.s3-website-us-west-1.amazonaws.com/builds/w...

> ViolentMonkey "does not collect user data at the moment", but also allows for it in the privacy policy.

That reddit thread is outdated. ViolentMonkey's actual privacy policy unambiguously states that they do not collect any user data.

https://violentmonkey.github.io/privacy/

I find it interesting how often I observe someone give a disclaimer about being bad at English, followed up with the clearest explanation / documentation / answer I've seen in a good month or so.