rom-antics

I agree. I gave Zig a fair shake, even went so far as to find the compiler PR that automatically adds `_ = foo` to your source code while compiling[1] and set up the VSCode extension with autofix. I couldn't get used to seeing the lines with `_ =` appear and disappear all over my code while I was typing.

With the usual warnings approach, you can rely on compiler/IDE/pre-commit tooling to find unused variables - they'll all nag you until it's fixed. With Zig's autofix approach, those problems are immediately silenced and you don't have any help from the compiler or tooling to find unused variables. It's quite an ironic outcome if you think about it.

[1] https://github.com/ziglang/zig/pull/12803

Yvette and Ling would be perfect for each other. https://www.lingscars.com/

I've been wondering lately whether a new spatial approach can yet again simplify matters.

I've been closely following the development of Vale since I first saw it here. Though their approach is slightly higher-level than Rust and requires (some) runtime safety checks (though to be fair, so does GC).

https://vale.dev/

https://verdagon.dev/blog/zero-cost-memory-safety-regions-ov...

I think it would be tough to change the spatial model in a language as low-level as Rust, because that spatial model is just reflecting how your CPU actually works under the hood. If you try to hide that away, the programmer is going to end up losing some control.

On the other hand though, it brings symmetry to types and values, and makes destructuring feel natural.

  let i: i32 = 1;
  let &i: &i32 = &1;
  let &mut i: &mut i32 = &mut 1;
  let (i, &mut j): (i32, &mut i32) = (1, &mut 2);

When I was a kid I had a toy electronics kit and one of the circuits was an AM radio that worked without batteries. A normal radio station signal is strong enough to drive a pair of earbuds without any additional power. Since then I've always wondered if you could harvest that same radio energy to power other things without batteries, maybe even a Game Boy. There's electromagnetic radiation in the air all around us. And I'm sure you could build a Game Boy using today's tech that's much more power efficient than the ones from the 90s.

You mean due process? Sounds great, sign me up!

If you want compact, use an array of tuples:

  const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...];
  for (str1, num, str2) in &foos {
      // ...
  }

This is megabytes (at most) of text we're talking about, not gigabytes. And ripgrep is absurdly fast. Grepping a 5MB text file should be pretty much instantaneous.

discord has a search feature, but it’s pretty awful

Their search makes me want to pull my hair out.

Why can't I just search the history with grep? That's a feature I would pay for (if anyone at Discord is reading this and wants my $10/month)

I can't say I'm impressed.

https://i.imgur.com/Iq9DcSY.png

How about a nice game of chess?

Well that's a loaded title. (EDIT: The article title, not the changed HN title)

Another take:

https://www.eff.org/deeplinks/2022/02/enforcement-overreach-...

Read the section on Trusted Flaggers to find out what that word "safer" really means.

we are not yet at the point where a voice can be mimicked accurately from a voicemail or a clip on social media

See: https://www.thestar.com/business/technology/2023/01/10/micro...

Microsoft’s new AI can mimic any voice after just 3 seconds

Play the result over a low-bandwidth PTSN line and it could probably fool people in tech, let alone your grandma. Welcome to the future.

The word "fraud" has really lost its punch these last couple years. OpenAI has actual, working products that people think are valuable enough to pay for. The name is misleading, sure, but that doesn't make them a fraudulent company.

Is there a word for the opposite of the euphemism treadmill, where people call ordinary things by worse and worse names trying to get an emotional reaction out of people?

I don't see a video in either article. Link?

That article doesn't support the headline. The closest it gets is saying nobody asked her beforehand, but she doesn't say after the fact that she wants people to stop.

Meanwhile, from the people who actually bothered to talk to her[1]:

In her view, the photograph is an immense accomplishment that just happened to take on a life of its own. “I’m really proud of that picture,” she said.

This whole situation reminds me of GitHub, Fuck Your Name Change[2]. People want to drum up outrage and don't care one bit about the people involved.

Is it really worth erasing a piece of computing history because of some kids virtue signaling about a picture that was taken before they were born?

[1] https://www.wired.com/story/finding-lena-the-patron-saint-of...

[2] https://mooseyanon.medium.com/github-f-ck-your-name-change-d...

In this case it was one of the founders of the company. If you can't trust the founders, who can you trust?

You forgot:

0. Get elected to Congress

I love that there are so many options that people disagree about which is best. THAT is probably the worst thing that can happen to OpenAI - not just one competitor, but a whole heap of them.

I wouldn't call codegen adversarial. The optimizer isn't out to get you. It emits the best code it can given a certain set of assumptions. It may just seem adversarial at times because the output can behave in unintuitive ways if you break those assumptions.

I don't believe PROT_NONE suffices. The address needs to be accessible, not merely mapped. If reading through a pointer, the address must be readable. If writing through a pointer, the address must be writeable. This is why writing to a string constant is undefined behavior, even though reading would be fine.

