Anyone can slap a fancy UI on an existing engine and claim they made a browser. So many of them exist now, they don't matter anymore at all. This one will die in the crowd like every other wannabe browser. Build your own goddamn engine and then claim you made a browser, at least the Servo and Ladybird devs are doing some concrete work, not just pointless marketing and empty claims.
It's the opposite, anyone can slap an existing good engine to a bad UI that works well on many sites because it already works for some major browser. Almost no one can slap a fancy UI, and none of these newly sprangeld browsers offer any, they are way closer to the basic fails for Chrome/Firefox where even changing the default keybinds in an exercise in futility, and all the other stuff is similarly bad - for example, in this browser while the have vertical tabs, the 9to5mac example website doesn't fit the tab name and has the … symbol, which is not fancy at all on its own (fancy UI would be something like non-space-wasting fade out instead of text replacement), but also is part of the same low-density-whitespace-wasteful UI nonsense you see everwhere else - while there is enough whitespace in the tabbbar to fit whole ~two next words "...Mac Rumours breaki"
Buying gold and silver to get through the inevitable stock bubble pop is out of reach for normal people with normal wages and savings.
Houses and stocks got cheaper per ounce of gold last 20 years. But in terms of dollars they got way more expensive... inflation has been robbing us for more than 2 decades.
Since 1971. The world economic system became what I term financialism, where money is simply a debt instrument. The Treasury issues a debt note, in exchange for which they receive Fed Notes, and that debt obligation becomes the backing for more loans issued by the Fed to member banks. The Fed Notes handed to banks are then loaned too. Thus, debts in a single sector (if large enough) can crash the entire system.
The issue is, things that are tied to debt will go up first: housing, cars, etc. Stock inflation occurs because inflation forces people to speculate to stay ahead of the inflation rate.
To fix inflation when using a debt based currency, you’d need high interest rates (a high price of money), or you’d need the government to pay off debt which takes money out of circulation. Neither of these will happen as the politicians in power would cause serious short term pain. They all have an incentive to kick the can and hope the next guy is in power when it all falls apart.
What we are seeing now is the result of the price of money having been lower than the inflation rate for over 20 years. Effectively free money. This subtly skews the perception of risk, and therefore increases dollar velocity and drives inflation even higher.
The pain doesn't buy anything but the requisite costs of raising rates and/or cutting spending enough to allow debt pay-down would cause pain. Pain enough to sacrifice legacy, pain enough to sacrifice re-election, and pain enough to hurt lobbyists offering up that sweet lucre.
Sounds like unforgivable overhead for very questionable benefits, this whole LLM space is an overengineered slop, and everyone is jumping in building layers on top of layers of slop.
Slack is such a bloated, slow, piece of crap, every single keystroke gives me pain, that sluggish slow UI response, sometimes there are random unexplained jumps somewhere, no wonder web apps have such a bad reputation. My company forces us to use it, and it is sooo bad.
I am fairly indifferent to Slack - I have to use it for work.
But our experiences seem so vastly different:
- UI is, with the exception of large media, snappy and pretty native feeling
- no jumps (that I can recall)
The mobile app is okayish though its offline indication and notifications are a bit frustrating.
Not sure if it might be related to specific instances, i.e. large organizations with hundreds of channels, etc like in my case... still, my workstation is pretty beefy, threadripper pro 7985wx, 256GB RAM, RTX 4080 (and this is no software issue, as other, much more resource intensive apps run just fine)... though slack is unmistakably sluggish, to the point of me being frustrated enough with it to complain about it here :)
For some strange reason I am attracted to try to use ZTreeWin, even though I am using a dual pane manager as my daily driver, but there is some nostalgic force driving me to try and force myself onto ZTreeWin.
I even bought the license for it more than 2 years ago, but still haven't touched it in any serious capacity. I mostly lack the convenience and speed by which I am able to accomplish tasks in my existing (dual panel) orthodox filemanager, and at the same time I am losing patience by learning every single thing in it from sratch. Does anyone know of a good learning resource for ZTreeWin?
It’s not particularly sudden - we in the west just perceive it as such thanks to recent drama. Majority of the world population wasn’t living in a democracy for a while now (not even sure it ever has)
In C, sure. C is a dangerous language of its time.
But these contracts don't make things better.
Now you're removing control from the user. So now if an allocation fails, you crash. No way to recover from it. No getting an error signal back (NULL) so that you can say "OK, I need to clear up some memory and then try again". (Note that I'm not saying that inline error signaling such as NULL is good design - it's not).
Nope. No error handling. No recovery. You crash. And ain't nothing you can do about it.
That's just bad design on top of the existing bad design. Things that crash your app are bad. No need to add even more.
I'm not convinced. If something is going to cause a crash, like a nullptr, I'd rather crash near where the error happened with a nice error message, than hitting some UB crash god knows where.
Do I want my app to crash at all? No, of course not. If it's crashing, there's a serious bug. At least now I know where to look for it.
Should we pass back up an error signal instead of crashing? Yes, if it all possible, do that instead. Sometimes it's not possible or not worth the hassle for something you're 99.99999% sure can't/won't happen. Or literally can't currently happen, but you're afraid someone on the project might do a bad refactor at some point 5 years down the road and you want to guard against some weird invariant.
I think the point is about e.g. malloc as shown in the blog post. The stdlib function already have return values to indicate invalid arguments from the caller. These exist to allow the caller to decide what to do in this case. Replacing them by invoking UB or panicing, means the user looses control.
Having the stdlib expose both ways, means either having two stdlibs (like on MS Windows), or dynamic checks in the stdlib. I don't think either way is a good idea. Thus, these contracts can't be used by libc.
Precisely. The barn door is already open as far as the C library goes. And since C's error mechanism is all in-band (another bad idea in hindsight), the only thing the extra invariant checks will do is add even more (now uncontrollable) crash points to an already intolerably crash-prone app.
Panics are like goto: Only useful in VERY rare circumstances. Every use of a panic should require a rock-solid justification for why you're choosing to crash the process - similar to how every call to abort() requires justification in any professional C codebase. assert() in production code was a horrible idea because liberal use was actually encouraged.
Rust's panic mechanism was almost good. Unfortunately, they chose to give them all innocuous names like unwrap() rather than or_panic(). So now you have to check for it all the time using clippy because it's too easy for a human to accidentally gloss it over. Linting usually points to a design failure in the language UX.
The other hope for contracts is static whole program analysis can prove your program - at least in part. If you can prove some contract false that tells you where a bug is long before anyone triggers it.
Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware.
A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation details.
I will never understand how C developers can catastrophize over Rust panics, a language that has a panicless "_try" version of every panic causing function that returns a Result instead, while simultaneously accepting the infinite growth of ever harder to avoid UB in C/C++ and telling people to never have undefined behavior in their code.
If you think dealing with undefined behavior is easy and you assume that people have verified that their software triggers no undefined behavior at runtime is fair game, then you should grant that assumption in favor of Rust developers having done the same with their panics, because avoiding panics is child's play in comparison to avoiding UB.
I don't know what it is about panics that triggers some mania in people. UB does not interrupt the program and therefore allows memory corrupt and complete takeover of a program and the entire system as a consequence. C developers are like "this is fine", while sitting in a house that is burning down.
There used to be a pretty blatant hibernation bug with AMD GPUs on Linux that essentially crashes your desktop session upon turning your computer on from hibernation. I've also had a wifi driver segfault on login that forcibly logged you out so you couldn't login like 9 years ago. C doesn't magically fix these problems by not having an explicit concept of panics. You still need to write software that is correct and doesn't crash before you push an update.
There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.
Can we refrain from strawmen? I haven't made any of the points you're harpooning and vehemently disagree with all of them.
What I said was that panics aren't always appropriate and the context to determine this doesn't exist at the language level.
I didn't say managing UB was easy and in fact I've argued diagnosing it is impossible directly with members of both language committees. I didn't say panics are never appropriate. They usually are appropriate. I didn't say I don't use rust because X, Y, Z. I write rust. Etc.
There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.
More likely, but not guaranteed. I don't want to engage more with you, but there was a specific incident I was thinking of when I wrote the prior post that involved an assert improperly placed in a real time control loop that burnt out a very expensive motor.
We removed 30% of UB in the core language already for C2y and are in progress of removing more, so there is no "infinite growth of ever hard to avoid UB". For many UB the right way is indeed to panic and in C you can often achieve this with the UB sanitizer (but not for all).
