An example of failing to follow DoD is the N+1 query problem: a programmer builds an abstraction that operates on individual DB rows, but "where there's one, there's more than one": you will inevitably be running that code in a loop so that you can process multiple rows. If instead the programmer had abstracted over groups of rows, then per-item query overheads suddenly become per-batch overheads.

  use std::panic::catch_unwind;
  fn throws_exception(){
      panic!("hello");
  }
  fn main(){
      match catch_unwind(|| {
          throws_exception();
          println!("Never reached");
      }) {
          Ok(_) => (),
          Err(e) => println!(
              "threw an exception: {:?}",
              e.downcast_ref::<&'static str>().unwrap())
      }
  }

Again: I'm not disputing the fact that the rust index operator does a dynamic bounds check.

https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...

  for i in some_arr {
    println!("{i}");
  }

That's the thing, though. Your Fil-C code isn't calling mmap, it's calling the Fil-C wrapper for mmap. In neither Fil-C nor Rust('s safe subset) can you call the actual system mmap.

Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it.

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?

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.

- 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.

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".

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.

  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 <>
       setCheck1(e.target.checked)}/>
       setCheck2(e.target.checked)}/>
      {check1 && !check2 && }
    ;
  }

  

  
  
  {#if check1 && !check2}
    
  {/if}

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.

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--){
  
  }

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.

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.