Another issue is alignment. If you read from a `*const i32` with unaligned pointer value 0x2, the optimizer is free to assume that code path is unreachable and, you guessed it, bulldoze your house. If you get a segfault from reading an `i32` from address 0x2, you've already hit UB and spun the roulette wheel.

In theory the emitted code could check pointers for alignment and validity (in whatever platform-specific way) before accessing them, and simulate a segfault if not. Such checks would serve as optimization barriers in LLVM, and prevent these instances of UB. Of course Zig's current ReleaseSafe doesn't do this, and I think it would be silly if it did. But that's the only way you could accurately call segfaults "well-defined".

Lightsail are among the worst when it comes to actual benchmarks. Though you might not notice if your apps aren't very resource demanding.

Their fastest instance type is still in the bottom ~15% of this list for example: https://www.vpsbenchmarks.com/screener

Maybe if we stopped looking down on people because of the color of their collar, we wouldn't be having these problems. Just a thought.

I'm claiming that if a program is compiled with LLVM, it must follow must LLVM's rules. One of those rules is that a pointer must be valid in order to be dereferenced. If a program attempts to dereference an invalid pointer and segfaults, it has broken those rules* and thus exhibited undefined behavior. While undefined behavior MAY result in a segfault, it's equally valid for the program to continue running with corrupted state and wipe your hard disk in a background thread.

I'm not sure how I can connect the dots any more clearly. Like gggggp said, it's baffling to see the creator of a popular language sweep the nasal demons under the rug and pretend that certain undefined behavior is guaranteed.

Calling such segfaults "safe" or "well-defined" is setting your users up for disappointment and CVEs, because a "well-defined" result is axiomatically impossible in the presence of undefined behavior. It's subtle, and if we were talking about a Java competitor maybe I could forgive the mistake. But if you're writing a low-level language it's important to understand how this stuff works. Ironically, he spread misinformation in the very post where he accused Rust evangelists of the same.

This thread is long dead and continuing the discussion seems futile, so I'll just leave it at that.

*excluding something silly like `raise(SIGSEGV)`

I don't think 0x2 is a valid pointer either. The docs say the pointer value must be "associated with address ranges allocated through mechanisms..." - to me the word "allocated" means it's the result of an allocation, pointing at usable address space. (Sorry, I know this is a purely semantic argument. Debating the meaning of words does not make for very interesting discussion.)

In Rust for example, derefencing a raw pointer is unsafe - because that pointer could have a value of 0x2 - which would result in undefined behavior according to LLVM.

tbh I'm surprised any of this is even up for debate. If you google "is segfault undefined behavior" you'll get 100 results telling you yes, yes it is.

From the same section,

- Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined.

- A null pointer in the default address-space is associated with no address.

A null pointer (0x0) is associated with no address, therefore it has no address range. So if you do attempt a memory access (dereference), the behavior is undefined. QED. A naive translation to assembly would indeed segfault on a modern OS, but LLVM's optimizations are free to assume that code path is unreachable and do anything else.

Once the program is in this state, a bug of some kind is unavoidable. I don't take issue with that - what I take issue with is your claim that this behavior is well-defined, because it definitely is not. It would be equally valid for a null dereference to corrupt your program state or wipe your hard disk.

Is not one of the LLVM rules, pointers must be valid and have a valid provenance in order to be dereferenced? If 0x2 ends up in a pointer that is dereferenced (or 0x0 in a nonnull pointer), has that rule not been broken? And if the rule is broken, does that not trigger undefined behavior?

I'm sure he can spare some of his 19876 internet points, just say it FSS

I know Zig is not C, that's why I specifically mentioned LLVM. It's fine if Zig has different opinions about UB than LLVM does, but in that case ReleaseSafe builds should not use LLVM, not even optionally. If Zig says some operation is defined, but LLVM says it's undefined, well, LLVM is the one optimizing code so it's LLVM's invariants that matter. Right now it looks like Zig is playing fast and loose with correctness, shoving everything through LLVM but not respecting LLVM's invariants. And hey, if something is observed to segfault under some conditions today on the current version of LLVM, we'll just say segfaults are guaranteed. It's disappointing to see.

That's a guarantee on the level of the hardware/OS, but hardware semantics are not the same as language/compiler semantics. Even if according to the source code you're dereferencing a pointer value 0x0 or 0x2, that doesn't mean the compiler-emitted machine code will end up telling the hardware to do the same.

Remember this gem?

https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

Once you trigger UB, all bets are off and your code could do anything. A segfault just means you spun the roulette wheel, bet it all on red, and got lucky your house wasn't bulldozed.

Zig also uses LLVM under the hood, right? So it's subject to these same semantics. An LLVM pointer value cannot legally contain arbitrary non-null non-pointer integers such as 0x2. That's a dead giveaway of UB. And I doubt the emitted Zig code safety-checks every pointer dereference for a value less than 0x1000 before performing the dereference.

What is the threat model you're worried about? If an attacker can write data to your disk or authenticate to your cluster, aren't you already screwed?