Drop #243 (2023-04-19): Watch Your Language! (And Runtime!)

C23; Node 20; Svelte, TypeScript, And The Looming War For Your Dev-Attention

Being a Daily Drop reader means you do your best (with or without the aid of my blatherings) to keep up with what's happening in the tech world. That's hard work.

We are constantly bombarded with new technologies, frameworks, languages, runtimes, apps, and more; each promising to make our development or data science lives easier and our code/analyses more efficient. But, with so many options available, it can be difficult to know where to focus our attention on any given day. That's one reason I make the Drop! It's a kind of like a daily digital “dowsing rod”¹.

Now, I know I have a tendency to focus on the ✨ shiny super new toys the cool kids are 👀. But, the — lacking a better term — foundational components, like good ol' “C” and trusty “Node.js” still matter quite a bit, despite young upstarts like Rust and Deno looking to send them to the cyber-retirement home.

So, today we'll take a peek at what “C” is up to, how Node.js is doing on its 20th (release) birthday, and explain why I added a 100% clickbait title in the third topic. 🙃

C23

Photo by Claudio Schwarz on Unsplash

The last major revision of the C standard was C11, and — since these standards adopt the 2-digit year idiom for versioning — that was a while ago. Sure, there have been interim releases, but it's been a full twelve years since our C Overlords gave us the new C23 [direct — large — PDF].

In the immortal words of Iñigo Montoya: Let me explain. … No, there is too much. Let me sum up… what the core changes entail²:

1. Introduction of new attributes, such as nodiscard and maybe_unused.

2. Clarifications and updates to the restrict keyword, alignment requirements, and floating-point semantics.

3. Updates to the preprocessor, including line numbers and new directives.

4. Changes to the handling of wide characters, string literals, and character encoding.

5. Updates to the floating-point library, including new functions, macros, and features.

6. Improvements to the handling of integer types, including new fundamental types for N-bit integers and bit-precise bit fields.

7. Enhancements to enumerations, compound literals, and object declarations.

8. Introduction of new functions and utilities for memory management, time handling, and bit manipulation.

If you are primarily an R or Python user (which I suspect categorizes ~85% of Drop readers), you may not care too much about a new C standard, but you should! While many packages that rely on a shared object library for core functionality in both ecosystems are being rewritten in Rust (or even WASM-ified), C/C++ is still the primary extension language. C is a notoriously unsafe language, so, could it be possible C23 starts to level the playing field with Rust/Go?

(Also, C/C++ is also, still, what powers Linux, macOS and many bits of IoT.)

So, one area I'd like you to focus on (in all that spare time you have) in C23 — with the aid of “Catch-23: The New C Standard Sets the World on Fire - ACM Queue” — is a specific feature in item number six in the above list.

That ACM Queue post discusses the entirety of the new C23 standard and highlights some new features and improvements in more depth than I did here. The one I'd like you to dig into is <stdckdint.h>. That's not some foreign language curse, but a header for checked integer arithmetic. That's right, if coders do the work, C/C++ programs are about to get a whole lot safer! There are some more “batteries included” saftey guardrails, too. While all of them combined are nowhere near Rust's level of safety³, it is a welcome improvement.

It goes on to mention a new #embed feature for something called literate executables, discusses the importance of idiomatic and fluent code in C programming, and provides examples of common idioms and best practices. It also has a fair amount of justified jabs and snark. Furthermore, it’s just a great read.

While I won't be turning back to C/C++ for library or executable work, it's great to see the standard evolve with a continued focus on safety in each iteration.

Node 20

Photo by Richard Burlton on Unsplash

There's a bunch packed into the Node.js v20. A new “test runner” provides foundational components for leveling up your — you guessed it — tests. The core V8 engine got some nitrous injections (i.e., it's overall faster than previous versions). ArrayBuffer and SharedArrayBuffer objects are also now resizable/growable (in a performant way).

Another neat new feature is the ability to make Single Executable Applications which allows the distribution of a Node.js application (conveniently) to a system that does not have Node.js installed.

But, what excites me the most — b/c I'm a cybersecurity safety/control freak — is the new Permissions Model which enables developers to restrict access to specific resources during execution, such as the file system, child processes, and worker threads. I want this baked into R, Python, Julia, Rust, Golang… everything. I know it'll cause some pain, but if folks take advantage of this, it'll do tons of good and make life harder for attackers.

Pour out a glass/mug of your fav beverage and see what v20 has to offer.

By the next release, Node will be old enough to drink in the 🇺🇸!

Svelte, TypeScript, And The Looming War For Your Dev-Attention

Photo by Matt Artz on Unsplash

I've already acknowledged the headline was kind of just clickbait fodder, but I do want to close with a short but serious discussion about the current, dangerous state of JavaScript development after we cover the Svelte bit. I figured that was as good a way to get your attention on this last section as any.

The catalyst for this section was an article from back in March — Rich Harris Talks SvelteKit and What’s Next for Svelte - The New Stack. In it, there was a passing mention about Svelte/SvelteKit (we've covered that before) abandoning TypeScript in favor of vanilla javascript.

There has been and is now a modest controversy over using TypeScript as the basis for a web project (vs vanilla js). It's mainly about the trade-offs between the benefits of TypeScript's static typing (and other features) and the costs of the additional complexity and build time it introduces.

Some folks argue (raises hand) that TypeScript can bring a false sense of security and may not be worth it for smaller projects or prototypes. Others believe that TypeScript can improve code quality, reduce bugs, and make it easier to maintain large codebases. But, ultimately, the decision to use TypeScript or plain JavaScript depends on the specific needs and goals of the project, as well as the preferences and expertise of the development team.

If you've never even given this a first or second thought, here are four links to dig into, before I close with another reason not to use TypeScript:

• When to Use TypesScript: Pros and Cons for JavaScript Devs - Prismic

• Why You Should Use TypeScript

• What Is TypeScript? Pros and Cons of TypeScript vs. JavaScript

• What is TypeScript and why should you use it? | Contentful

Now, for some war talk.

You may not be aware that one of the most evil corporations on the planet owns:

• GitHub

  • which includes Copilot

• NPM

• TypeScript, and

• VS Code

That is insane.

They, in essence, own the entirety of the predominant components of the most prolific/prevalent developer ecosystem. In my not-so-humble opinion, it is too much. Do you, your team, your org really think Microsoft has your best interest at heart? Do they not have a massive history of turning capricious or cost-conscious on a dime/whim? Do you think you are not the product when you engage in any of those ecosystems?

I think I'll stick with just ensuring critical JS components have decent JSDoc entries so that any decent IDE can provide the necessary composition, definition, and visibility helpers that make it possible to write safer code faster.

Take another look at that list and, perhaps, reconsider some [development] life choices (says the dude who is ironically writing this in VS Code o_O).

FIN

We made it to Wednesday! Time to crush the rest of the week! ☮

1. That being said, I have no idea how Wikipedia got this picture of me.

2. Astute, long-time readers may be wondering “what’s up with the numbered list?”, but I assure you there is a method to this numerical madness.

3. which is, itself, somewhat of a Potempkin village, which we'll get into at another time