I am working on a language that was C with extensions, transpiled to plain C, but the C syntax is kinda not great to work with (stuff like needing type tables and unbounded lookahead). At the point you clean up the syntax, you're not really C with extensions anymore.
Pair programming is a great way to do knowledge sharing and collaborate on tricky problems. Now, I don't really want a multiplayer editor, but I'll highly contest that coding is solely a solo activity.
Sometimes I feel like people online hate all their coworkers. Thankfully, such people have not been highly represented amonst those I've worked with.
Its unfortunate that this is using eBPF and not cBPF. I'd want to enable this in a namespace using binfmt-misc's namespace support, but eBPF requires root.
I don't think they can convince me they have actually reversed course on this. Its invisible so we wouldn't know if they kept on doing it secretly. It required building out technical capability which is unlikely to remain forever unused while conveniently available to them.
They relied on trust that they were providing the service they were being paid for. That trust was blown, and an "oops, lets undo that" does not regain trust. It would be prudent to assume the invisible guardraild are possibly in play for all future Clause use, Fable or otherwise.
C with Zig's comptime is compelling though. Zig doesnt allow you to access all the features your C compiler does, and puts you in the LLVM ecosystem. I've been working on something similar; extending C with both Zig/C++ inspired reflection and linear types, with a compiler that compiles to a subset of C to allow you to leverage GCC and all its extenstions.
More like RIP bun. Wouldn't have paid any attention bun if it weren't for Zig. Now I need to figure out what the "normal" runtime is to switch my work typescript stuff to.
This level of quality is why they have my business. We had a CI setup with rpi boards that needed fans (uart clock tied to cpu clock so heat meant slowing down and the uart dropped characters). I got tired of seeing random test failures on some board and driving up to the office to replace the fan that had failed. And they were loud and annoying. I ended up frustrated and expensing hundreds of dollars of noctua fans. Dead quiet, did a better job, and not even one ever failed on me.
The one problem I have with the trusted files thing is that I have no way to trust non-file-visiting buffers. Why is *scratch* untrusted!? *scratch* should always be trusted, without me having to configure anything, ideally. Though a setting to automatically trust non-file-visiting buffers would be nice.
I just ended up stopping using the scratch buffer because of that issue.
I have the opposite experience. I have no trouble navigating Gnome apps, and now when selecting an application for a task, I'll choose a Gnome or GTK4 one first. Other apps implement odd controls that don't mesh with the rest of the system.
Most of the deadlocks I've faced are with different proccesses/devices both waiting on reads from each end of a socket/uart/etc. I've taken to putting timeouts on read calls, though then you have to deal with legitimate long request cycles timing out.
A pedestrian shouldn't need to be able to hear to be safe from cyclists. Focusing on headphones is ignoring that the same dangers are being imposed on deaf people and people with otherwise bad hearing. If a cyclist needs to use the bell for safety, they should hit the brakes.
These days, I've noticed that lobsters feels a lot more genuine to me, like hn was a few years ago. These days it feels like hn is bland and homogeneous, which I suspect is due to LLM-written comments.
Moving mostly to codeberg was a simpler affair than I expected. It's been a breath of fresh air. Its like github without the gamification, ads, copilot, and social features.
Its for the time being is stuck with LLVM, so I can't currently LTO with GCC objects. Its got a lot higher complexity than I perfer in a language. A lot of features I find important seem perma-unstable. Pin is unnessesarily confusing. No easy way to define multiple compilation units for use with linker object selection and attribute constructor. The easy path is downloading binary toolchains with rustup and not using your disto package manager. You can't use unstable features without the bootstrap env var on distro rust toolchains. Cargo leads to dependency bloat. The std/core crates are prebuilt binaries and bloat binary sizes. Bindgen doesn't translate static inline code. The language has a ton of stuff it exposes just to std and not user code. Unsafe code is unergonomic. No easy way to model a cleanup function that needs more args. No support for returns_twice. No ability to use newer stuff like preserve_none. Can't go-to-definition from a bindgen binding to original header file. Macros pollute global namespace. Can't account for platforms where size_t and uintptr_t are different. Traits can only be relied on if marked unsafe. Can't implement something like defer since it holds a borrow. no_std code still can pull in core::fmt. Can't enforce dependencies are also no_std. Panics are considered safe. No way to add non-function fields to dyn vtables. No way to declare code separately from definition. No way to have duplicate type definitions that merge, making interop between different bindgen generated modules annoying.
Its possible to dislike Rust but pragmatically use it. Personally, I do not like Rust, but it is the best available choice for some work and personal stuff.
I think you are entirely missing the author's point. The author is generalizing from the specific technicalities of C/Rust/etc UB, to the problem with UB which is that should it be triggered, then you can't know what the program will do. This does not have to be the result of language specification. If writing safe Rust yourself, yes no UB will occur usually, and you can know what will happen based off of what code you wrote. The author extends UB to vibecoding where there is no specification to understand the translation of prompts to code. Without thorough review, you are unable to be sure that the output code matches the intent of your prompting, which is analagous to writing code with UB. The issue the author has with vibecoded Rust is not that the code can trigger undefined behavior at the language layer, but that the perfectly "safe" code generated may not at all match the intended semantics.