wasmperson

Its their time to spend as they see fit.

I'm complaining on these developers' behalf, not bemoaning them doing what they were more or less forced to do. If glibc decided tomorrow to remove the `malloc` function from their library and every C project suddenly had to implement its own allocator, that would be a massive waste of everybody's time, no?

If you're curious, and you too aren't in love with the "Modern frontend" philosophy

I'm also going to hesitantly mention sveltekit. From the outside it looks like yet another JS front-end framework but having been forced to use it recently I've learned it actually has great support for the more hypertext-focused design philosophy promoted by HTMX and friends.

Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal:

- Effort spent writing sway that could have been spent improving i3

- Effort spent writing GNOME-Wayland that could have been spent improving GNOME

- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)

- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors

- Wine/Proton devs needing to waste time getting every windows application to work in Wayland

- Firefox needing to target both Wayland and X

- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort

- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)

What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.

I indeed did not know about this. There seem to be some caveats:

https://anubis.techaro.lol/docs/admin/configuration/challeng...

I guess for the meta refresh challenge it's less "proof of work" and more "proof of patience".

It's somewhat interesting to see the FSF's approach to this. From what I understand they can't really use something like anubis since they want their websites to be accessible without javascript:

https://www.gnu.org/philosophy/javascript-trap.html

Users can't consent to running a page's javascript the way they can consent to running a program they've intentionally downloaded, so it's effectively "non-free" regardless of license.

