Community

Chat Logs

Friday, October 30, 2026 (America/New_York)

03:57:24phalethyet another TS runtime https://github.com/are-we-dodo-yet/dodo
04:56:24phalethhttps://1clickimpact.com/website-carbon/bytecode.news
05:05:03jreicherphaleth: "TS" runtime?
05:05:07jreicherYou mean typescript?
05:13:59phalethyup
05:15:50blueddf
05:15:57bluedeno dumpster fire :P
05:17:38jreicherI really don't know what to me make of js, ts, and wasm. So many people seem to think they are "competitive" now, and without any firsthand experience I'm left wondering "how is that possible"?
05:20:13bluets is js with types. wasm is a different beast, popularised by the web, but not limited to it. consider it an abstraction. many languages can compile *to* it, and the web (as in browsers, and also runtimes), can it
05:20:41blueyou can write a c program, compile it to a .wasm file, then load and run it in a browser, or in node
05:22:17bluefor c, gcc does not directly compile to wasm, so you usually use an additional tool call emscripten, `emcc`. but that's a gcc stupidity; clang has a wasm32 target
05:22:32bluefor go, rust or zig, they have wasm as a target
05:23:41bluenext to wasm, there is also wasi. when people started to run wasm code on runtimes, so on servers, they realised wasm doesn't have apis to interact with the operating system, i.e. IO/FS
05:24:19blueenter wasi, Web Assembly System Interface, aka POSIX for wasm
05:24:30jreicherI know what it "is". But I don't know what its place in the world is.
05:24:43jreicherOr rather I should say I know what they are.
05:25:13jreicherFrom what I can tell the only thing that distinguishes them is the historical browser runtime. And that's historical accident, no?
05:25:26jreicherI don't understand the technical merits, if any.
05:25:30bluedistinguishes what?
05:25:53blueI just told you what its place in the world is. the typical use can is cpu-intensive stuff running in the browser. you'd write it in another lanugage, then load it in the browser. that's a perf/interoperability gain
05:25:59blueuse case*
05:26:00jreicherWhy js/ts/wasm/wasi should be preferred over more elegant languages and runtimes.
05:26:21bluethat is a chain of dependencies
05:26:39bluejs should be preferred because it's the only language browsers understand natively. they don't understand python or ruby or php
05:26:52bluets should be preferred because it's a types-based superset of js
05:27:06jreicherThat is what I've always suspected, but I can't help wondering what would happen if browsers support another runtime. Care to speculate?
05:27:41bluewasm should be preferred for the first reason as well, combined with you wanting to execute NON-js code in the browser, for whatever reason. the emergent reason is performance, another is people wanting to run any of the languages I mentioned in the browser
05:28:49phalethif browsers supported anything better than JS then JS would be slowly but surely abandoned
05:28:52bluewasi is people trying to bridge the gap between wasm and server runtimes, so you can use wasm usefully on the server as well. what the use case there is, is yet to be revealed. some cloud providers support run wasm functions, that would bea use case
05:29:38bluebrowsers will never natively support another runtime, they have no reason to, and if they did, wasm killed off that reason
05:29:46phaleththe only reason JS is pervasive is cause of alot of people don't want to struggle with two languages on client and server and also cause web browser is way too convenient client
05:30:23bluebrowsers have no incentive structure to do, jreicher. js has been optimised in the last 10 years (v8, jsc) to run almost as fast as native code. and wasm now provides a good escape for cases it doesn't
05:30:27blueto do so*
05:30:45phaleththere are far better runtimes than the JS ones that can utilize hardware resources in a much better way than JS allows
05:30:55jreicherWhat I'm trying to get at is something like this: if a wasm-ish runtime was designed for browsers from scratch now, would it still look like wasm, and if not, what would it look like?
05:31:06bluethere are, but the cost of bringing them to the browser isn't justifiable
05:31:25jreicherI'm trying to separate history from technical merit.
05:31:28jreicherJust for my own understanding.
05:32:22blueit's hard to tell, jreicher. wasm is intentionally a very simple language with I believe like four primitive types. this is a bit like you asking, if x86 webassembly were redesigned today, how would it look like. I don't believe wasm has been specifically designed with js as the host/client language in mind, but I may be mistaken
05:32:36phalethwasm's goal is to be streamable and compilable at the same time, but so far a lot of it's uscases are not for the web, neither wasm is assembly, so the web assembly name is not very fitting
05:33:31phaleththe problem wasm can solve is the so called long cold starts of services
05:33:34jreicherThat's a good point. I should probably make some time to look at wasm while making a conscious effort to forget the branding
05:33:39bluehow jreicher, your question is not without merit. let me ask a question in return. if I want to run react today, and also benefit from things like SSR, but I want the server to be ruby, what are my options?
05:33:44blues/how/now/
05:34:31phalethwasm modules can be thought of as being scalable down to zero, due to the wasm service can just be started quickly so it can also remain shut down when not needed
05:34:43phalethbut there is of course orchestration around that is required
05:34:45blueso if you told me, "just take ruby on rails", I'd tell you, then I lose react SSR
05:34:51jreicherblue: Yeah the larger ecosystem most definitely makes a difference. That's one of the reasons I'm implementing my language in Java. I don't have an easy answer. I'm just trying to understand the landscape.
05:35:46bluewhat I'm trying to hint at it, that wasm is a nice abstraction for creating one application that can still use all the perks of js frameworks like react/svelte/vue, which need both a JS server and a JS client
05:36:04blueand also have a server running ruby code
05:36:15jreicherHint taken. I need to look at wasm again with that context in mind.
05:36:39bluethis is something ruby on rails can't do for ruby, or django for python, or spring for java, or any php framework for php
05:36:54bluebut it is something that primate does (for ruby/python/go; not yet for java/php)
05:37:30bluejreicher, you should look into people that want to run things like laraval but with react. it's very weird and complicated
05:37:39blue(they end up needing to run two servers)
05:37:53bluewasm solves that elegantly
05:38:05jreicherInteresting. Ta.
05:38:29phalethwasm is just an overengieered way to allow faster number crunching in web browsers, remember that all numbers in JS are 64 bit floats
05:38:35blueThis is also why I'm so excited about Java 25; with its native wasm compilation, it could be well supported by primate as backend. I just haven't got to it yet
05:38:58blue(designing the API is actually harder than wiring it)
05:39:14phalethwasm mvp (1.0) is 32 bit, the support for 64 was added to web browsers only recently
05:39:38bluephaleth forget wasm in the browser, it's not interesting there at all imho :P
05:39:55bluewasm is most interesting on the server because there I suddenly get access to the entire world of the programming language
05:40:13phalethalso the problem with JS is the required conversion to UTF-16 that has to be done all the time
05:40:20blueutf-16 strings?
05:40:22blueya
05:41:19blueI guess the point I'm trying to make is, perhaps interesting wasm/wasi use cases haven't arisen yet. primate is trying to change that
05:41:37phalethwasm was never meant to make runtimes multilingual, most of the widely used languages have their own GC and will never be able to cleanly tap into wasm's gc
05:41:45bluejreicher: https://primate.run/docs/backend
05:41:46nevetPrimate — Backends
05:42:11phalethbecause of that there are new languages being created and the ecosystem is being split further for the sake of hype and overengineering
05:42:55blueya well, that always happens
05:43:01phalethon the other hand wasm can unify the codebase of a project and solve problems with some of the so called native targets by allowing say kotlin to compile to wasm
05:43:08blueremember the mushroms-after-the-rain-framework cumbrian explosion after bun released?
05:43:11phalethand so a kotlin project can target mobile
05:43:38phalethblue: nope
05:44:11bluethings like honojs or elysiajs that are specifically bunonly
05:44:17bluetotal dumpster fire abandonware
05:44:20phalethalso Java has JS runtimes of it's own, no need to worry about wasm
05:44:35bluehonojs supports deno too I believe, but now deno is dead so it's effectively a bunonly framework
05:44:55phalethyeah, but hono is at least pushing performance boundaries of express and the likes
05:45:14phalethit's all hype perf and shit so people can rewrite for eternity
05:45:26blueya we should stop that
05:45:46blueit's easy to optimise correct stuff, it's hard to correct optimised nonsense
05:47:37phaleththere are dev teams forming foundations around new software tools and then people calling them douchebags for one reason or another so out of frustration new tools are created and new teams form
05:51:28blueya
08:42:14dreamrealnevet now has actual extension points :D
08:42:28dreamrealhad them, really, but now they're being used
08:42:53dreamreal(safecracker is now an extension and is no longer in the streampack repository)
11:10:40bluegreat
12:00:01bluedreamreal: idea for repopack. `rp verify <path-to-bin>`; gets sha256 of an exe, queries repopack, and shows you data about the bin, if published on repopack. date, publisher, status (if revoked)
12:01:22bluethis also is an idea in the direction of the "known-unknown" problem. if repopack always records the sha256 of every artifact it publishes, then this is a forward mechanism by design
12:02:03blue(regardless of the artifact itself has such a mechanism)
12:02:09blueregardless if*
12:30:20dreamrealyeah, makes sense
15:38:45bluedreamreal: I'd like your input on something
15:39:40blueso repopack has stacks. stacks are code dependencies. if I stack 256 on 255, then it doesn't rebase onto master, but onto 255. the idea is to have work that builds up on other work, and to avoid too many merge conflicts and rebasing after merging onto master
15:40:08bluegenerally, if I have a clean stack 1 -> 2 -> 3 -> 4, and all of them are reviewed and approved, then they will merge cleanly in order
15:40:21bluethe issue I'm facing are *non-linear* stacks
15:40:25blueconsider this:
15:40:30blueparent
15:40:35blue- child 1
15:40:38blue- child 2
15:41:16bluein this case, both children stack on parent, but they are independent of each other. they can merge in either order, and often merging one will introduce conflicts that need to be resolved in the other
15:41:32bluethey can have children of their own also, and so on
15:41:36blueso here's the thought:
15:42:01blueA) are non-linear (shared 'upstream' history) stacks useful at all? what use cases?
15:42:15blueB) if not, does it make sense to reject stacking more than one child on a parent?
15:42:31blueC) if yes, does it still make sense to allow an *opt-in* project setting "Only linear stacks"
15:42:34bluefin
15:46:02blue(so a 'use case' for non-linear stack is this: parent introduces necessary base work; then two children introduce two *independent* features that base on this work; but it doesn't sound like a very useful use case to me)