ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Community

Chat Logs

Friday, October 30, 2026 (America/New_York)

  1. * phaleth joined #primate
  2. * skillnews quit (Remote host closed the connection)
  3. * skillbot quit (Remote host closed the connection)
  4. * skillbot joined #primate
  5. * skillnews joined #primate
  6. * jreicher quit (Read error: Connection reset by peer)
  7. * phaleth quit (Ping timeout: 248 seconds)
  8. * phaleth joined #primate
  9. * phaleth quit (Remote host closed the connection)
  10. * phaleth joined #primate
  11. phalethyet another TS runtime https://github.com/are-we-dodo-yet/dodo
  12. * phaleth_ joined #primate
  13. * phaleth quit (Remote host closed the connection)
  14. * phaleth_ is now known as phaleth
  15. * jreicher joined #primate
  16. phalethhttps://1clickimpact.com/website-carbon/bytecode.news
  17. jreicherphaleth: "TS" runtime?
  18. jreicherYou mean typescript?
  19. phalethyup
  20. blueddf
  21. bluedeno dumpster fire :P
  22. jreicherI 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"?
  23. bluets 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
  24. blueyou can write a c program, compile it to a .wasm file, then load and run it in a browser, or in node
  25. bluefor 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
  26. bluefor go, rust or zig, they have wasm as a target
  27. bluenext 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
  28. blueenter wasi, Web Assembly System Interface, aka POSIX for wasm
  29. jreicherI know what it "is". But I don't know what its place in the world is.
  30. jreicherOr rather I should say I know what they are.
  31. jreicherFrom what I can tell the only thing that distinguishes them is the historical browser runtime. And that's historical accident, no?
  32. jreicherI don't understand the technical merits, if any.
  33. bluedistinguishes what?
  34. blueI 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
  35. blueuse case*
  36. jreicherWhy js/ts/wasm/wasi should be preferred over more elegant languages and runtimes.
  37. bluethat is a chain of dependencies
  38. bluejs should be preferred because it's the only language browsers understand natively. they don't understand python or ruby or php
  39. bluets should be preferred because it's a types-based superset of js
  40. jreicherThat is what I've always suspected, but I can't help wondering what would happen if browsers support another runtime. Care to speculate?
  41. bluewasm 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
  42. phalethif browsers supported anything better than JS then JS would be slowly but surely abandoned
  43. bluewasi 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
  44. bluebrowsers will never natively support another runtime, they have no reason to, and if they did, wasm killed off that reason
  45. phaleththe 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
  46. bluebrowsers 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
  47. blueto do so*
  48. phaleththere are far better runtimes than the JS ones that can utilize hardware resources in a much better way than JS allows
  49. jreicherWhat 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?
  50. bluethere are, but the cost of bringing them to the browser isn't justifiable
  51. jreicherI'm trying to separate history from technical merit.
  52. jreicherJust for my own understanding.
  53. blueit'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
  54. phalethwasm'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
  55. phaleththe problem wasm can solve is the so called long cold starts of services
  56. jreicherThat's a good point. I should probably make some time to look at wasm while making a conscious effort to forget the branding
  57. bluehow 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?
  58. blues/how/now/
  59. phalethwasm 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
  60. phalethbut there is of course orchestration around that is required
  61. blueso if you told me, "just take ruby on rails", I'd tell you, then I lose react SSR
  62. jreicherblue: 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.
  63. bluewhat 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
  64. blueand also have a server running ruby code
  65. jreicherHint taken. I need to look at wasm again with that context in mind.
  66. bluethis is something ruby on rails can't do for ruby, or django for python, or spring for java, or any php framework for php
  67. bluebut it is something that primate does (for ruby/python/go; not yet for java/php)
  68. bluejreicher, you should look into people that want to run things like laraval but with react. it's very weird and complicated
  69. blue(they end up needing to run two servers)
  70. bluewasm solves that elegantly
  71. jreicherInteresting. Ta.
  72. phalethwasm is just an overengieered way to allow faster number crunching in web browsers, remember that all numbers in JS are 64 bit floats
  73. blueThis 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
  74. blue(designing the API is actually harder than wiring it)
  75. phalethwasm mvp (1.0) is 32 bit, the support for 64 was added to web browsers only recently
  76. bluephaleth forget wasm in the browser, it's not interesting there at all imho :P
  77. bluewasm is most interesting on the server because there I suddenly get access to the entire world of the programming language
  78. phalethalso the problem with JS is the required conversion to UTF-16 that has to be done all the time
  79. blueutf-16 strings?
  80. blueya
  81. blueI 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
  82. phalethwasm 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
  83. bluejreicher: https://primate.run/docs/backend
  84. nevetPrimate — Backends
  85. phalethbecause of that there are new languages being created and the ecosystem is being split further for the sake of hype and overengineering
  86. blueya well, that always happens
  87. phalethon 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
  88. blueremember the mushroms-after-the-rain-framework cumbrian explosion after bun released?
  89. phalethand so a kotlin project can target mobile
  90. phalethblue: nope
  91. bluethings like honojs or elysiajs that are specifically bunonly
  92. bluetotal dumpster fire abandonware
  93. phalethalso Java has JS runtimes of it's own, no need to worry about wasm
  94. bluehonojs supports deno too I believe, but now deno is dead so it's effectively a bunonly framework
  95. phalethyeah, but hono is at least pushing performance boundaries of express and the likes
  96. phalethit's all hype perf and shit so people can rewrite for eternity
  97. blueya we should stop that
  98. blueit's easy to optimise correct stuff, it's hard to correct optimised nonsense
  99. phaleththere 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
  100. blueya
  101. * nevet joined #primate
  102. * blue!~blue@user/blue changed the topic to: https://primate.run | This channel is logged: https://bytecode.news/logs/irc/libera/primate
  103. * nevet joined #primate
  104. * blue!~blue@user/blue changed the topic to: https://primate.run | This channel is logged: https://bytecode.news/logs/irc/libera/primate
  105. * nevet joined #primate
  106. * blue!~blue@user/blue changed the topic to: https://primate.run | This channel is logged: https://bytecode.news/logs/irc/libera/primate
  107. dreamrealnevet now has actual extension points :D
  108. dreamrealhad them, really, but now they're being used
  109. dreamreal(safecracker is now an extension and is no longer in the streampack repository)
  110. * nevet joined #primate
  111. * blue!~blue@user/blue changed the topic to: https://primate.run | This channel is logged: https://bytecode.news/logs/irc/libera/primate
  112. bluegreat
  113. bluedreamreal: 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)
  114. bluethis 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
  115. blue(regardless of the artifact itself has such a mechanism)
  116. blueregardless if*
  117. dreamrealyeah, makes sense
  118. * skillnews quit (Remote host closed the connection)
  119. * skillbot quit (Remote host closed the connection)
  120. * skillbot joined #primate
  121. * skillnews joined #primate
  122. * phaleth quit (Quit: phaleth)
  123. bluedreamreal: I'd like your input on something
  124. blueso 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
  125. bluegenerally, 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
  126. bluethe issue I'm facing are *non-linear* stacks
  127. blueconsider this:
  128. blueparent
  129. blue- child 1
  130. blue- child 2
  131. bluein 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
  132. bluethey can have children of their own also, and so on
  133. blueso here's the thought:
  134. blueA) are non-linear (shared 'upstream' history) stacks useful at all? what use cases?
  135. blueB) if not, does it make sense to reject stacking more than one child on a parent?
  136. blueC) if yes, does it still make sense to allow an *opt-in* project setting "Only linear stacks"
  137. bluefin
  138. blue(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)