It probably is. Since they already have a working web app, why would they throw all that away and start a new project from scratch targeting 3 platforms (MacOS, Linux and Windows) and triple the maintenance burden?

I'm assuming they have reworked their current web app into an electron (or similar) desktop application and going forward they can make changes and immediately push out to both web and desktop.

We should ask people who complain about Electron apps if they're willing to pay an extra $20/month to pay for a team of developers to make and maintain a native app for each platform.

I'd bet they say no. If they say yes, they're lying.

I'm on Linux and elecron apps are always good news for me, because I know I won't be left out ;)

Unless you're using Evernote. Private Beta for Evernote for Linux and afterwards..... An email saying they are stopping the development of Evernote Linux :)

PS: Electron, AFAIK.

Damn, that's some low effort for Linux people. Well I’m using Obsidian. They’re on some old version of electron. Which is annoying but it works well other than that it requires some exception in my Nix config.

Leading to features like "Karmic Dice" in the recent Baldur's Gate 3

There is a consideration there that isn't necessarily a problem with randomness itself. (Though I agree that the randomness does bring its own problems.)

Say you're playing through someone's electronic D&D module and you try to do something with a 90% chance of success. Then you roll a 2. You didn't make a mistake when deciding what to do, so that feels wrong -- this is a problem with randomness.

What do you do? You reload from right before you tried to do the thing, and you reroll. The game can't actually make you accept randomness if you don't want to. So they have to do something else.

That seems like missing the point of the article. What I understand the author to mean with Dart plan vs Typescript plan is the way these languages approached evolution of the base language (JavaScript).

Dart aimed to replace JavaScript completely and isn’t very compatible with it, leading to issues like not being able to leverage the existing library ecosystem. While the Typescript approach enhances the base language instead of replacing it and is still compatible with existing libraries.

When looking at language adoption, the Typescript approach seems to have worked a lot better than the Dart approach. If it wasn’t for Flutter, Dart would probably be irrelevant by now and Typescript is now pretty much everywhere where JavaScript is.

Another successful-ish example of the Typescript plan is Kotlin, which was originally designed as an improved Java, fully compatible with the existing ecosystem.

So I can see where the author comes from when trying to do the same thing for C++.

Herb would like to associate Cpp2 with Typescript (which is generally considered to have succeeded) and other 2022 C++ Successor Languages with Dart (not so much). Herb emphasises the way in which what he's done is like Typescript and de-emphasises ways in which it's entirely unlike Typescript.

I guess that's smart positioning. But a big problem Herb has is that the real alternative isn't any of those 2022 C++ Successor Languages. Ultimately your project will decide whether to stick with C++ or go to a language like Rust or maybe Swift. "Alternatives to C++" that might be finished some time in the next five years are irrelevant to that decision. It's like arguing that you're the best Chicago-style pizza joint in Naples. Who cares?

And when comparing against Rust or Swift, we're back to Herb's ten year head start problem also mentioned in this talk. Rust is what, 18 months away from its tenth anniversary of Rust 1.0? Swift is even closer.

The problem with your argument is that swift is not, and cannot be, a replacement for C++. At best it can be an alternative for some programs, and on macOS only; for the rest of the world it's not very useful. And rust is great but the thing it lacks here is a great C++ interop story, the way TS has with JS and kotlin has with java. There's not really any language with that today (maybe D?) that also has a compelling story of being modern and safer than C++.

In that sense, cpp2 might get to the point of being usable while having perfect interop with C++ (as in, you can use any C++ library trivially, and you can mix it with C++ in a codebase on a per file, maybe even within files, easily) before Rust or swift or Carbon.

From point of view from Apple it is, for their own ecosystem.

It is also a reason why if you want modern C++ support on Apple devices, now you need to install clang yourself.

As Apple keeps focusing on Swift, with Objective-C for its companion.

When you don’t care about the discussions being in the public record the comments don’t necessarily need to be integrated in the blog.

I have my email on my personal site and when an article reaches the frontpage on HN I usually get some emails related to the post.

Same.

I don’t want my website to be a distribution channel. The last thing I want is to be managing visitors to my home.

I’ll let the distributors do their thing to pass my content around and I’ll own/manage my own content on my homepage.

I'm putting my full comment here to add to the Linux votes since I'm on Linux 80% of my time. Although, I will be given the macOS trial a shot soon as I have an iOS project in the pipeline.

Congrats on launching and sharing! The idea of an integrated all-in-one solution is intriguing to me. So intriguing that over the last 10 years I've started various projects in a similar direction. Mostly focused on integrating calendars (multiple external calendars), tasks and notes within the same app. Lesser focus on web app integration or focus modes.

