Chris Siebenmann

Monomorphization does not guarantee inlining of lambdas. You can perfectly well output a monomorphized version of the 'contains' method specialized to the type of a particular lambda argument and then call this lambda on each loop iteration in the generated code. (Rust's assembly output is pretty impenetrable compared to Go's, but I believe this is exactly what happens if you compile something like this without optimizations: https://godbolt.org/z/qaYbGMMzM)

It does not surprise me that Rust inlines more aggressively than Go, but that doesn't have anything much to do with differences between Rust and Go generics or type systems.

Adopting the type-level fiction that every lambda has a unique type does not fundamentally make inlining any easier for the compiler. It may well be that in Rust the monomorphization triggered by this feature of the type system leads to more inlining than would otherwise happen. But that is just an idiosyncrasy of Rust. Compilers can do whatever kind of inlining they like regardless of whether or not they think that every anonymous function has its own unique type.

Edit: One further thing that's worth noting here is that the Go compiler does do cross-module inlining. So (unlike in the case of a typical C compiler) it is not the case that the kind of inlining we've been talking about here can only occur if the function and the lambda exist in the same module or source file. https://utcc.utoronto.ca/~cks/space/blog/programming/GoInlinesAcrossPackages

Author has an article on that too[1]

To explain what I learned on my own:

If you want to (for example) put 4 NVME drives (4 lanes each) in a 16x slot, then you need two things:

1. The 16x slot actually needs to have 16 lanes (on consumer motherboards there is only one slot like this, and on many the second 16x slot shares the lanes, so it will need to be empty)

2. You need to configure the PCIe controller to treat that slot as 4 separate slots (this is called PCIe bifurcation.

For recent Ryzen CPUs, the first 16x slot usually goes directly to the CPU, and the CPU supports bifurcation, so (assuming your BIOS allows enabling bifurcation; most recent ones do) all you need to do is figure out which PCIe lanes go to which slots (the motherboard manual will have this).

If you aren't going to use the integrated graphics, you'll need a 16x slot for your GPU. This will at best have 4 lanes, and on most motherboards (all 800 series chipset motherboards from all major manufacturers) will be multiplexed over the chipset, so now your GPU is sharing bandwidth with e.g. USB and Ethernet, which seems less than ideal (I've not benchmarked, maybe someone else has?).

In the event that you want to do a 4x NVME in a 16x slot I found that the "MSI X670E ACE" has a 4x slot that does not go throught the chipset, and so does the "ASRock B650M Pro x3D RS WiFi" either of those should work with a 9000 series Ryzen CPU.

ThreadRipper CPUs have like a gajillion PCIe lanes, so there shouldn't be…

> What helped C was exactly the same as what made JavaScript sucessful, it came with a free beer platform (UNIX).

Your saying that reminds me of this:

https://utcc.utoronto.ca/~cks/space/blog/programming/CTriumph

> This significantly understates the real appeal of C at the time, even and especially to people who had alternative languages. A great illustration of this is C on the early Macintosh. You see, unlike environments like MS-DOS (which had no language associated with it, just assembler), the early Macintosh systems already had a programming language; they were designed to be programmed in Pascal (and the Mac ROMs were originally written in Pascal before being converted to assembler).

> This was more than just an issue of Apple's suggested language being Pascal instead of C. The entire Mac API was designed around Pascal calling conventions and various Pascal data structures; it really was a Pascal API. Programming a Mac in C involved basically swimming upstream against this API, full of dealing with things like non-C strings (if I remember right, Mac ROM strings were one byte length plus data).

[snip]

> Despite all of this, C crushed Pascal to become by far the dominant programming language on the Macintosh. [snip] C was enough better to displace Pascal in a hostile environment.

> C did not win just because it was at the right place at the right time. C won in significant part because it was (and is) a genuinely good language for the job it does. As a result it…

The "#" key on the phone is called the "pound key" in the US and Canada.

https://en.wikipedia.org/wiki/Number_sign#Names

It still is, to this day: if you call an automated system such as voicemail, you may be prompted to "press 'pound'". This is really standardized, AFAICT, and no telephone system has told me to "press hash" or "press the 'number' key" [because that's ambiguous]

cks has a history of #! but not an etymology: https://utcc.utoronto.ca/~cks/space/blog/unix/ExecAndShebangHistory

He links to Wikipedia which documents a good history: https://en.wikipedia.org/wiki/Shebang_(Unix)#History

I was trying to recall what we called it. I used SVR3, so I would've been using "#!/bin/sh" as early as 1990, and even more on SunOS 4 and other Unix servers.

I can't recall having a name for it until "hash-bang" gained currency later. We knew it was activated by the magic(5) kernel interpretations. I often called "#" as "pound" from the telephone usage, and I recall being tempted to verbalize it in C64 BASIC programming, or shell comment characters, but knowing it was not the same.

"The whole shebang" is a Civil-War-era American idiom that survived with my grandparents, so I was familiar with that meaning. And not really paying attention to Ricky Martin's discography.

Wikipedia says that Larry Wall used it in 1989. I was a fervent follower of Larry Wall in the mid-90s and Perl was my #1 scripting language. If anyone would coin and/or popularize a term like that, it's Just…

(Note: that was in this article https://utcc.utoronto.ca/~cks/space/blog/programming/ErrorHandlingNotSolvedProblem)

Yeah and more generally, the author seems to group Go and C on one side (langs where errors are values) and Rust in another, when actually in Rust errors are values just like in Go, and the ? operator just does early return (similar to if err != nil return from Go). Results just make it impossible to use the return value of some function without deciding what to do with its errors, which is awesome (you can't just forget to treat errors)

The distinction between results and panics in Rust is also very instructive. Rust forces the developer to distinguish between recoverable and unrecoverable errors because after the program hit a panic (meant to represent unrecoverable errors) there is probably no meaningful way to continue the execution (data structures might be in an inconsistent state for example, if the panic happened in the midst of an update). Panics very often indicate a bug in the program (for example: array indexing with an out of bounds index means there was a bug while calculating the index) and no amount of error recovery will eliminate the fact that the program has a bug that must be fixed. It's absolutely the best default to interrupt the program after a bug rather than continue and propagate data corruption further.

Now, what can happen is that a library you call considered some error to be unrecoverable (and thus threw a panic) rather than…

There's been a relatively comprehensive take-down on autoconf (1), that boils down to:

It's an old piece of software, with basically no maintainers, which is fantastically difficult to make any changes to.

Not... stable because it "just works"; unchanging because it's so enormously complex to make and coordinate even trivial changes, that it is effectively the peak of the software lifecycle, where something has accumulated so much technical debt you can no longer make changes to it.

...so; in that context, being a fan of some features that autoconf supports is interesting, but, makes absolutely no difference to the reality; that it needs to die in a fire and be replaced.

Software, that you cannot change, is dead. Especially a build tool, that has failed to be maintained to changing needs of developers.

If autoconf wants to live, people need a comprehensive plan to maintain it, not to sing praises of its current, clearly bad, state.

> it has been popular to suggest that Autoconf should go away.

Yes.

...because no one has a plan to maintain it or fix it.

> Some of the people suggesting this have also been proposing that the replacement for Autoconf and the 'configure' scripts it generates be something simpler.

Specifically who?

Build systems are hard. No one serious, who understands what they're talking about and the context around it that I've seen is suggesting this.

...most people, seem to consistently be suggesting that the current state of autoconf is…