continuational

This is a really good mental image of what happens - thank you for sharing it.

That seems very promising. If it really is that good, wasm has a lot more potential in my eyes.

But e.g. sharp/vips ended up with a much worse result: https://www.libvips.org/2020/09/01/libvips-for-webassembly.h...

It may just be a matter of waiting for simd and threads though.

Tail calls are super important for non-C like control flow, and it's great that it might be added.

But what I really think wasm should focus on is to get near native performance (say, <50% overhead). Until that happens, the whole endeavor seems pointless to me.

I'd much rather click my way through menus than constantly be waiting for arbitrary delays.

The thing is, letting the user format some text as bold isn't really enough for many use cases. You need custom block and inline elements, such as tables, highlighted code or formulas.

Firefox was also clearly a better user experience at the time, which made it much easier to convince people to switch.

I switched back to Firefox a while ago for ideological reasons, but the majority of people are not going to switch to something that is more or less the same, just without their bookmarks, passwords and history.

Please see https://news.ycombinator.com/item?id=31672541

Sure - you typically cache the result of some expensive query.

The hard part of cache invalidation is to detect when an update somewhere in your system is going to affect the result of that query, such that you need to trigger an invalidation.

Please be careful with such bold claims. You don't really address the hard part of cache invalidation, which is to figure out when to do it.

With the risk of stating the obvious - the hard part of cache invalidation is to know when to invalidate the cache.

This article makes the classic mistake of assuming linked list = mutable doubly linked list.

Immutable, singly linked lists (aka cons lists) are a different beast entirely, and don't benchmark well in languages with heap fragmentation issues.

All artificial sweeteners I've tried, I've found absolutely horrible.

I don't really understand how to use VSCode efficiently. IntelliJ IDEA has the best editor I've tried so far. I'm not suggesting it could be a replacement for Emacs, however.

I think Emacs is built upon a golden idea: The programmable text buffer as the user interface for the OS.

A lot of data manipulation can be expressed as text manipulation, especially if it only has to be correct in a single instance.

However, Emacs is really starting to show its age. The keybindings are arcane and pre-standardization. There is no built-in support for multi-cursors, which are often much more direct than macro recording. Configurations are time consuming and perpetually broken. I think it's time for a replacement.

> General-Purpose, Industrial-Strength, Expressive, and Safe

> Here's how to do square and factorial.

Show, don't tell.

Why is it not bound to happen eventually?

How is the setInterval cleared when Counter is no longer rendered? It seems like a leak.

I figure latency hiding the primary challenge in networked games. Does this framework help with that?

You can't add async programming to a blocking language like Java or C#. It doesn't mix well, and will fragment the ecosystem with libraries that mustn't be used together.

I did a blind test of 6 brands of cola with a friend who claimed you couldn't taste the difference, and got them all right. In fairness, 3 of them were with artificial sweeteners, which is very easy to identify.

Hi everybody, author here. Firefly is a full-stack programming language in the making with colorless async/await.

Part 1: https://www.ahnfelt.net/async-await-inference-in-firefly/ Part 2: https://www.ahnfelt.net/async-await-inference-in-firefly-par... Part 3: https://www.ahnfelt.net/async-await-inference-in-firefly-par...

I'd love to know what you think about it :)

But then you have to wonder - what is the storage requirements for storing the results of every computation, ever?

I'm working on a web language with colorless async/await: https://www.ahnfelt.net/async-await-inference-in-firefly/

Hey, sorry for replying off topic.

We had a discussion on Firefly earlier, and I've just written the first small peice of Firefly documentation, introducing the new capability-based async/await inference: https://www.ahnfelt.net/async-await-inference-in-firefly/

You said to reach out by email, but it's not showing up for me on your profile. If you're interested, there's also a draft on part 2 here: https://www.ahnfelt.net/p/ce19cc5c-d18c-452f-86c3-85a920e748...

Thank you :)

But is it efficient? I would say web programming takes about a decade to become proficient in, after you learned to program. There are so many (perhaps accidental) things to know about the DOM, CSS, HTTP, web standards and practices, interactivity, hosting models, database tech, caching & CDNs, integrations & APIs, and god forbid, any "connect the dots" design and ux work that lands on your table.

There are a lot of solutions out there where you can share your datatypes between the client and server now though, and it's great!

I mostly agree, but it's very nice for the x% of your application that is real-time interactive. In some cases, x is high, such as Figma.

We have an internal JSON format for specifying the firewall configurations of all our servers. Essentially just "this group of servers can access this group of servers on these ports". Together with an idempotent "make it so" script, it has been a lifesaver.

The toolbox analogy breaks down when you realize that every language feature interacts with every other language feature. So it's more like a toolbelt that you have to wear. Hopefully, the tools aren't so plentyful and heavy that you spend all your energy dragging it along!

I like that analogy. You're saying that C should only be used in competitions, and not be allowed in the real world, right?