jtrueb

The callout about auditing inline and comptime reminds exactly of the C++ point made about how you have to follow the style guide. Whoosh?

Call me crazy, but jj is more confusing than git.

RTOS can be used a lot looser than you describe. Like a build system, scheduling, and interrupt framework that allows you to program an MCU like you describe. Zephyr RTOS and Free RTOS provide easy enough ways to write code that uses blocking APIs but probably runs your code according to the timing constraints if you hold it right. As an alternative, you could write for “bare metal” and handle the control flow, scheduling, interrupting, etc. yourself. If you are writing to “random” addresses according to some datasheet to effect some real world change, you are probably reaching for an RTOS or bare metal unless you are writing OS driversn. If you look at the linux drivers, you will see a lot of similarities to the Zephyr RTOS drivers, but one of them is probably clocking in the MHz while the other in the GHz

I kinda quit using it. The tab feature is useful when making minor or mundane changes, but I quite prefer the codex GUI if I am going to be relatively hands off with agents.

Is there a new version or news related to this? v0.9 was Nov 2024, and Leptos and Dioxus have been a lot more active.

AI-assisted research is a solid A already. If you are doing greenfield then. The horizon is only blocked by the GUI required tooling. Even then, that is a small enough obstruction for most researchers.

Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.

Have you been in a self driving car? There are some quite annoying hiccups, but they are already very safe. I would say safer than the average driver. Defensive driving is the norm. I can think of many times where the car has avoided other dangerous drivers or oblivious pedestrians before I realized why it was taking action.

I don't need nanosecond accuracy. I just know there are a lot of scripts expecting it.

I would describe it as the huge majority, reflecting on my pandas use over the years. Pretty much all of the data worth exploring in pandas over excel, some data gui, or polars involves timestamps.

That timestamp resolution discrepancy is going to cause so many problems

Heard of `#![forbid(unsafe_code)]` ?

simd was one I thought we needed. Then, i started benchmarking using iter with chunks and a nested if statement to check the chunk size. If it was necessary to do more, it was typically time to drop down to asm rather than worry about another layer in between the code and the machine.

I mainly use Rust in embedded now. I don’t always rely on encoding all of the correctness in the Rust type system. To a degree all the old ways of enforcing correctness are still in play, I am just choosing when to take use idiomatic Rust or escape hatch out via shim to C-style Rust. It reminds me quite a bit of how C and C++ shops require another layer of macros or templates be used for containers, resources, etc.

The build time of Zig seems like the most desirable piece worth deciding over. Developer time is money, but it isn’t weird to have multi-hour build times in a mature project either C, C++, or Rust. The correctness suite is a bigger time sink than the build though. When building a database, you could drive the build time to 0 and still have hours in CI.

I was on a team with a similar timeline with C++ (4 year). All the language and toolchain difficulties came after shipping. Meeting new customer needs meant shifting from greenfield to brownfield engineering. We were chasing down strange platform and provider behaviors. Adding features while maintaining performance and correctness, meant relying on knowledge of tools available in the broader community. Solutions for build issues came through a combination of in-house effort and industry partners with related experience. Having two stable compilers (gcc and clang) was super helpful.

Yeah, I think BDFL wants to use Zig. I understand that it is nice for Zig to feel more like C, and that can be fun. If the toolchain is so far away from being mature, how long will it take the database to be mature?

Since previous comment was edited. I would clarify that I don’t doubt the engineering capabilities, just the timeline. A from scratch database in _established_ toolchains take 5-10 years. The Zig toolchain also is going to be evolving in the same timeframe or longer. The codegen, linking, architecture specific bugs etc. Isn’t it double the effort to bring to bear in the market?

The reason for not choosing Rust still doesn't make any sense to me. If you don’t want to OOM, need correctness, are following the power of ten (where you aren’t allocating anyways), I don’t see the conflict or harm of additional enforced correctness.

Also, Rust does support checked arithmetic and has stable toolchains.

Wow!

Slides from video description

https://docs.google.com/presentation/d/1SoDsm_m_pb_gS6Y98Hgh...

Obviously there is a lot of work here, but I am a bit confused. If you already have lab code in Julia, Matlab, R, Python, Excel, etc., what is the motivation to use this tool? Is this hot in a specific community?

That’s if the voltage supply was stable and within electrical specs for a sufficient period of time. We can see this is a snippet 2 hours into the discontinous collection.

3.6V is the maximum value that the nrf52832 SoC can handle. I would suspect the VDD is variable.

A true champion

when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, which further led to improving our CI infrastructure. Then I noticed that we wait quite a long time for our CI workflows, and started optimizing them. Then I started running the Rust Annual Survey, then our GSoC program, then improving our bots, then…

Arc doesn’t give you the choice until this upcasting feature lands in stable.

I agree this is useful. I also think it isn’t the end of the world to support some semblance of OOP in Rust.

If it helps you ship the business logic, sometimes it’s okay to concede some performance or other cost.

Getting closer and closer to OOP

I think that is a bit of an overstatement given the amount of legacy code and bindings generation capabilities. I do think it had to swing towards memory safe and C++ still didn’t have a plan for smart pointers much less move semantics when Swift dev started.

Who knows what present day Objective-C++ could have been if it had been the workhorse language of choice. Maybe this profiles thing Bjarne is pushing could have been in the roadmap. We will never know.

Having worked on the old, the migrating, and the new, I appreciate Swift more than Objective-C mostly due to IDE support.

If they had put the effort into Objective-C++ that they put into Swift, I struggle to imagine it in a worse place than Swift is in these days.

How many years old is your swift codebase?

??? Swift is terrible right now. Language features conflicting, async story migrating, compile issues horrific and IDE support in its infancy.

Since I often use a sliding window, I made a Rust implementation and was surprised with how performant the VecDeque implementation was.

The MidVec was only faster than VecDeque when doing batch inserts and removals with my implementation.

https://gist.github.com/trueb2/9c0a23aa012f56d4c3d50afe8acf6...