6d65

Keep up the good work and thank you for sharing.

I wasn't sold about the source level snapshot tests, they seemed clunky and not that universal. But, I am definitely giving snapit a try after this blog post, and the other two linked.

I might have to add a few things, most notably the support for multiline strings for more readable ascii art based prints, but I have a good feeling about this, but will see how it goes.

I have been tracking 5950x prices and anything over $300 seems unreasonable. And I think I'm just going to get a 7700x and a new MB and 32GB of RAM, it should be a $500-sh upgrade. It should have M3 like single threaded perf, multi threaded perf better than 5950x, slightly worse than M3 Max, better memory bandwidth than the 5950x.

You're right about just having a beefier PC, but maybe a baseline M2/M3 Air to SSH into a local machine + a beefier PC is a good combination. Luckly I switched to an all in terminal dev experience with Neovim/Helix/Tmux and the advantage is that one can seamlessly mix ssh/mosh shells in this workflow. Don't even need to set up any VNC/RDPs/Moonlights. Maybe even that is not needed if your languages supports ccache like tools.

I'm mostly interested in compilation speed, maybe running some programs faster on beefier hardware and I don't mind working on Linux.

So to recap, a baseline Air for portability(or some light ryzen laptop) plus a medium range PC seems like a winning combination for me. Given you already have a case/psu/ssd together they can cost as an entry level m3 macbook pro with 8GB of RAM.

Since everyone is sharing, I'm using bookmarklets daily, the main ones being 3x and 2x, which find the video element in the current page and speed it up.

I also made some overlay grid helpers, like 8h and 8v which create some overlay pass through elements and render red grid lines(8px spacing) using css. This is like an alignment tool for every page.

The bad thing is that Chrome and Edge don't highlight bookmarks by default when searching and makes one to type the top arrow key. Firefox used to be better in this regard, with the bookmarklet highlighted and ready to hit. The workaround for Chrome and Edge is to make the bookmarklet a search engine, that makes the bookmarklet selected by default.

Bookmarklets and custom search engines (for various online documentation sites, or plain jira, or aws) can be a productivity booster.

I wouldn't be able to navigate aws ssm without my trusty ssm search engine. Same for the others: EC2, CF, S3.

I should be using bookmarklets more though.

Another great post in the series.

I've been trying to bootstrap my own deep learning framework in Rust for a while now. I'm still stuck at implementing the stuff on the CPU.

But I've always wanted something running on GPU as well. I've poked at OpenCL, and webgpu. But Piet-gpu(more probably piet-hal) seems to be the best starting point in the Rust land.

Once I get to the GPU compute part, I'll start with Piet GPU. Not looking forward to debugging GPU compute kernels, but maybe it will be fun.

PS. It's a bit disheartening to see such buggy Vulkan implementations, since one of the main Vulkan selling points was less bugs in the drivers. I'm not sure what I'll see on Linux.

Also, I hoped that between Vulkan and Metal one could cover all the the major desktop OSes with GPU accelerated software. It's sad to see apple dropping the ball in this regard.

There is also the concern of code reuse and code quality. Doing something complex in one pass would mean a huge kernel. It would be interesting to investigate if something like openai's Triton can be implemented in top of Piet-gpu(HAL). A dsl embedded in Rust that could do kernel fusion, and generate one shader when composed together. I'll poke around at this when I get to Piet-gpu.

I'm vaguely familiar with Factor and hopefully not in process of reinventing it.

I was planning to investigate this space just for fun. Most likely nothing will come out if it and that's ok, it's just a learning opportunity.

Maybe I'm not using the proper FP function term. I don't mean functions as objects that you can store or pass around or higher order functions. Just take some arguments from stack, and return some values.

What I mean is that FORTH words seem to be functions taking stuff from stack and pushing stuff back. The composition is done by chaining them together.

This probably works fine with repl driven development(same as in lisp), you find out during development that your words cannot be composed. But as mentioned by others it may make the code hard to read, having to keep the state id the stack at all times in your head.

