jbhoot
Joined 2 years ago
Joined 2 years ago
> Anti-colonialism has been economically catastrophic for the Indian people for decades. Why stop now?
Lingual purists may find it irritating, but I love such mix-ups!
I don't imagine this is a uniquely Indian phenomenon – other non-native English speakers would be doing the same.
Its a morphed version of the name of an Indian deity – Jagannath.
From https://en.wikipedia.org/wiki/Juggernaut:
> A juggernaut, in current English usage, is a literal or metaphorical force regarded as merciless, destructive, and unstoppable. > This English usage originates in the mid-nineteenth century. Juggernaut is the early rendering in English of Jagannath, an important deity in the Hindu traditions of eastern and north-eastern India. The meaning originates from the Hindu temple cars, which are chariots, often huge, used in processions or religious parades for Jagannath and other deities, the largest of which, once set into motion, are difficult to stop, steer or control by humans, on account of their massive weight.
alias gist='git status'
alias stagit='git stage'
alias gitcom='git commit' # also toying with comgit
For the rest, I just use the full commands to avoid accidents.Fiction has so much more to offer! On top of what you wrote, fiction helps you to develop an ability to put yourself in others' shoes. Empathy is anyway scarce in this politically-charged and ragebait-filled world.
Fiction has helped me develop empathy and to stay empathetic. It has helped me develop my philosophy of life; morals and values I strive to stay close to. The fictional characters have given me courage during hard times. And so much more.
Lot of people prefer to start with self-help kind of non-fiction which is, IMO, the least helpful category of books. I don't know what draw people to it.
I don't get that feeling after I put out a post on Bluesky.
For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.
In my PoC (https://github.com/jbhoot/poc-ocaml-logic-native-ui) - a tiny hello world CLI on macOS, that has a Swift "frontend" and OCaml "backend" - I followed a similar model:
- Both sides pass messages to each other. Both of them talk through C ABI. My model was synchronous though. Async is certainly better. - I used the protobuf binary protocol for message passing. Faster and probably more efficient than, say, JSON. But both sides may have copies of the same data for this reason.
I've written down my approach, which roughly aligns with yours, in the project's README.
What I wanted to do was for OCaml side to allocate data in memory, and for Swift to access the same memory through some commonly agreed upon protocol (protobuf itself maybe?). But I haven't yet explored how difficult this could be with GC coming in play. I think OCaml does have a few tricks to tell GC to not collect objects being shared through C ABI (https://ocaml.org/manual/5.3/intfc.html#s:c-gc-harmony), but I haven't looked into this enough to be sure.
Your projects will sure help me figure out the concepts!
Have you used https://github.com/Bogdanp/Noise? I assume serde would take up memory on both sides (Racket and Swift).
Sorry for a barrage of questions. I am quite curious about how all of this works. I am mulling over using OCaml for what you've used Racket for.
Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)?
In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I/O management. I understand using the native APIs for other "I/O" like UI, hardware interfaces (bluetooth, accelerometer, etc.), because they often don't have an equivalent API in the programming stack used to implement the common core.
As far as I know, Capacitor wraps over the native APIs.
• Website: <https://bhoot.dev> • GitHub: <https://github.com/jbhoot> • Lobsters: <https://lobste.rs/~bhoot> • LinkedIn: <https://linkedin.com/in/jbhoot> • Bluesky: <https://bsky.app/profile/bhoot.dev>