lokeg

Isn't working with the utf8 stream sufficient? Especially if you only have ASCII keywords/operators/brackets, I feel a ASCII parser should work with utf8 out of the box

There is a somewhat famous post about this:

https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_hav...

Essentially stating that Linux users disproportionately care to actually report bugs they encounter rather than ignoring them. I find that very plausible.

This can be alleviated by the gas plant operator selling call options, effectively paying them for being reliable. The relevant keyword is "capacity markets".

What about the worst case? I.e. something like searching for 1000 'a's in a long string of 'a's interspersed with 'b's every 500-1000 steps? Seems accidentally quadradic unfortunately in the absence of some KMP-like fallback

Something like the following? I am trying and failing to reproduce the issue, even with mutable AST nodes.

  use bumpalo::Bump;
  use std::io::Read;
  fn main() {
      let mut arena = Bump::new();
      loop {
          read_and_process_lines(&mut arena);
          arena.reset();
      }
  }
  #[derive(Debug)]
  enum AstNode<'a> {
      Leaf(&'a str),
      Branch {
          line: &'a str,
          meta: usize,
          cons: &'a mut AstNode<'a>
      },
  }
  fn read_and_process_lines(arena: &Bump) {
      let cap = 40;
      let buf: &mut [u8] = arena.alloc_slice_fill_default(cap);
      let l = std::io::stdin().lock().read(buf).expect("reading stdin");
      let content: &str = str::from_utf8(&buf[..l]).unwrap();
      dbg!(content);

      let mut lines = content.lines();
      let mut latest: &mut AstNode<'_> = arena.alloc(AstNode::Leaf(lines.next().unwrap()));
      for line in lines {
          latest = arena.alloc(AstNode::Branch{line, meta:0, cons: latest});
      }
      println!("{latest:?}");
  }

What?

It indeed does not make sense to have a market for carbon sequestration that does not also include fossil fuel emissions.

But implementing a comprehensive cap-and-trade system is superior to a fixed carbon price in that the it directly limits emissions without fiddling with the exact price (which instead is discovered by the market), and therefore can be planned long term.

(What should the carbon price be 2050? That depends on inflation and many other factors, but the allowed net emissions should clearly be zero or negative)

I recommend everyone to take a look at the EU ETS which unfortunately is surprisingly unknown

Skimming this I did not really understand the programming model difference from glommio or tokio-uring. Aside from striving to be cross-platform, how is this significantly different?

I think this is what they call a doomsday cult..

My point is, this would leave you in a really bad position if it turns out after 10 years nothing really happened

The aspect ratio in that fold is 4, the very first step is folding the square down into a ribbon

I am out of the loop, but surely this would be politicized math education? Which is absolutely different from mathematics research and not related to reproducibility.

> It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright.

I would not call this trivial. The code in your post is incorrect. For example, it cannot find "ababc" within "abababc", since after the first mismatch we skip too much of the haystack.

The real solution to this is Knuth-Morris-Pratt, where we must precompute for every index in the needle the longest needle prefix that fits before it. I would not expect your average interviewee to derive or implement this.

An easier linear time solution (in my opinion) is rolling polynomial hashing. But if you actually expect solutions in an interview you should settle for the naive quadratic algorithm.

Using libraries is so much easier in rust compared to many other libraries due to rustdoc. I can trust the type signatures to show me the actual usage, I can trust the code snippets to not be outdated, and above all this is consistent for all code in the entire ecosystem.

Almost always when I use python libraries I have to get used to a new documentation format, learn how to navigate it and so on. And then it has to be detailed enough to make up for the lack of type signatures. I cannot tell you how often I have to skim a significant portion of my dependencies' source just to use them. (Though there are counterexamples, stdlib and numpy in particular actually have okay docs)