WingNews logo WingNews GitHub [2]

jaxrtech's comments

jaxrtech | 2 years ago | on: The Rust I wanted had no future

If Rust was a higher-level language, then I'd say yes, just automatically handle running Futures in parallel, join them when you actually need to resolve the data, and pretend that they look like synchronous functions in the 80% of cases. Though things like `select!` wouldn't make any sense mixing the two.

I continue to find the "function coloring" argument misses the point unless you're arguing from a developer experience perspective. Why should two fundamentally different things look and function the same? Want this the ultimate pitfall of early RPC implementations where everything looks synchronous?

In Rust, a lot of the friction is due to how async functions/futures fundamentally differ in model of execution and how that interplays with the rest of the language. Other languages get to hand-wave a lot of these problems away with a GC. (It certainly could be less of a pain nonetheless.)

- Futures don't execute until polled, can partially execute if something isn't ready (and would block), can partially execute and be arbitrary cancelled and dropped. There is no equivalent in sync functions unless you make them co-routines.

- Since you can "pause" futures if something would block, you need a place to store the function's state for when it's resumed. Now you must be consider if the async function's state is `Send` if the future wants to move to a different thread to continue executing -- which is why you see `pin!` used. Sync functions don't care about this since you always run to completion on the same thread, and the stack is ephemeral.

- Likewise, the `Future` returned by the async function is going to need to encapsulate it's state that it saves. In the general case, this is a compiler generated anonymous struct that changes if any state saved across `.await` changes, hence the opaque `impl Future`. This is why you see `BoxedFuture` a lot to abstract this away at the expense of an allocation. Ideally, the new associated types with lifetimes can avoid this with traits.

So if all functions were co-routines (i.e. functions that can be resumed and re-entered) they would all have the same "color". But all you really did was "lift" all sync functions to be "async" functions with no internal await points.

(IMHO, if the C# team back in the day decided to implement full blown co-routines into the language instead of just `async/await` as a compiler trick, I think many other projects would have followed suit with a more general co-routine solution instead of treating `async/await` as this special thing which is just a specific compiler generated implementation of co-routines.)

jaxrtech | 2 years ago | on: Language Pragmatics Engineering

Various thoughts:

It seems to me that the fundamental definition of a function/method should be a compile time executed function that generates a syntax tree always (assuming the compiler dog-foods itself or can parse and interpret it). Much like Python has metaclasses or Rust's procedural macros but it's just assumed by default.

It's kind of unfortunate that a language with managed effects & capabilities hasn't gone mainstream. Maybe it doesn't have the right ergonomics yet.

jaxrtech | 2 years ago | on: htmx

This vaguely reminds me of Adobe's ColdFusion except in the browser for better or worse.

jaxrtech | 3 years ago | on: Ncdu – NCurses Disk Usage

Just fair warning. 99% of the time, ncdu is great at intuitively finding what is taking up space. Know that unlinked, but in-use files still take up "physical" disk space.

Be weary on machines that have not been restarted I'm a while. The free space reported on the file system layer may not be the same as the amount of space taken up by files.

i.e. It's possible that delete files may still be referenced by processes still running since the space will not be reclaimed until they are killed or close the fd. This commonly happens with GB of log files you deleted but at still `open()`.

That seems to be the greatest difference between Windows and Linux from an OS & file system perspective. - Windows treats files similar to a row in adl database with locking behavior: "This file entry must be deleted from the system. Tell me if I'd be locked out by another process". - Linux treats files as reference counted resources: "I no longer need this file in this directory. The underlying data can still be referenced. You can unlink it."

jaxrtech | 3 years ago | on: Blessed.rs – An unofficial guide to the Rust ecosystem

This is fantastic. This is almost identical to what I've been having to remember in the back of my head every time I go create a new project haha. I've also settled on the anyhow + thiserror deal. Rust is not batteries included -- it's nice for those experienced or beginners to know which batteries to use without going on some expedition to find them.

The more challenging part is working in niche areas, https://lib.rs definitely helps as well.

jaxrtech | 3 years ago | on: Pitchfork: Rack HTTP server for shared-nothing architecture

A lot of the time, I ask myself, "why don't we seem to have a tool with robust source-to-source transformation?" You could call it "cross-language refactoring". I wouldn't be surprised if someone with the code-base the size of Google has some internal tool. Maybe this is just wishful thinking. The closest thing I've seen is in academic research, e.g. [1].

[1]: Koppel, Solar-Lezama - Incremental parametric syntax for multi-language transformation (2017) - https://dl.acm.org/doi/10.1145/3135932.3135940

jaxrtech | 3 years ago | on: Improving Firefox Responsiveness on macOS

From my understanding, Chromium/WebKit/V8 and Firefox/Gecko/Spidermonkey are the last (major) contenders in the browser engine space. After Opera switched to WebKit in 2013. And Edge in 2020. I'm sure there are numerous lesser known ones...
page 1
more