Readit News logoReadit News
apatheticonion commented on Google will allow only apps from verified developers to be installed on Android   9to5google.com/2025/08/25... · Posted by u/kotaKat
medhir · 6 days ago
Every day we stray farther from the premise that we should be allowed to install / modify software on the computers we own.

Will once again re-up the concept of a “right to root access”, to prevent big corps from pulling this bs over and over again: https://medhir.com/blog/right-to-root-access

apatheticonion · 5 days ago
Also add "the right to maintain". Too many Android devices have drivers hidden behind kernel forks that will never be updated.

I'd love to install OpenWRT on my portable 5g modem currently running Android - . but I can't and likely never will. Same for my IoT automated blinds

apatheticonion commented on The Future of JavaScript: What Awaits Us   jsdev.space/future-of-jav... · Posted by u/javatuts
rafram · 11 days ago
Every major browser supports WASM and has for years.
apatheticonion · 11 days ago
Missing threads and bindings for the system/DOM interfaces
apatheticonion commented on The Future of JavaScript: What Awaits Us   jsdev.space/future-of-jav... · Posted by u/javatuts
apatheticonion · 11 days ago
I just want wasm so I can write web applications in Rust
apatheticonion commented on Comptime.ts: compile-time expressions for TypeScript   comptime.js.org/... · Posted by u/excalo
Wintamute · 25 days ago
Writing a web app at the moment with C++/Emscripten. What makes wasm unusable in Rust?
apatheticonion · 23 days ago
It's not unusable per-se, however being unable to take advantage of Rust's fearless concurrency and having to glue everything together with JavaScript severely restrict the usefulness.

May as well just use TypeScript and React at that point.

The dream is to be able to specify only a wasm file in an html script tag, have the tab consume under 1mb of memory and maximise the use of client hardware to produce a flawless user experience across all types of hardware.

apatheticonion commented on Comptime.ts: compile-time expressions for TypeScript   comptime.js.org/... · Posted by u/excalo
krukah · 25 days ago
Maybe the (relative) lack of ecosystem has kept you away, but I really recommend checking out both Dioxus and Leptos. Leptos is incredibly similar to React, but with Rust ergonomics, and it's been a pleasure to learn and use. With an LLM by my side that knows React and Rust pretty well, I've found myself not even needing the React libraries that I thought I would, since I can easily build on the fly the features/components I actually need.

I too, eventually gave up on React <> WASM <> Rust but I was able to port all my existing React over into Leptos in a few hours.

apatheticonion · 23 days ago
Yeah they are great, it's more the poor integration and lack of parallelism that makes it not worthwhile.

Thunking everything through JavaScript and not being able to take advantage of fearless concurrency severely restrict the use-cases. May as well just use TypeScript and React at that point

apatheticonion commented on Comptime.ts: compile-time expressions for TypeScript   comptime.js.org/... · Posted by u/excalo
teaearlgraycold · 25 days ago
Wrangling the borrow checker seems pretty manual at times. And I don’t know why you’d bother with a persnickety compile time GC when JS’s GC isn’t a top issue for front end development.
apatheticonion · 23 days ago
You stop noticing the borrow checker after a while and being able to write insanely parallel/performant code is quite rewarding.

Again, not all websites need to be usable on low end hardware/have a 1mb memory footprint - but there are a lot of use cases that would benefit.

Think, browser extensions that load on every tab and consume 150mb+ * number of tabs open and shares the main thread with the website.

ServiceWorkers that sit as background processes in your OS even when the browser is closed, that sort of thing.

apatheticonion commented on Comptime.ts: compile-time expressions for TypeScript   comptime.js.org/... · Posted by u/excalo
MrBuddyCasino · 24 days ago
I really really (really) don’t want Rust style macros and proc macros in JavaScript (or TypeScript), ever.
apatheticonion · 23 days ago
Might be a good idea to advocate for faster progress in wasm so fans of the feature don't try to pollute the language :p
apatheticonion commented on Comptime.ts: compile-time expressions for TypeScript   comptime.js.org/... · Posted by u/excalo
alpinisme · 24 days ago
Oh, I get the value of comptime! I was specifically responding to the rust-like macros comment
apatheticonion · 23 days ago
There are quite a lot of valid use cases to being able to transform arbitrary tokens into JavaScript at "compile" time. One that already exists is JSX, which is a macro that is baked into the TypeScript compiler but is restricted/tailored to React-style libraries.

We sort of get around this today using template literals and eval, but it's janky. https://github.com/developit/htm

A generic macro system could open the door to a framework like Svelte, Angular, Vue, etc being able to embed their template compilers (with LSP support) without wrapper compilers and IDE extensions.

e.g. imagine syntax like this being possible (not saying it's good)

```

export class MyComponent {

  template = Vue.template!(<div>{{ this.foo }}</div>)

  #[Vue.reactive]
  foo = 'Hello World'

  constructor() { setTimeout(() => this.foo = 'Updated', 1000) }
}

svelte.init(MyComponent, document.body)

```

Where the `template!` macro instructs the engine how to translate the tokens into their JavaScript syntax and the `#[reactive]` macro converts the class member into a getter/setter that triggers a re-render calculation.

It would need to be adopted by TC39 of course and the expectation would be that, if provided at runtime, a JavaScript engine could handle the preprocessing however transpilers should be able to pre-compute the outputs so they don't need to be evaluated at runtime.

apatheticonion commented on M5 MacBook Pro No Longer Coming in 2025   macrumors.com/2025/07/10/... · Posted by u/behnamoh
tracker1 · 23 days ago
If I were to guess, it's likely that sales projections are down right now, and they're hoping by keeping the existing line a bit longer, new buyer numbers will be larger in the spring. Most people don't upgrade every generation and a lot of people are still running M1/M2 devices.

I would also speculate that there may be some growing pains for the n2 production from TSMC, and/or a desire to get there in the AZ fab production before launch to avoid tariffs hitting their bottom line. They'd rather pay 12-20% more for just the CPU than eat large tariffs on the full cost. I don't think they'd be able to significantly raise prices further based on tariffs, like some other companies with smaller margins are forced to do, on order to be competitive.

apatheticonion · 23 days ago
Due to the limitations of MacOS, my M1 MacBook pro is pretty much exclusively a thin client (software dev, gaming) and I see no reason to upgrade it - unless battery degradation warrants it.

It's fantastic as a thin client - though it's a bit annoying carrying around a mini PC with me when I travel.

apatheticonion commented on Windows XP Professional   win32.run/... · Posted by u/pentagrama
inetknght · 24 days ago
> ...but I've yet to experience the level of DE stability you get from Windows XP/7

Have you used Cinnamon? I used Cinnamon for five years and the only weird quirk is needing to change the keybind for locking the machine (Power key + L defaults to opening some stupid debugger).

apatheticonion · 24 days ago
Not recently. I think the last time I used it was a few years ago. I'll take a look though!

u/apatheticonion

KarmaCake day1613August 4, 2017View Original