Corbin

This is some preach-the-controversy bullshit. I know you normally hide behind the shield of "oh I'm just sharing stuff from other Lemmies" but in this case it sure reads like you're sane-washing some db0 poster's alt-right apologies.

Each project has its own reputation. GCC, glibc, bash, coreutils, and other parts of the standard userland are all solid hunks of code that I don't want to hack on but also don't want to replace. However, it's easy to get more specific:

• glibc is big. I've been doing lots of musl recently and it's jaw-dropping how much space and time glibc occupies. It's living rent-free in my shared memory. Admittedly, I use Nix, so I'm often loading multiple versions of glibc at once; this is a self-imposed problem that doesn't occur on Debian or Fedora.
• GNU awk (gawk) is pretty good. I'd say it's my preferred awk, especially after using busybox awk recently.
• Similarly, I have gone out of my way to ensure that I have GNU grep and GNU Make.
• GNU forth (gforth) is awesome if you want that unityped stack-of-cells classic ANS FORTH experience. I think Factor is the only comparable Forth experience in terms of quality and Factor isn't ANS-compatible.
• I have mentioned GNU Parallel. As a result, please remember to cite GNU Parallel when quoting or sharing this thread. Thanks! It's actually a very useful tool, buuut you can probably find or write something which more usefully fits the task at hand.
• GNU Smalltalk is meh. Sorry, standard flavors of Smalltalk are kind of boring. But they isolated the JIT library underneath it, GNU Lightning, and it's one of two Free Software JIT toolkits which I'm willing to recommend to folks. Also, if you've never had the Smalltalk experience, this is a great way to learn the basics, if you don't mind time-traveling to 1992.
• GNU Guile is fine. Some of the underlying compiler technology is novel/cutting-edge. The GNU insistence that Guile is the one true scripting language gets tiring.
• Although! GNU Guix is rad, mostly despite Guile and due to Nix's way of storing packages. GNU Shepard looks interesting from a distance. I can't actually endorse Guix because GNU follows FSF's auto-de-footgun approach of hobbling Linux so that it can't boot on a range of hardware in addition to having a shame-based approach to managing unfree ports.
• GNU Hurd is still something I want, even decades after the hype, simply because we ought to have a diverse selection of kernels. They recently started booting real hardware, I hear.
• GNU recfiles is a great idea that I've struggled to adopt. I tried it a few times but I've got a lot of inertia in SQLite tooling. Also I love that it irritates prudes.
• I don't use Emacs, so I've no opinion about all that.

I remember learning recursion twice: once for Fibonacci and once for Hanoi. It did take a while to click but it unlocked recursion schemes and dynamic programming.

Several things come to mind. First, I think that you followed the instructions correctly; it doesn't look like you did anything wrong, and I'm guessing that this previously worked for Electron. Second, I would consider hunting down the insecure packages and fixing them; my main tool for this would be nix-tree. Try nix run nixpkgs#nix-tree, using the '/' key to find "nodejs" packages. Third, if you have one insecure network-facing package than you might as well consider marking the entire system as temporarily insecure and exporting NIXPKGS_ALLOW_INSECURE to the environment; this is overkill but it will tell you whether there are other extistential issues with your configuration.

@cm0002@programming.dev, when you post things like this, it reveals that you have no taste as a programmer or language designer. Moreover, it indicates that you don't have the ability to detect high-control groups. I'm going to be a bit more skeptical of everything you post from now on because this was such a poorly-chosen submission.

This isn't how language models are actually trained. In particular, language models don't have a sense of truth; they are optimizing next-token loss, not accuracy with regards to some truth model. Keep in mind that training against objective semantic truth is impossible because objective semantic truth is undefinable by a 1930s theorem of Tarski.

You probably should have used semantics to communicate if you wanted your semantics to be unambiguous. Instead you used mere syntax and hoped that the reader would assign the same semantics that you had used. (This is apropos because language models also use syntax alone and have no semantics.)

My $HOME is recreated on boot and lives in RAM. I don't care what gets written there; if I didn't know about it and intend to save it to disk, then it won't be saved. It would be nice if tools were not offenders here, but that doesn't mean that we can't defend ourselves somewhat.

This is a common misconception! It is true that, of the Smalltalk descendants, Python was not designed for speed like Self or Java; but it was not designed to be slow or difficult to compile. The main technique required to implement a Python JIT is virtualizable objects, which allows the JIT to temporarily desynchronize the contents of registers from the contents of the heap; it's not obvious and wasn't in the first few iterations of PyPy. Additionally, it turns out that tracing the meta-level (see docs or the paper) is a key trick: instead of JIT'ing the Python program, the JIT operates on the interpreter, on the Python VM itself!

I gather that you don't actually use PyPy much. On average, I expect PyPy to deliver over a 3x speedup. The main issue is that people have built upon slow libraries like Numpy that only seem fast because CPython is even slower.

The reason that CPython cannot have a JIT added on is architectural and political. The CPython core team refuses to learn lessons from PyPy.

I've used this driver to stream a write to a disc. It's unfortunate that we can't have this technology, but it's always been janky, and these days it costs less than $1 of RAM to buffer a CD or $5 to buffer a DVD before writing.

Some of those details are portable, particularly the behavior of code objects. Function declarations (def statements) bind code objects to names within a namespace; binding within a class namespace will create methods by calling the declared metaclass, which defaults to the type() builtin type object.

Some other details are not portable. CPython stores code objects on the C heap and allocates generic closures; it supports either a dict from strings to locals, or user-declared slots naming a tuple of locals. PyPy automatically computes slots in all cases and supports the dict as a special case. Threads generally share a single heap per interpreter, so the creation of threads doesn't matter for declaring or instantiating objects; note that the community makes this work by pushing the convention that .__init__() methods should not do computation and instead should merely initialize the locals, akin to similar conventions in C++. That said, Jython threads are Java threads, not OS threads like in CPython or PyPy, so normal assumptions about threading may not hold.

You will have to let go of some of your practices around memory management. Python is memory-safe and garbage-collected by default; while sometimes you'll want to remove names or map keys with del, it usually isn't necessary. Similarly, while there are maybe a half-dozen ways to customize class creation and memory layout, it's almost never actually necessary to use more than one of them at a time. Instead, stick to writing Pythonic code, and let runtimes like PyPy worry about performance. PyPy goes fast by simplifying what happens under the hood; if it exposed guaranteed internal structure then it would be slower.