fayten

I have spent a lot of time in the PL space and I just cannot wrap my head around the love of Racket. I absolutely love the innovation that comes out of the community though! The gradual types system work, nanopass, embeddable DSLs are all fabulous so I like to keep tabs on what they are cooking up.

I recently picked up Essentials of Compilation by Jeremy Siek, perhaps his book and lectures will make something click for me.

In the meantime Julia has been my happy medium for a “lisp”.

Unless you are actively managing your own herd or actively hunting I don’t see how you are connecting to nature at the grocery store.

People don’t care as long as it tastes good. The current methods we have for farming meat do not scale and we need to work on alternatives. Meat is tasty and people want to eat it.

Innovation will continue in the lab grown meat sector and when it eventually scales it will over take traditional methods. Current factory farming is anything but natural and there is plenty of harm being done.

I always love seeing more done in the web component space. I think Lit has the no build process captured pretty well and they include things such as a router.

I do prefer the style of of your components more, where you separate out the script and styles with html tags. I don't know if one way or the other is superior for performance, I but just like the separation verse the templated strings in Lit.

With build tools being so straightforward now-a-days, I struggle to see the value in the build less approach. One use case I can think of is maybe a constrained environment where the application contains some kind of customizable user components fully in the browser like a reporting WYSIWIG of some kind.

Is there a particular reason you prefer this approach?

If it allows for alternative design patterns that are simpler then I think it's a win in the end. For example pattern matching is great when writer parsers as an alternative to going the visitor pattern route.

Pattern matching has finally made it out of ML land and getting increasingly implemented in mainstream languages. I'm not sure if Rust is the main driver here, but I'm glad to see it.

I have been dabbling with F# for scripts as well. The F# REPL (FSI) and .fsx files make it really easy to hammer something out and share.

I also found Superset unintuitive to use and setup as well. I settled on standing up Metabase because it was so simple to get started with trying it since it can be launched as a single jar. The business users loved it and so did I and administration with a Postgres backend instead of the internal h2 database was a breeze.

I started evaluating Defold this past weekend and I have been very impressed.

The developer experience is very similar to Godot, especially if you work on your scripts with external editors. Everything that has to do with building and running the app is faster than Godot though.

Initial builds with Defold are very fast, it has on demand hotreload, and very small binary sizes. The small binary size makes it well suited for working on web games.

The Godot Editor is still a tad bit nicer to use, but I do like the fact that the Defold editor is written in Clojure. I imagine it makes extending it fairly quick.

The main reason I see myself sticking with Defold over Godot is because scripting is done in Lua.

The Lua ecosystem has a lot history in the game dev space making it easy to search for answers. Lua is trivial to extend and has multiple statically typed options that compile to it. Notable statically typed languages are Typescript and Haxe. Also Lua has a lot practical use in many domains outside of the Defold editor unlike GDScripts lock-in to Godot.

Defold has no where near the size of the community of Godot, but the developers seem very active on the forum and GitHub.

I need to play around with it more before I’m 100% sold. Both Godot and Defold are great looking choices for 2D.

That is wild, thanks for sharing the soundcloud link!

Very cool stuff, thank you for your hard work on Emmy!