Who knows if this is the reason that Trump is putting in place this trade war and increasing tariffs, but this paper is a very interesting perspective on why someone in the position the US is in, in regards to the global economy is extremely thought provoking [1].
Seeing as how Trump appointed the author into his political circle though could be evidence this is the ultimate goal.
The paper is quite lengthy, however, in the beginning Stephen explains this idea of the Triffin Dilemma. A country that acts as the worlds reserve currency and thus creates enormous demand for their currency for things outside of goods are at a disadvantage that exasperate their trade deficit. This is implicit for a countries currency where most global trade is settled in their dollars, not to mention the benefits of holding the world reserve currency as a value store or investment.
I've wondered since the tarifs were announced how much impact they can actually have, but besides that point what is a reserve currency country to do? Give up their reserve currency status? There are significant downsides to that as well...
Well isn't that the whole point? At a fundamental level, investment profits are a payment for the risk you take. No risk equals no profit. There are "safe" investments currently. You can get paid 4% a year roughly to hold treasuries right now. Considered a "risk free" investment (Which sure, maybe the merits can be argued).
But at the end of the day the only way to profit from an investment is taking some risk. It all comes down to pricing that risk.
Does this mean it's impossible in Zig to do strictly Stack related recursion and just by the mere inclusion of a recursive function your implicitly getting heap allocations alongside?
You can put a big buffer on the stack, and use this buffer to break your cycles. At some point you'll run out of this buffer and be forced to handle failure, rather than triggering a stack overflow segfault.
So it will be the same thing but with more (error handling) steps.
This annoyance can be avoided by avoiding recursion. Where recursion is useful, it can be done, you just have to handle failure properly, and then you'll have safety against stack overflow.
Wait, so how do I write mutually recursive functions, say for a parser? Do I have to manually do the recursion myself, and stick everything in one big uber-function?
What is the value proposition for these form libraries? Is it scale? Is it the custom builder? How complex are people's HTML forms these days from a UX perspective?
I was browsing the code, and noticed this forms library was using Supabase, presumably a paid service if this OSS library takes off. I just can't seem to grasp why a custom form building library needs a 3rd party, managed Database included. Scale maybe?
These are genuine questions as I'm woefully unaware of the state of HTML forms / Frontend in 2025
There's a few reasons. The biggest one, IMO, is that it lets non-technical users change things quickly without having to go through the engineering team. Obviously there are limits to that, but in many cases, a product or marketing team wants to modify a form or test a few variations without having to put it into a backlog, wait for engineers to size it, wait for an upcoming sprint, then wait another two weeks for it to get completed and deployed. (Even in more nimble organizations, cutting out the handoff to engineering saves time, eliminates communication issues, and frees up the engineering team to do more valuable work.)
On the technical side, these form builders can actually save a decent amount of development effort. Sure, it's easy to build a basic HTML form, but once you start factoring in things like validation, animations, transitions, conditional routing, error handling, localization, accessibility, and tricky UI like date pickers and fancy dropdowns, making a really polished form is actually a lot of work. You either have to cobble together a bunch of third-party libraries and try to make them play nicely together, or you end up building your own reusable, extensible, modular form library.
It's one of those projects that sounds simple, but scope creep is almost inevitable. Instead of spending your time building things that actually make money, you're spending time on your form library because suddenly you have to show different questions on the next screen based on previous responses. Or you have to handle right-to-left languages like Arabic, and it's not working in Safari on iOS. Or your predecessor failed to do any due diligence before deciding to use a datepicker widget that was maintained by some random guy at a web agency in the Midwest that went out of business five years ago, and now you have to fork it because there's a bug that's impacting your company's biggest client.
Or, instead of all that, you could just pay Typeform a fraction of the salary for one engineer and never have to think about those things ever again.
Super interesting project! I have zero experience writing Postgres extensions, but I was browsing a blog post about an extension the other day. I was curious what ones workflow looked like while developing a PG extension. From the little I read, it looked like you would have to recompile postgres, including your extension, then enable it just to run it. Seems like a very long feedback loop. Was I missing something?
You don't need to recompile it actually! It's enough to compile your extension and Postgres can then dynamically link to it, which makes for a perfectly good feedback loop. pgfdb is built with pgrx: https://github.com/pgcentralfoundation/pgrx, which is a framework for building Postgres extensions in Rust that handles all the compiling and linking for you. Highly recommend that if you want to try writing extensions and are also a fan of Rust!
Is there a DBMS or storage engine intended for a DBMS that does bypass the filesystem altogether? I'm not aware of any, but at the same time I don't have a full grasp of all the storage engines offered.
It almost seems like a ridiculous idea to me for a database component author to want to write there own filesystem instead of improving their DB feature set. I hear the gripes in this thread about filesystems, but they almost sound service level user issues, not deeper technical issues. What I mean by that, is the I/O strategies I've seen from the few open source storage engines i've looked at don't at all seem hindered by the filesystem abstractions that are currently offered. I don't know what a DBMS has to gain from different filesystem abstractions.
There are DBMSes that do their own thing -- superficial chatgpt queries seem to result in a few, but I'll not mention them because I don't know much about their internals. I can think of a few reasons, mostly related to wanting to have more control over how physical media is used. I don't see those arguments made here though.
This paper may be a good read: https://dl.acm.org/doi/10.1145/3341301.3359656 -- it lays down arguments for why not to build a distributed filesystem on top of a regular local filesystem, and some of those arguments could apply to DBMS'es.
It's a choice. tmux uses the "alternate screen" capability, the same way editors like "vi" do, which (according to man tmux): "preserves the contents of the window when an interactive application starts and restores it on exit, so that any output visible before the application starts reappears unchanged after it exits."
To change that behavior, put the following in your tmux.conf:
set -g terminal-overrides '*:smcup@:rmcup@'
set -g status off
I have been wrestling with having to enter scroll mode for so long now. It's so infuriating. It works without configurations on iTerm, but does not work on a single other terminal emulator I've tried.
I just tried your config setting in Ghostty and still, when I use my mouse it scrolls through zsh history, not the screen
Being an advanced scuba diver is absolutely no indication of one’s ability to freedive. You Absolutly can not compare the two besides both taking place underwater.
On top of that, even if this guide was a Divemaster which is far from guaranteed given the other safety failings from this company, being an advanced Divemaster does not equate to one’s ability to cave dive. Survivors state the lack of lighting in the boat and so I’m assuming he would have had to navigate the boat in complete dark under water. So while not exactly cave diving, it’s equatable. An activity that’s insanely dangerous to anyone, even Divemasters that don’t have cavern or cave experience.
There’s a reason there’s a grim reaper sign at the entrance of caves in popular dive locations.
The Egyptian dive guides are often pretty good freedivers, especially when they started out as boat boys, they often freedive every day to fasten ropes to the reef.
Still, deciding that the guide should not try does not even make sense if there was only a 5% chance he'd make it, from the two tourists point of view.
Seriously