mtndew4brkfst

Well, survivorship bias means that Elixir is loudly populated by AI maximalists now. Just go look at the last several years worth of US/EU Elixirconf talks schedules, it's maybe a third of each cohort and included in keynote slots.

Now we watch this viewpoint proliferate thousands and thousands of times over, even if it's less commonly stated so baldly, and yet people still wonder where the doomer viewpoints stem from?

I find Mergiraf pretty pleasant to use and frequently pretty helpful as a time-saver. Handles TOML and Rust for me, and I have way fewer manual interventions, especially after supplementing it with rustfmt rules to not do a bunch of merged use statements in one go. Easy to configure as a jujutsu tool as well.

https://mergiraf.org/

I think my point doesn't really land. I was trying to express the idea "S3 is not a standard where AWS is the reference implementation, it is a successful commercial product with many many copy cats".

Their only real inherent commitment here is to whatever backwards-compatibility expectations are being set for their first-party SDKs. If they fulfill that but other vendors can't or won't follow suit, the outcome is gonna be different than it would be for an actual standard rather than an assumed one. There is no meaningful leverage for the third parties to exert to force a community-favored outcome if Amazon decides otherwise.

The ones in my neighborhood are full of religious evangelism titles or bad self-help books.

I can't see how Amazon is incentivized to avoid making any changes that break compatibility for their imitators, so long as their first party SDKs continue working. Standardized feels like it should be suffixed with "as long as Amazon doesn't ever feel like evolving the product further".

You're probably thinking of Actix and the unsafe/TechEmpower thing? I've never seen Axum involved in any notable drama.

I have no idea about timeline, progress, or suitability, but IIUC the Tauri folks are exploring integration with Chromium Embedded Framework:

https://github.com/tauri-apps/cef-rs

https://github.com/tauri-apps/tauri/issues/14963#issuecommen... and following comments

https://github.com/tauri-apps/tauri/issues?q=CEF

For some people cua-mode being opt-in and very difficult to discover organically will be a larger barrier for comfort and learning than normal/insert modes and motion commands could ever hope to be.

(10 year evil-mode user who moved to Neovim for other reasons, chiefly performance/LSP nativity/plugin ecosystem vitality)

Animated server logos, colorful /gradient and tonally-varied usernames & avatars, the super emoji or whatever they're called, etc all feel like they're pushing more towards Twitch chat than anything else. Which as another commenter remarked, is essentially aligned with their original and biggest target demographic.

Content grist for the algorithm mill, so I would say so. Also gives the appearance of staying on the bleeding edge which may attract viewers.

I knew before I opened the article that this was going to be about or at least include the Jumping <Food> entries. Happy to be right, and for them to be gone.

Andy is very critical of using mmap in database implementations.

GitHub has never allowed public repos to disable PRs in particular. There's no setting for that.

One foundational misunderstanding in your very first bullet - Universal Blue distros are installable operating systems that happen to use container image formats as a file representation for network distribution and update mechanisms, but you're expected to be running it on actual hardware or as a traditional VM. The outermost "container" part is largely an incidental implementation detail. You don't run these as a workload on like, a Kube cluster, or anything like that.

The underlying project in question for the next conceptual layer down is rpm-ostree:

https://coreos.github.io/rpm-ostree/

Here's one from 2002: https://meyerweb.com/eric/comment/chech.html

It's literally impossible for open source development to be an asocial or apolitical endeavor.

"LWN.net is a reader-supported news site dedicated to producing the best coverage from within the Linux and free software development communities."

FOSS beyond Linux itself is still explicitly on-topic by the site's own self-description.

But we all know what this was about anyway. Good luck to you out there.

Why does her hair color matter to you? Why is open source longevity and viability not on-topic for LWN discussion?

Dr Foster holds a PhD, did her dissertation about the Linux kernel, and has had a respectably long career in technology with a focus on open source and governance. The topic is literally straight in her professional wheelhouse.

In an ideal world, yes, my belief is that that produces the best results.

Very very much so. The project also includes separate binary releases with this feature compiled out altogether, but I'd much rather this sort of feature was never ideated or acted upon in this first place.

Generally speaking I don't want a terminal multiplexer to be doing network IO of any sort, so I also didn't love it when they shipped "load WASM plugins from a non-checksummed arbitrary URL via your config file" in a previous release.

As with my comment in another tree, no, none of the Elixir core team or Dashbit employees are directly involved with this effort, though they may be advising informally and will likely submit a PR here and there.

https://dashbit.co/#team https://elixir-lang.org/development.html#team https://github.com/elixir-lang/expert/graphs/contributors

I would say there's an ocean of software with better UX than those two, so it all comes down to what axis you measure on.

Nit: there has never been an official LSP implementation until now, only community-authored. Even now no Dashbit employees or language core members are directly involved in this project in an ongoing basis.

IMO that contributes powerfully to the quality of the experiences of using any of the options.

It has both a justfile and a makefile at the root, even. Most of us seem to want to use it to throw make away entirely.

That said, I consider `just` very language-agnostic and useful because of that, and I consider mix pretty bad at any workflow needs that isn't directly concerned with BEAM.

It's unkind to publicly speculate on this in this particular way, IMO.

API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.

IMO in the 12 months or so I've been aware of the BABLR work and observed the author's comment contributions, they've never really substantiated why BABLR would be preferable to tree-sitter, or how a JS-based implementation of parser tech can fulfill any of the same niches. Most consumers of tree-sitter leverage it via FFI or native code, not an embedded or external JS runtime.

It's not clear to me how you could substantially replace the capabilities/benefits of what LSP provides with BABLR either.

Nothing since then really recaptured what I personally liked about GWave or let me use their tool in similar ways to how I used it. YMMV, of course, more so than most of my comments.

It is, however, a commit object per change because of how jj tracks the evolution of commits. Those intermediate/ephemeral commits will not be able to be GC'd from git object storage until they are either abandoned in jj or are removed from the jj op log. The latter of which AFAIK does not happen automatically, not even on a time/age basis.

I am an extremely fervent believer in jj and use it exclusively since December '24, but I think it's useful to be accurate as possible for these kinds of trade offs. I don't use watchman snapshots specifically because of this downside.