lytigas

I've read a few small overviews of jj. One thing that's off-putting as a git lover is that while git is truly append-only (except refs), jj seems quite "mutable" by comparison.

Say I'm messing around with the commit that introduced a bug, somewhere deep in the history. With git, it's basically impossible to mess up the repo state. Even if I commit, or commit --amend, my downstream refs still point to the old history. This kind of sucks for making stacked PRs (hello git rebase -i --autosquash --update-refs) but gives me a lot of confidence to mess around in a repo.

With jj, it seems like all I would have to do is forget to "jj new" before some mass find+replace, and now my repo is unfixable. How does jj deal with this scenario?

I was under the impression Waymo was the leader. Who are they behind and how?

A C programmer who doesn't check the validity of pointers passed to functions and subsequently causes a NULL dereference is not a C programmer I want on my team.

I disagree. Interfaces in C need to carefully document their expectations and do exactly that amount of checking, not more. Documentation should replace a strong type system, not runtime checks. Code filled with NULL checks and other defensive maneuvers is far less readable. You could argue for more defensive checking at a library boundary, and this is exactly what the article pushes for: push these checks up.

Security-critical code may be different, but in most cases an accidental NULL dereference is fine and will be caught by tests, sanitizers, or fuzzing.

For a structured approach to ptrace/syscall rewriting, you could try FB's reverie. I worked on and used it during an internship a few years back; it's pretty amazing at what it does.

https://github.com/facebookexperimental/reverie

During the early part of this event, we were unable to update the Service Health Dashboard because the tool we use to post these updates itself uses Cognito, which was impacted by this event.

Poetry.

Then, to be fair:

We have a back-up means of updating the Service Health Dashboard that has minimal service dependencies. While this worked as expected, we encountered several delays during the earlier part of the event in posting to the Service Health Dashboard with this tool, as it is a more manual and less familiar tool for our support operators. To ensure customers were getting timely updates, the support team used the Personal Health Dashboard to notify impacted customers if they were impacted by the service issues.

I'm curious if anyone here actually got one of these.

It's possible the Chromium/Electron thing is this bug[1], which affects new proprietary nvidia drivers on recent Chromium versions. I also experienced that bug, though I don't think it affected Firefox for me.

It resolved itself for me recently in all apps except Slack. I have no idea why. I'm fairly sure I didn't update anything.

While it was still reproducing, I tested a purported fix in the upcoming Chromium 87 (or 88?) and it was resolved. So just wait a bit or try Canary. More specific info in the bug thread of course.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=111304...

According to [1], Crystal Macros "receive AST nodes at compile-time and produce code that is pasted into a program." This is basically the same as Rust procedural macros[2]. You're probably thinking of "Macros by example"[3]

[1] https://crystal-lang.org/reference/syntax_and_semantics/macr...

[2] https://doc.rust-lang.org/reference/procedural-macros.html

[3] https://doc.rust-lang.org/reference/macros-by-example.html

Rust wraps in release mode and traps in debug mode[0][1]. All large projects that I know of ship in release mode. Though I'd be interested to see a source for it not pessimizing badly.

[0] https://play.rust-lang.org/?version=stable&mode=release&edit...

[1] https://github.com/rust-lang/rfcs/pull/560

The field of view of the camera is only 1.5x1.5 degrees[1], roughly 3x the size of the moon viewed from the ground.

[1] "NAR" in the upper left, and https://forums.vrsimulations.com/support/index.php/A/A_Forwa...

Some here are saying "Why not just use Rust/D/Zig/Nim/Crystal if you're going to break backwards compatibility?" I believe the proposal is closer to "We've removed this old feature, run this tool to replace it with the new one." C++ will keep looking like C++, not like Rust. Here's Google's "Codebase Cultivator" explaining the idea for their Abseil library:

https://youtu.be/tISy7EJQPzI?t=2209

I remember watching another talk where they propose something similar for the language itself, but I can't find it at the moment.

There's really no evidence that C++ has a higher performance ceiling. From a broad view, both are compiled with no runtime. More specifically, Rust and C/C++ trade the lead constantly in the language benchmarks game. In some cases, Rust can be faster because it makes stack allocating easier. In others, C++ can be faster because of specialization (which Rust doesn't have yet).

Regardless of what exactly rustc does right now, in the future Rust's strict aliasing rules will basically ensure Rust does this optimization in every possible case, because Rust reasons at compile time to ensure no mutable references ever alias. Things have been held up for a while on this LLVM bug, though[0].

[0] https://github.com/rust-lang/rust/issues/54878

Rust basically has this functionality. Whether a type is borrowed or not dictates what I can do with it. For example, I cannot remove items from a `Vec` with a shared &reference. Thus, without knowing which reference type is used in a trait method, I cannot write generic code; I don't know whether my function must take &T or T.

There might be a way around this limitation, but it makes figuring out who is supposed to free a resource hard to do.

The rust solution is to have different traits for different levels of ownership. For example, if I want to iterate over a vector of strings, I can get a Iterator<&str> without destroying the vector. If I'm willing to destroy it, I can get an Iterator<String>.

Or, you can actually implement a trait on a reference type[0] to convert a `self` argument to effectively `&self`. This is the recommended way to implement some conversions, using AsRef and/or Into[1].

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio... [1] https://doc.rust-lang.org/std/convert/trait.AsRef.html