but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere

  function initWidget(root){
    // Or a bunch of calls to document.createElement, whatever you want.
    const inp = root.querySelector('.input');
    const check = root.querySelector('.check');

    function update(){
      inp.style.display = check.checked ? 'none' : 'block';
    }
    check.onchange = update;
  }

  function initWidget(root){
    // Or a bunch of calls to document.createElement, whatever you want.
    const inp = root.querySelector('.input');
    const check = root.querySelector('.check');
    const check2 = root.querySelector('.check2');

    function update(){
      inp.style.display = check.checked && !check2.checked ? 'none' : 'block';
    }
    check.onchange = update;
    check2.onchange = update;
  }

  function Widget(){
    const [check1, setCheck1] = useState(false);
    const [check2, setCheck2] = useState(false);

    return <>
      <input type="checkbox"
        checked={check1} onChange={e => setCheck1(e.target.checked)}/>
      <input type="checkbox"
        checked={check2} onChange={e => setCheck2(e.target.checked)}/>
      {check1 && !check2 && <input type="text" />}
    </>;
  }

  <script>
    let check1 = $state(false);
    let check2 = $state(false);
  </script>

  <input type="checkbox" bind:checked={check1}>
  <input type="checkbox" bind:checked={check2}>
  {#if check1 && !check2}
    <input type="text">
  {/if}

Agreed. IME the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage.

The perf argument against RAII is very abstract and is less "RAII causes bad performance" and more "the kind of design that leads you to reach for RAII is the kind of design that's bad for performance." There exist similar hand-wavy arguments against many other C++/Rust features.

More generally, "you shouldn't even want that" is basically a meme at this point in programming language design. Every new-ish language has some version of it.

Thinking of it as a "stopping condition" is backwards, that part of the loop is called the invariant:

https://en.wikipedia.org/wiki/Loop_invariant

You should think of it as the condition that's true for all iterations, not a one-time event that halts the loop. The loop is short for this:

  for(size_t i = size - 1; 0 <= i && i < size; i--){
  
  }

without having to do any sudo commands or expose anything new to the network.

Again I'm not understanding the distinction. I don't need to run sudo commands to install a web server, and depending on your definition of "exposing something new" to the network then either I don't have to do that either or your solution also does that.

Something is getting downloaded and run on the remote machine, correct? Why is it problematic for that something to be a web server (with SSH-forwarding I guess) instead of this custom thing?

And why install anything on the server at all if it'll just serve a binary that downloads and runs on your local computer anyway? For example, if I type `sftp://username@server.domain/file/path` into my file manager's address bar, I get the nice file browsing experience you demonstrate without installing anything on my computer or the server.

EDIT: OK, after reading through your earlier posts, I think the value proposition really is just that you've implemented a slightly better UX for proxying remote web servers via ssh, and that the "run native code" thing is an independent idea you are also pursuing. So the answer to the question "isn't this just proxying an http server over ssh" is basically yes.

I think I incorrectly read this as attempting to propose a radically new idea and not as an incremental improvement to the status quo.

it requires exposing a port to the internet or using some SSH port forwarding tool

This sentence is bizarre to me. Your SSH-based solution also requires exposing a port to the internet and installing a special tool (on both server and client!). What's so special about SSH that using HTTPS is a problem but using SSH isn't?

The industry also tried the whole "use the web browser to run native binaries" thing with ActiveX (and the unity web player I guess). The idea was thrown out along with flash and java applets for what I presume were security and portability reasons.

In gamedev, "optimistic updates" are called "client-side prediction," and are a standard part of multiplayer games. IMO it's somewhat risky to apply the technique to web-apps, since each network request typically corresponds to some important operation, and optimistically updating the UI is lying to the user about whether that operation completed successfully.

IMO a good approach is to update the UI immediately but still show some indication that the operation hasn't completed. So in a chat app, for example, add the message to the list of messages, but with contrast reduced slightly to indicate that other people can't see it yet.

Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.

It matters in single-pass compilers. You can't allocate a variable in a register if its address is ever taken, but by the time a single-pass compiler knows that information it has already spit out all of the assembly for the function.

This article is about async/await.

It is not. It tries to address async/await part-way through, but it does so without the context of 10 years of successful async/await usage in javascript, the language it's criticizing.

Threads do solve this problem because they are just regular functions being called by other regular functions. They don't require the entire function stack to be `async` in order to work.

This is fixating on syntax: it would be trivial for all functions to simply be `async` by default and for all calls to an `async` function to automatically `await`. This might "fix" the coloring problem as you describe it but I argue wouldn't meaningfully change anything.

IMO the function coloring problem was solved with async/await. This article was posted before Javascript's async/await syntax cleaned up that ecosystem, so the author is only guessing when they say it doesn't fix the issue. It did fix the issue, and now function coloring isn't really a problem.

If async/await doesn't solve the coloring problem, then neither do threads. Why would you ever need to start a thread to invoke a function when you could just invoke the function directly? Because the function is a red function.

Rust's memory safety is as much a social convention as it is a language feature. The language has something better described as "mutation safety," and it's the job of library developers to use that to design UB-free APIs.

I think many people understand this subconsciously, and that this is what drives some of the more performative security culture in Rust spaces (superfluous safety comments, shunning of certain crate authors, `forbid(unsafe)`, push-back against syntax sugar, etc.).

C folks still think is a portable Assembly

C [community] wants to still code

many still don't know to distinguish

the culture that... despite easy proof that isn't the case

devs wrongly assume

self inflicted complexity

considered an advantage when argued by C folks

when the same crowd points

as the C crowd pretends it to be

You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.

Specifically addressing the "almost no ceremony" claim and not the "totally worth it" claim:

JS:

  let person_1 = { };
  let person_2 = { parent: person_1 };
  person_1.child = person_2;

  use std::cell::Cell;
  struct Person<'a> {
      parent: Option<&'a Person<'a>>,
      child: Cell<Option<&'a Person<'a>>>
  }

  let person_1 = Person {
      parent: None,
      child: Cell::new(None)
  };
    
  let person_2 = Person {
      parent: Some(&person_1),
      child: Cell::new(None)
  };
    
  person_1.child.set(Some(&person_2));

WHY javascript code is even allowed to see all these actions of the user?

scrolling: used by games, maps, image viewers

link navigation: used for client-side routing (youtube/twitch, any website with a chat window)

text selection and copy/paste: word processors, spreadsheet editors, forum software, etc.

