kaba0

Off topic, but rust really messed up the terminology by using 'enums' for sum types.

Rich Hickey has a presentation titled 'Maybe Not' that talks about this exact distinction, but he actually argues the reverse (and often criticized quite wildly, even though both sides are sort of right here, I believe). He says that nullability is better [1], as refactoring a function that accepted T to T?, or a function's return type from T? to T are both backwards compatible, while the sum type variants require code change.

Your last sentence put the whole argument even better in place in my head, it depending on the runtime is both a blessing and a curse and is what let's us change function signatures in a backwards compatible way, while also what hinders our ability to reason/encode stuff in it statically.

[1] I think part of the misunderstanding here between the "two camps" is that some people work on systems that are a closed world. You know and control everything, so an all-encompassing type system that can evolve with the universe itself makes the most sense. Hickey on the other hand worked/works mostly in an area where big systems developed by completely different entities have to communicate with each other with little to no coordination. You can't willy nilly refactor your code and just trust the compiler to do its job, this is the open sea. Also, I think this area is a bit neglected by more modern/hyped languages, e.g. the dynamicism that the JVM has is not really reproduced anywhere anymore?

I don't know, go has lackluster expressivity, and these pre-compile tools always feel like a hack in its case.

Let’s not fool ourselves, linux’s accessibility (and anything else) support was lackluster to begin with. Android and ios is far far superior on every count from an accessibility perspective and interestingly they have a sane security model.

This has absolutely nothing to do with the technology, it’s just that there is no standard protocol for one more thing simply because accessibility experts don’t happen to do some free work that will be de facto accepted by multiple different vendors. Comparatively, apple or google can just declare that this new API is the way to go, and support it natively from the de facto frameworks of the platform (and probably paid for accessibility experts along the way).

It shouldn’t complicate the program itself, everything should be sandboxed by default.

And they should simply not have access to my home folder, it should be given access to a specific file only it is about to read.

> Why do I have to open Moebius sync to keep syncthing synchronization running

Because it’s a mobile OS and every single spent CPU cycle is a detriment to battery life? There is absolutely nothing in the security model that would prevent it from running - but it is essential that processes have a “structured” lifetime.

E.g. compare how much more graceful android is in low-memory situations, asking apps to serialize their state and then stopping the last used one. Linux oomkiller will just reap my whole display manager for some reason.

In what way or form? Citation needed.

You might be living in a bubble. The majority of the population doesn’t have a PC, most people use a smartphone as their only general purpose computer. And while you may not run blender on your phone and render a full-time movie with ray-tracing there, there is absolutely no fundamental limitation, it just so happens to primarily target portable devices, not beasts of a machine with 4 video cards. This functionality requires zero special permission, neither does photoshop (of which there are multiple mobile-versions), or digital painting which, etc.

You would be surprised how many content creator gets by with a single ipad.

But what’s the limiting factor of doing the sane and safe thing by default?

The most popular operating systems all do that (ios and android), and they have carved out safe APIs for all of that to work. You can’t patch up a Swiss cheese after the fact.

Is it hard to create standard APIs in a bazaar style of development? Yeah. But that doesn’t mean that it’s not the correct approach.

They queried that info based on a specific implementation of a framework. If that framework is implemented under Wayland, then through the Wayland APIs it will only get rudimentary info on mouse position (e.g. only when it’s in focus and the mouse is over it).

And an often under appreciated tenet of security — even a “good” software can be exposed to “bad” data, and you only need a bug (especially a memory bug, which is exceedingly common because linux userspace can’t get rid of c for the life of it) to have arbitrary code executed.

Like, your pdf reader is surely not evil, but do you trust every single pdf file you open?

XOrg was predominantly used as a useless middleman between a compositor and a window manager communicating with each other. Just because the wayland compositor is “one big important process” doesn’t mean that the whole architecture is more complicated.

Multiple IPCs make the whole stuff way more complex, there is a reason why we have a big monolith as browsers and not some `curl | htmlRender | jsInterpreter` Rube Goldberg machine — the unix philosophy is not the pan ultimate design, it works in some cases and is utterly broken in others.

Heh? That hasn’t been true on even the very first POC wayland compositor, Weston. I mean, it used to crash from time to time in the very early days, but visual artifacts? I don’t remember any, besides the occasional xwayland app (which is literally an X app running inside wayland).

(Nitpick, but it’s just a “superficial” superset. The biggest difference is probably doing “multi-methods”, aka the runtime type of an argument deciding which method implementation to call vs java’s static overload resolution.)

‘Informed users’ has always been a joke.

Apple’s intelligence has the benefit of a much deeper integration (if they can live up to their wwdc), which will pretty much bring the sci-fi assistent to life. Just say “when will my plane depart” and when siri replies ask it to “send that info to X” is absolutely possible with current LLM tech exposed to a standardized API against which it can execute commands. Give it some personalized context and that’s absolutely reachable tech.

I don’t know, if apple can pull it off, that will bring a huge change to human-device interactions.

The java metric is also from a single core. But you are probably right that it should only be taken as a rough ballpark, but java is definitely in the same ballpark as go in compile speed.

The actual compilation step is 100% not the bottleneck - it can go as fast as 10k-50k lines per second! (According to the Mill benchmark, but that’s the Mill-independent part).

Comparatively, Go does “only” 16k lines per second based on some HN comments.

Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools.

What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?

To be blunt, if anything it might be you who live in a closed bubble.

Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.

There are quite a few cases: the moment you touch another language, resources that require a compile-step (e.g. xml schemas to code dtos, protonbuf, all that kind of stuff), sometimes even the code itself requires generation.

First invocation may be. Subsequent builds are very fast, unless someone decided to write random bullshit into the build scripts that execute at config time, making the config process impure.

There is basically no DSL. You simply write what a build needs, e.g. you write a function `collectCFiles()` that collects every file with extension `.c`. You then issue a command like `gcc ${collectCFiles()}`. And pretty much that’s it - you can use shell commands, or do anything in scala (or java or whathaveyou). You simply have your functions return either a value (e.g. a checksum) or a location, which is the only mill-specific logic. So your compileC() function will simply invoke your collectCFiles() function, and this invocation implicitly creates a dependency between these tasks. You have written literally the simplest way to describe your build logic. But in the background mill will cache your functions’ inputs outputs and parallelize those that need re-run, which is what a build tool should do.

The implementation may not be the theoretical best, but I think the idea is pretty much the perfect build system out there.

Not the parent commenter, but I feel it mixes sandboxing and a non-ideal packaging method together.

Something like nix solves the second problem so much more elegantly.

From your own article:

> The Flutter team would like to eventually turn the semantics on by default in Flutter Web. However, at the moment, this would lead to noticeable performance costs in a significant number of cases, and requires some optimization before the default can be changed

Its web targeted version is still not accessible, even though they promised that they will actually render to HTML elements as much as possible. A single canvas element is not that.

Throwing out the baby with the bath water? There are millions of standardized APIs available in the browser that would be probably impossible to recreate in anything else due to failing consensus.

So throwing out literally 99% of what makes the web actually portable and useful?

A random drawn rectangle is not a UI, it’s not accessible, not inspectable, not part of the de facto OS native toolkit.

If all we wanted is a random cross-platform canvas element to draw onto from a vm, it could be solved in a weekend. There are million examples of that.

Java is as open-source as it gets (it’s reference implementation, OpenJDK, has the same license as the linux kernel)

And it was used by some browsers, there was just no consensus between different vendors due to politics. The problem largely solved itself by.. only one vendor remaining, chromium.

Completely ordinary setup, as is, both arch and nixos.