moosingin3space

Nearly all my work at this time is in C++, Rust, Python, and JavaScript. Thanks to pipenv, Python environments finally feel on par with Rust/cargo and NodeJS/Yarn.

C++, though, still a mess to get an isolated build environment there. Meson and Bazel are close, so close...

Pedantic: memory leaks are memory-safe, despite generally being undesirable.

Python isn't first-class in any GUI framework IIRC (although Qt for Python may change this). JavaScript and C#, with regards to GUI, are single-platform languages (I've never seen a UI built with Node and no browser, and I don't see a good way to build a Linux GUI in C# that is actively maintained). That leaves Java, which I will concede, even though Java isn't first-class on any platform except Android.

Why should horrible low-level or platform-specific languages be our only options for building GUIs?

This extension's functionality is definitely possible with the new APIs. Cookie manipulation APIs are exposed, including APIs for the separate cookie stores enabled by Multi-Account Containers.

While I'm very enthusiastic about the Librem 5, I think it would be better if they recommended a non-C language for app development. Gnome Builder, the IDE they recommend, has support for Vala, Rust, and Python, all of which should provide a much better developer experience, not to mention should enable more reliable apps.

Is this similar to what Svelte does, where Svelte compiles down to the right DOM transformations?

What actions?

Gnome is moving in this direction by using Flatpak + Gnome Builder. They're also running CI inside the Flatpak environment.

Unofficial slogan of the C apologism task force, apparently.

I'm not pcwalton, but he is correct. The Rust compiler only allows objects that implement the Sync trait to cross thread boundaries. Rc<T> is not Sync, while Arc<T> is. Sync is a marker trait, with impls automatically generated by the compiler for types that are comprised entirely of Sync types, or manually (and unsafely) specified by the author. As a result, Rc<T> cannot be misused from multiple threads without unsafe.

To learn more about this, look here: https://doc.rust-lang.org/beta/nomicon/send-and-sync.html

I like aiohttp for simple Python HTTP apps.

It's no secret that I dislike C. That said, I'm very pleased to see libraries like this, because I think that much of what are extolled as the benefits of OOP can be achieved with effective use of message-passing between modules. This handles both stateless and stateful components well, in many cases better than C++/Java-style class-oriented OOP.

Yeah, I think Kubernetes is more like a distributed OS than a distributed systemd.

I would probably just use either docker-compose or systemd+runc for a single node, then use Ansible to manage configurations. Kubernetes strongly assumes you've got a cluster, not a single node.

I use uMatrix for this purpose, and to block third-party frames to defend against clickjacking. That said, Multi-Account Containers still are very useful.

I've had issues where sshfs hangs in uninterruptible sleep if the connection is lost.

It uses the WebSocket API.

> Only a small minority of crates should require any manual work to opt in to a new edition

Is this going to be tracked through the system that catches compiler regressions against the entire crates.io ecosystem?

I expect this niche will be filled by Matrix in the near future. Host a Matrix homeserver + Riot.im web UI, then employees can use Riot mobile apps and any Matrix-supporting client.

For the record, I don't like Slack very much. I just disagree that IRC or IRCCloud are acceptable alternatives.

Sorry, I really don't see the "bait and switch" here. IRC/XMPP gateways were never a selling point of Slack. Bots were always supposed to use the proprietary WebSocket/HTTP APIs, and in all the companies I've worked in that use Slack, not a single person used the IRC or XMPP gateway.

Open-source project communities should not be using Slack, if for no reason other than the 10k message limit and the fact that it's annoying to be present in multiple Slacks. I prefer IRC or Gitter for those communities, as they're better designed around the flow of "drop in, drop out" than Slack.

Which is a centralized, proprietary, web-based client. All three of which HN loves to hate Slack for.

See, I thought you were complaining about software complexity when you posted your original comment about "why does a text editor need so much abstraction". Nope, turns out it's just another run-of-the-mill anti-Electron rant.

Every text editor beyond the most basic is incredibly complex. Terminals are a complete mess, so every terminal-based text editor certainly can't be called "simple", and that's not even beginning to consider extensibility! Emacs and Vim have entire interpreters embedded into their codebases, for instance.

Maybe text editors with an extensible feature set really are more complex than we've been led to believe?

The strategies being employed here look similar to those of xi (CRDTs for multithreaded buffer representation) and neovim (separable backend and frontend). This is definitely a project I'll be keeping my eye on.

Another thing that's interesting is that if they're targeting a web-embedded editor (mentioned as a goal), they could possibly reduce the need for a full Electron install, possibly using the Rust web-view bindings[1] to link with the system web engine.

[1]: https://github.com/Boscop/web-view

Been enjoying your library webview for some small home projects. Thanks!

56 will never get backported security fixes of any kind. For the record, neither will 57, as 58 is the current stable version. Mozilla does not apply security fixes to versions of Firefox other than the latest stable and the latest ESR.

Default on Fedora Gnome since 25.

Unlikely -- remote X11 display performance for anything GPU-accelerated isn't great due to X11's design, not Firefox's.

Hmm, I did not know this. Good to know!