Befunge VS language

1. C compilers don't do a good job, & thus even CPython, which has historically stuck to rather vanilla C, uses computed goto, as described in https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...

I resorted to similar techniques in optimizing Befunge: https://github.com/serprex/Befunge (See bejit.c & marsh.c/marsh.h)

2. Rust enums are not variable sized, think of them as tagged C unions, where the Rust compiler can sometimes apply tricks to make Option> the same size as Vec

3. match can specialize for straight forward cases, when in doubt use https://godbolt.org

I've found async to be straight forward anytime I've used it. Promise#then is equivalent to callbacks

async/await often requires very little changes compared to synchronous code, whereas reworking a program into callbacks is much more impactful. & the async/await compilation process tends to produce better performance in addition to this. My first async/await work was a few years ago to increase a data importer's performance by an order of magnitude compared to the blocking code

Here's an example where looping made for a callback that recursively called, using async/await I get to use a plain loop:

before: https://github.com/serprex/Befunge/blob/946ea0024c4d87a1b75d...

after: https://github.com/serprex/Befunge/blob/9677ddddb7a26b7a17dd...

I don't see why people find it so complicated to separate begin-compute & wait-on-compute

I've since rewritten a nodejs game server into rust, https://github.com/serprex/openEtG/tree/master/src/rs/server... handleget/handlews are quite straight forward

You'll also find them used in CPython's ceval.c

I use them in both my C befunge implementations:

https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...

https://github.com/serprex/Befunge/blob/c97c8e63a4eb262f3a60...

I noticed that I can enable inline-class as an experiment to play with Extension Types. You need to also add sdk: ^3.3.0-0 to your pubspec.yaml.

Current syntax is not all that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose.

[1]: https://github.com/dart-lang/language/issues/3021

Reference

A future version of Dart will probably support macros which should make this all a bit easier to use, similar to how Swift 5.9 works which makes already fantastic use of its new macro capabilities by integrating mobx (or solidjs) like reactivity into SwiftUI by a harmlessly looking @Obervable annotation.

Coming from a Dart context here where that team is also looking at adding Macros to the language. It was really interesting to compare and contrast some of the approaches https://github.com/dart-lang/language/blob/main/working/macr...

Yes, that needs a bit of boilerplate for the constructor declaration and the extra build method, but I personally don't mind and with implicit constructors this will become much easier. Also, you get a performant UI as Flutter knows to not redraw widgets that didn't change.

I know that it would be nice not to use the generator at all, but we have to wait until static metaprogramming is implemented in dart. https://github.com/dart-lang/language/issues/1482

I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart.

I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I considered acceptable.

Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics):

https://github.com/dart-lang/language/blob/main/accepted/fut...

The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our approach yet, and we have some fairly large tests of matching on tuples of enums.