Combining calendar, tasks en notes within the same app is something that I have not found a good solution for. Most apps focus on only 1 aspect and lack in the others typically leading to having to use a separate app for each aspect, and then losing time and focus by context switching between apps.

A few years ago I wrote about my experiences in this space[1].

I'm curious to see how you have tackled this problem and how the integration between tasks/calendars (and notes?) works.

also: The "Learn more" link near the bottom does not go anywhere.

[1]: https://stevenvanbael.com/open-calendar-task-space-is-a-mess

How does N relate to the number of parameters that is frequently mentioned?

In my screed, N is the attention width. (How many token it looks at at a time) number of parameters is O(KxNxNxL) where k is the vector size of your tokens, and l is the # of layers. There are other parameters floating around, like in the encoder and decoder matrices, but the NXN matrix dominates.

This is an awesome explanation. You guys are the real heroes

Imagine your keyboard lagging a few extra ms before the character you typed is visible on the screen.

Average keyboard latency is between 3-15ms depending upon the type of keyboard switches used and the connection type.

I have a feeling desktop development is going to slowly revert back to classic OOP paradigms just like the web world detoured from MPA -> SPA -> SPA+SSR -> back to something that looks a lot like MPA again.

Classic toolkits like GTK, Qt, UIKit/AppKit, Swing and JavaFX use OOP to solve some of the problems this article talks about.

However, this OOP model seems to be somewhat incompatible with Rust's strict memory safety rules. At least I think it is because I haven't seen any big efforts for a Rust OOP toolkit like this. Most of the existing Rust toolkits are immediate mode or ECS or something "reactive" that looks like React.

While I understand the idea of moving away from "unsafe" languages like C/C++ to something like Rust, I wonder if Rust is the right language for building UI applications? Maybe a better architecture is to use Rust for the core logic as a library to be consumed by a higher level language that meshes well with these OOP widget tree and event handling paradigms.

I think we need other UI models instead of everything mature being object-oriented-oriented. Doing UI work in FP (or FRP) is great in many aspects until you need to integrate with these OO models like the DOM, et.al. Direct integration or a first-class VDOM-like model would be a nice step. There’s a tangent issue with all of popular game engines built around objects.

Even Lisp programmers decide to pragmatically use an OOP model when doing GUIs.

The idea of using FP for everything is about as sensible as the paradigm of using OOP for everything.

You say that like CL programmers are inherently functional, which has never been true. They have always embraced OOP when needed

Less, I would say; because using OOP for everything is straightforward, just obtuse, verbose and possibly slow.

You don't have to solve paper-worthy academic puzzles to use OOP everywhere.

Using OOP everywhere has been done and probably continues to in some shops. There was a time in the 1990's when nobody was fired for using OOP everywhere.

In Common Lisp, absolutely every value you can create has a class: the class-of function is meaningful for any value. You can replace all the defun forms in a Common Lisp program with defgeneric and defmethod.

What you're asking for is what Compose does (the new Android toolkit). Being pure FP though does have issues. There's no way to get a reference to anything on the screen, so some tasks that are basic and obvious in an OOP toolkit turn into a strange hack in Compose. For instance to focus a text edit you have to create and memoize a "focus requester", pass the "requester" as a parameter to the TextField function, then "launch an effect" and finally you can use the requester to request the focus.

Compare to an OOP toolkit: call edit.focus() when the UI is first displayed and you're done. The reason you need a requester in Compose is because everything is FP and lacks identity, even though there actually is object identity buried deep inside, it's just hidden from you.

The FP model does have some benefits, but I think OP is right and we'll end up with a less radical mixed approach.

Is there a practical functional model for GUIs?

If something doesn't exist, maybe the reason is "it's a poor fit".

If you're going to assert that FP is a better fit for GUIs, you need some demonstration of that, especially since it's been decades since this meme started.

Using the Spotify Rest API it is already possible to build nice feature rich Spotify clients for remote players. I don't think there is a supported native playback library? I'm not sure how local playback is implemented in this project.

The main problem I have with the Spotify API is that its remote playback management API is limited/incompatible with some players (Sonos).

It relies on a separate client for playback, which can be an open source client like librespot/spotifyd, or an official client. It's also mostly older systems using the older, deprecated, playback client that aren't compatible with the Web API afaik.

One of the things I'm thinking about recently is putting a Mac mini on my desk for occasional iOS development on multiplatform projects (main laptop is Linux) and keep it always running as a CI runner for those projects.