I'm not sure if your question was sincere or if you were trying to say that the web should not support these use cases.

Ludum Dare 59 just wrapped up last week, and both first and second place were won by developers using "Agentic" coding tools, something the community there is still discussing:

https://ldjam.com/events/ludum-dare/59/setidream/about-ai-ar...

For what it's worth, the non-AI-coded entries were still quite good relative to the winners, so it's not so obvious that AI use confers an unbeatable advantage.

Bots are usually very stupid and will bail on any captcha system they don't recognize, so anything you make that's custom and requires javascript will cull 99% of them. This may change at some point with LLMs but for now my websites at least are still holding strong.

Most "web fork" ideas try to either ditch the web as a sandboxed application distribution platform or to ditch the web as a hypertext-based front-end for networked systems. IMO a good from-first-principles solution wouldn't abandon one or the other but instead split them into discrete components. I suspect this would simplify things a lot vs. the HTML/CSS/JS status quo.

We kinda sorta almost had that for a short period with Flash (and Java, I guess): a webpage either didn't use flash and was secure and efficient like opening a document, or it did use flash and was featureful and interactive like an application. Users and system administrators could block Flash or enable it conditionally while expecting most of the web to continue to work, which in hindsight was actually pretty nice from a security perspective.

It's been a while but from what I remember the easiest way to block this was by disallowing outbound network requests from search/the start menu in the firewall settings. It worked across all versions of Windows I tried it on.

I mean 99.9% of the problems can be averted by just not installing some random new aur package with 0 votes or popularity.

Piracy websites use a similar system. It's not nothing, but it's not enough for me to install pirated software.

How is that an unacceptable threat model for a repo of packages that are optional and user-made? One that clearly says, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." (1)

The AUR is an official part of Arch Linux. It's hosted on the archlinux.org domain with a prominent link to it from the main page. You enable package installation from it either using one of the many transparent pacman wrappers recommended in arch community spaces and on the arch wiki, or by ticking a checkbox in a graphical package manager like pamac. IMO a one-line disclaimer on the aur main page doesn't fix the problem at all.

Security isn't about the trustworthiness of the code you're running, it's about the trustworthiness of the person who's giving you the code. No matter how good you are at auditing bash scripts, there's a malicious bash script that will slip by you, even if you're diligent (which most aren't, even among so-called "power users"). With official packages, I have to trust the people who distribute my OS. With vendor-distributed software (Windows software, PPA, curl | sh) I have to trust the person who wrote the software. With the AUR, I have to trust the first person to park the name of the package.

"End-users need to read and understand shell scripts to make sure they're safe" is a completely unacceptable threat model. The way I see it installing software from the AUR is about as safe as installing software from the pirate bay. Nevertheless, this distribution keeps getting discussed and recommended to people, with the AUR often cited as a reason to use it.

I think the biggest problem is that the DOM was built for documents, not apps.

The world wide web was invented in 1989, Javascript was released in 1995, and the term "web application" was coined in 1999. In other words: the web has been an application platform for most of its existence. It's wrong to say at this point that any part of it was primarily designed to serve documents, unless you completely ignore all of the design work that has happened for the past 25 years.

Now, whether it was designed well is another issue...

Instead of slow React renders (50ms?), every interaction is a client-server round trip.

This is true only if you use zero javascript, which isn't what the article is advocating for (and even with zero javascript there's quite a bit of client-side interactivity built-in to CSS and HTML). Besides: in practice most interactions in an SPA also involve network round trips, in addition to that slow react render.

The idea that it does nothing is a persistent myth. Both GCC and Clang heed it although neither treats it as a mandate:

https://tartanllama.xyz/posts/inline-hints/

This library seems to have the annotation on every function, though, so it's possible the author is just following a convention of always using it for functions defined in header files (it'd be required if the functions weren't declared `static`).

I was reminded of this website by the recent slinging.org discussion:

https://news.ycombinator.com/item?id=46951430