D4ckard

> The worst part about uninitialized variables is that they frequently are zero and things seem to work until you change something else that previously happened to use the same memory.

This is not the whole story. You're making it sound like uninitialized variables _have_ a value but you can't be sure which one. This is not the case. Uninitialized variables don't have a value at all! [1] has a good example that shows how the intuition of "has a value but we don't know which" is wrong:

  use std::mem;
  
  fn always_returns_true(x: u8) -> bool {
      x < 120 || x == 120 || x > 120
  }
  
  fn main() {
      let x: u8 = unsafe { mem::MaybeUninit::uninit().assume_init() };
      assert!(always_returns_true(x));
  }

If you assume an uninitialized variable has a value (but you don't know which) this program should run to completion without issue. But this is not the case. From the compiler's point of view, x doesn't have a value at all and so it may choose to unconditionally return false. This is weird but it's the way things are.

It's a Rust example but the same can happen in C/C++. In [2], the compiler turned a sanitization routine in Chromium into a no-op because they had accidentally introduced UB.

[1]: https://www.ralfj.de/blog/2019/07/14/uninit.html

[2]: https://issuetracker.google.com/issues/42402087?pli=1

I agree that zero-initializing doesn't really help avoid incorrect values (which is what the author focuses on) but at least you don't have UB. This is the main selling point IMO.

You can do lot's of the same things in C too, as the author mentions, without too much pain. See for example [1] and [2] on arena allocators (which can be used exactly as the temporary allocator mentioned in the post) and on accepting that the C standard library is fundamentally broken.

From what I can tell, the only significant difference between C and Odin mentioned in the post is that Odin zero-initializes everything whereas C doesn't. This is a fundamental limitation of C but you can alleviate the pain a bit by writing better primitives for yourself. I.e., you write your own allocators and other fundamental APIs and make them zero-initialize everything.

So one of the big issues with C is really just that the standard library is terrible (or, rather, terribly dated) and that there is no drop-in replacement (like in Odin or Rust where the standard library seems well-designed). I think if someone came along and wrote a new C library that incorporates these design trends for low-level languages, a lot of people would be pretty happy.

[1]: https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...

[2]: https://nullprogram.com/blog/2023/10/08/

The text column is very thin on pages like the IPv6 address generator. The spacing between the lines also seems too high (reminds me of school essays where for some reason you always had to put tons of space between lines). Maybe consider decreasing the space a little bit for readability.

I don't get why people want the AI right in their editor. In another windows inside the editor, fine, but not inline with code I'm writing. It's super distracting to have AI auto complete pop up at random all the time. As always, typing speed, or speed at generating raw code, is not the bottleneck in programming. The crux remains design, in which case having the LLM on the side is just fine (if you use it for that).

There are some niceties about inline completion (like spelling out a log message that's obvious from the surrounding code) but I don't get the hype much beyond that.

Maybe I'm missing some feature though ...

I love MBR hacking, it's so fun to see. Cf. sector lisp [1] and OSle [2].

[1]: https://github.com/jart/sectorlisp

[2]: https://news.ycombinator.com/item?id=43866585

This is a great series of posts which have inspired me to write a debugger when they were posted here before. Very fun! This is another insightful series of the topic: https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-...

Yes, there are really cool packing techniques. See this talk for example: https://www.youtube.com/watch?v=kPR8h4-qZdk

I don't include the null-terminator because I use this type in my own environment where I never use null-terminated strings so there is no need for it.

Read his other stuff, it’s rather well thought out. The assumption is you don’t use libc or at least you use different interfaces to it.

I’d really like to see a full C implementation of this interface. Remove all the C++ complexity in the back end

I don’t get why people use (or used) CGI programs for web servers. This seems crazy inefficient and prone to break

Yes, you can do that too

I got the error as well on the first load. Reload fixed it.

There's a great talk by Evan Czaplicki [0] that outlines the financial significance of browsers. It helps make sense of why Microsoft (and Apple) act(s) in this way.

[0]: https://www.youtube.com/watch?v=XZ3w_jec1v8

  Location: Northern Germany
  Remote: Possibly; I'd prefer to work in person
  Willing to relocate: Yes
  Technologies: C, Rust, (some) Haskell, UNIX Shell
  Résumé/CV: https://drive.proton.me/urls/4AEW15FMVM#amFzaHXAgqb6
  Email: thassilo.schulze (at) proton.me

I'm an aspiring developer, into programming languages and DevTools. Last year, I built a C debugger from scratch, and recently I've been programming in Haskell a lot. I will graduate from German high school this spring, and I'm looking for internship opportunities.

Daniel Lemire has an interesting talk on this: https://www.youtube.com/watch?v=wlvKAT7SZIQ. They key takeaway is that the disk is rarely the bottleneck.

Thanks for your kind words, and also thanks for the link : D

Scheme doesn't work well for very low-level code, and C doesn't handle processing source code very well. For that I'd rather use a functional language. Also, I like using different programming languages (though not necessarily in the same project).

Yes. Anyone who is interested in this topic should read it.

There are definitely many people who almost exclusively spend their time consuming stuff at a young age. I cannot tell however, if that has ever been different, or if it's just perceived differently now. For many people continue consuming a lot their entire lives. The quality of the content one can consume has likely gone up though, or at least it has become addictive.

The idea of only watching saddens me. Doing any creative work is incredibly satisfying, and I think has positive effects on long-term happiness and self-worth.

Yeah, I don't think so. It's x86_64 only, and C only too. Some points from your list make sense now, but most of it is simply not part of Spray's scope, and never has been ...

Thanks the links : D

Oh, I just noticed some bugs in the code while using Motes the other day. Expect some weirdness with the Emacs plugin. The scripts have been working flawlessly for me the past few weeks though. I hope you like them :D

Wow, this sounds great. Please hit me up at any time if you have questions about the code. I left behind comments most places, but I don't know if all of them are helpful.

Thank you for the link. I'm always looking for books on compilers, but they can be hard to find. Many of them are every from the ivory tower-like unfortunately.

I started off learning Python and C++. At some point I got fed up with C++ and switched to C.

Haha, the emoji thing was something I was doing for about a week or so. You see emojis used a lot more around Rust I guess. I never bothered to remove them. I think the bugs around the PID are fun. The ones in the comments might go at some point, though I didn't experience any problems with editors (Helix, Emacs, and VSCode all work) so far.

Should I maybe disabled printing emojis to standard output in the REPL if terminal colors are disabled as well?

It's mostly books and blogs: I like to read a lot. Also, your guess is correct, my dad is a computer scientist.

Thanks for pointing me to those projects! I didn't know about any of them.