I was thinking just adding a light syntax, ex:

let add a b = a b +

// optional type annotation

let square a = a a *

let add-square = add square

Maybe add some type inference, support for structs, match expressions. But at the core keep the low level FORTH nature, with an interpreter and compiler.

It remains to be seen if it's possible to reach a balance here. FP programmers may be disappointed this is not a proper FP language, while FORTH programers may say it's a syntax ridden abomination.

I would say with some tooling (editor support, test framework, god forbid package manager), it can be an interesting option for embedded development.

There's a twitch streamer(tsoding) doing a FORTH like language from first principles.

I've watched a couple of episodes and went started my own. I learned a bit of arm64 assembly, and now I have both an interpreter and a compiler to M1 binaries. Very fun experience.

One day I'll slap a F#/OCaml'esque syntax on top of it with typed functions, structs, interfaces and see if it works.

At their core(it seems to me), concatenative languages are about function (words) composition.

So, instead if having "words", I would make them functions, with typed arguments, and simple argument matching (no more dups and swaps). This would probably make the language less flexible, but will make it more readable.

Anyway, FORTH is nice.

Well, Microsoft became quite a big company off the OS and their business suite.

Of course it will be hard to find corporate clients for a mobile os, but may be doable.

But, you're right, aside from Microsoft and Red hat, and maybe CoreOS some time ago, people don't seem to earn money from OSes, unless I'm missing something.

You have fair points and much more experience than I have in this domain.

Yeah, $5 even at a 1M users is probably not that much, having to maintain drivers, and as you mentioned serving updates, that would require a team.

With regards to the Google apps, I think a company would be better off trying to make something of their own, or collaborate with some app makers, at least for difficult stuff like maps, camera, gallery, browser(not sure about the paid codecs)

As for the app store, I know that's a big project, but that would have to be custom and a core product of the company.

Hope you'll eventually find a way to monetize your ROM.

I was thinking not too long ago about how phones are missing an installable os with a clear business plan.

There is the potential(given an unlocked bootloader), to use webusb to allow people flash the OS from an official website.

And maybe at a later day allow install from phone to phone via a cable, as a lot of people nowadays don't have a PC.

The pricing will be tricky though, $5 per install given a large user base, plus maybe some additional features for sale.

That being said, having an OS also means having an appstore, that alone could generate enough revenue to make the OS free.

By OS I mean an Android fork or a fuchsia based OS if the license allows it.

Eyesore is a precise word for the local keyword, from what I see the variable names in scripts are usually short, and the local keyword seems to draw more attention than the variable names themselves.

Of course this can be alleviated with syntax highlighting that would slightly mute the local keyword. And, people using Lua they day probably learn to ignore the keyword automatically.

Yep, it makes sense.

With the popularity of Roblox with the young people, and it using Lua for scripting, Lua can see a renaissance of some sorts.

I will definitely give it a try.

Even after many years of not using terralang I still cannot forget what a good of an idea it is.

Nelua seems like a more pragmatic implementation of similar ideas, but generates C code instead of embedding the llvm. And doesn't generate code at runtime. But still, things like ecotypes should be possible.

It will be interesting to play with the compile time lua scripting. Also, as mentioned in the other comments not sure about the GC. But there seems to be a manual memory management option.

But still, looks great, kudos to the author, keep up the great work.

PS: If I would implemented it, I would deviate a bit from Lua and replace local with let. It's highly subjective but I think it would make code "prettier"(whatever that means)

Bought the PDF after reading the free web version, the work definitely has a lot of love put into it and this has to be rewarded.

I've skimmed the web version till the end, but thoroughly read half of it, still learned a lot. Especially the pragmatic approach to code generation via string concatenation. I went a bit further with a small dsl that also does string concatenation.

My C# and Rust implementations are half baked, but still I had a lot of fun doing them, and that's all that counts.

Can't wait to see Bob's next endeavor.