What about images, links?
Formatted text like bold or underline?
I also prefer plain text, but in most of my emails I talk about technical stuff, or I send transactional emails that require actions, in which case showing buttons is a much better user experience than plain text.
Every MUA I've used allows the reader to set a font size, so changing font sizes is 100% a feature of plain-text emails. Then they get the link the size they need to read it correctly and it's absolutely easy to read. This here comment is pain text. Is it hard to read this link:
I think the OP app is meant for creating transactional emails (or bulk-send emails like newsletters).
Those templates should account for all types of people and accessibility levels (including things like ADHD, where you need a big red button to click, otherwise you get overwhelmed by a block of text).
Using a URL shortener obviously. But you are right, if they only send plain text, they won't be able to include those 1x1 images at the bottom to track whether you have opened the email. Any sane email client blocks images by default, but whatever.
Yeah, I get it, I unfortunately live in the real world too. I like to keep it plain text whenever possible but it's extremely useful sometimes to have inline screenshots and stuff like that.
I didn't mean to be sarcastic but it's just that to me, philosophically, email is a plaintext technology that had HTML bolted on to it kicking and screaming, and it's always been kind of crap. People like me hate things that are fundamentally ugly and crap even if they are useful. The web was designed for HTML from the start.
I don't. Plain text is typically formatted for 72-78 monospace characters - even if you don't want formatting, the text will look bad on any device that doesn't match IBM's 80-character punch cards from 1928.
In theory format=flowed solves that, but the same boomers that despise HTML mail also refuse to provide that accommodation, for anyone not behind a teletype.
I used to think this, but lately I'm getting a lot of plain text marketing emails that are clearly LLMs. Now I dislike plain text emails just as much as HTML ones.
In what world would a specialized, niche, high precision, high readiness rocket meant to loft a very advanced interceptor munition into an extremely high velocity interception ever be cheap?
These things are closing at like mach 20. Physics says that's hard to do. That means it's expensive.
For reference, $75 million is in the realm of a Falcon 9 launch, which is a very cost optimized platform that doesn't have to place a very very precision instrument payload in a very very specific point in space to prepare it for a high energy, extremely difficult interception.
The cost primarily comes from the work needed to be done to make sure it works, not the raw materials. But there probably are some pretty expensive materials in it too.
This is what we had to build in the 60s to allow a missile to know where it physically existed precisely enough to allow it to 50% of the time hit within a circle of ~50 meters.
When you get to certain points in physics, certain energy regimes, you no longer are building machines or tools or something mass market. You are building artisan scientific instruments, and then sometimes gluing explosives to them.
Even modern laser ring gyros do not even share a dinner table with the precision and accuracy of the above singular component of the Peacekeeper ICBMs, and that was a long time ago.
"Tech" and some of the developments of the past few decades have really confused people. The miniaturization of the transistor, and building billions of transistors on a small slice of silicon is an aberration, an anomaly. Most things don't get "Better and better and cheaper and cheaper" like that because shit just doesn't scale infinitely and in general materials science isn't that precise.
For these ground based midcourse interceptors, they have to precisely loft the interceptor package at an incoming projectile. They have to shoot a bullet with a bullet, except the target bullet might even be moving around a bit, and your ability to precisely quantify the exact parameters of it's position and velocity is already limited. Is your position and velocity measurement an inch off? Two inches? Is that too much?
How well have you quantified the thrust of your rocket engine? THIS specific rocket engine, not a random one from the batch. Will you be off in a direction by a few meters per second? That might be enough to scuttle your interception.
IIRC this is the interception payload, a kinetic kill vehicle:
Then, are any of those nozzles slightly less smooth than they should be? That's a miss. Did propellant slosh in an unexpected way? That's a miss, Chicago is now a smoldering crater. Incoming round bounce your rader signal in just a slightly different way than you had the data to know about? Miss, San Fransisco now has significantly cheaper real estate. Chaotic properties of hot expanding gas slightly different than your simulation in the unluckiest way? Miss.
You have to exhaustively inspect, reinspect, quality control, test, simulate, retest, catalogue, document, every single component. You have to be able to predict, almost perfectly, how every single component will act and perform in a situation you will never get a test for.
High energy physics is always going to be hard, never cheap, because high concentrations of energy are literally what the universe itself is trying to reduce. The rules of reality itself are against you.
A creator on youtube named Alexander the Ok has done wonderful videos on a lot of the technology that goes into these systems, especially older, less classified systems.
Wow...just wow. Not a GNC engineer, but that drift spec strikes me as exceptionally good today, let alone the 60s.
EDIT:
> Even modern laser ring gyros do not even share a dinner table with the precision and accuracy of the above singular component of the Peacekeeper ICBMs, and that was a long time ago.
No kidding; full transparency, that was my basis of comparison.
It's a frankly insane piece of engineering, and that insanity is only multiplied by the fact that it works, and multiplied again by the fact that it works exceptionally well. No gimbal lock. No ball bearings.
"Actually it's really easy to precisely know your position and velocity in space, just float a special metal sphere in some fluid and touch it super gently"
I only know how exceptional it is because the video I linked above compared it's declassified specs to publicly available ring laser gyro specs. I am not a domain expert. There might be military inertial systems that beat even that nowadays. The US has been over-reliant on GPS guidance which is demonstrating it's weakness, but we used to be very very good at inertial platforms. However, that platform was so precise and accurate that improving it won't actually increase your missile accuracy that much. So maybe we have cheaper versions.
You probably know this but for trivia: Another standard ballistic missile position fix system is that they boost themselves up into space, and then take a moment to look at the stars, which is a remarkably workable system itself.
These floating balls of magic were essentially hand built, hand calibrated, with some components having upwards of 10k tests for verification. They cost several million dollars per system back in the 80s.
This is where a large portion of your tax dollars in the defense industry go: Paying very skilled americans to do very precise labor here in the US. General dynamics for example is about half the size of Pepsico, and takes a similar profit margin, but instead of overpriced water and potato products, we sometimes get the most advanced metrology money can produce.
Author here. The $75M is specifically for Ground Based Interceptors (GBIs). This is the U.S.'s ICBM mid-course interceptor. There are other interceptor types in the current U.S. arsenal:
Patriot PAC-3 (~$4M): Nations burnt through 600-800 in the first few days of Operation Epic Fury. There are reports that they're being used for drone defense.
SM-3 (~$10-30M): Ship-launched
SM-6 (~$4-5M): Ship-launched
THAAD (~$12-15M): Terminal phase, high altitude
GBI (~$75M): intended for interception of ICBMs (reported as the hardest type of missile to intercept)
Each type of interceptor is optimal for certain type of threats, which is yet another constraint on the optimization problem.
No-one in the real world wants to be paid with a $USR. Most everyone wants a cashapp/zelle/PayPal/wire transfer. The bullshit payment systems gained ground on crypto while crypto became more difficult/less usable
If you track the FATFs crushing of bearer bonds, bearer notes, non-KYC/non-AML offshore banking, and Hawala it almost perfectly tracks with the rise of crypto.
I don't know what USR is, but I would prefer to be paid in USDT or USC if Wealthsimple supported it as deposit method. When I withdraw, I do Deel -> Wise -> Interac e-Transfer -> Bank -> Interac e-Transfer -> Wealthsimple. This is incredibly stupid and I am forced to buy Canadian dollars. For groceries or electronics, you can buy gift cards using crypto.
But you do have to deal with bullshit payment systems. I can't receive stablecoins in my regular bank account, I'd have to set up some crypto nonsense on DankRocketBets or whatever for it to even work.
Why would I do this when I can already receive actual USD without any extra ceremony?
Stablecoins are a solution in search of a problem.
The problem presents itself when you have dirty money to launder. It isn't a product for non-criminals but they have to convince enough gullible people to participate and blend in with them.
If your employer does direct deposit of USD into your USD bank account, you don't need stable coins. This is not the case for most people outside of the U.S.
Most people don't realize they're inside a plexiglass shielded financial jail until they try to do something like wiring money for some legal activity in someplace spicy or on the FATF grey list.
If you fall into the middle bands of uses, or in the upper class that can just bend or make the rules, then the financial system is well oiled and it looks like the people questioning it are just cranks.
It's true that a lot of those in the outer bands are criminals but others are things like "buying a truck to build an orphanage for starving Iraqi children just outside of terrorist territory" or "wanted an investment visa in some corrupt island paradise and as it turns out no bank will open up account for purposes of 'international wires to the Comoros' "
Oh yeah, "most people outside the US" are looking to build orphanages in deeply sanctioned war zones. How could I have forgotten.
Come on now, that's absurd. If this is your best use case for stablecoins - groping for concocted scenarios to rationalise their existence
- I stand by what I said earlier: they're a solution in search of a problem.
One of the two is very close to something that actually happened to me. I tried to open up a bank account for paying immigration related costs to a particular shithole country, which is both legal and was part of a fully legal endeavor, but no bank would do it.
The other example is somewhat concocted but rooted in the time I spent in Iraq and noting almost all transactions are performed outside the banking system, in part because banking is inaccessible and people often don't have access to KYC documents.
It's really not absurd. As soon as you start trying to do anything interesting the KYC/AML burdens get greater until eventually you realize the compliance officers are just trying to get you to go away (or just deny you outright), get interesting enough and then suddenly despite fully complying with the law you find the walls are closed around you. Most people never find out because they never have occasion to try, they do a bunch of boring domestic transactions plus maybe some international trade with a few well known entities, then they just shout people are making up absurdities.
Clearly your situation of trying to obtain residency in the Comoros by investment would raise eyebrows at banks whose job it is to monitor tax compliance. I don't think you're describing an everyman kind of scenario.
I also don't entirely understand why you're even rationalising the purpose of the account to the bank. Can't you just open an account for any purpose? It takes me five minutes to open an account online, and I've never once been asked to explain or justify anything (in many decades). I use my accounts robustly, including for international transfers (I've lived on two continents in the last four years). I even once paid for a trip to North Korea out of an ordinary bank account. My bank never batted an eye.
Maybe you're just dealing with a bad bank, or an over-regulated banking system (Europe?). You realise you can walk into any US bank right now and they'll just open an account for you with nothing more than some accurate ID? And the same holds for much of the rest of the world? The problem you're trying to solve is already solved.
>> The other example is somewhat concocted but rooted in the time I spent in Iraq and noting almost all transactions are performed outside the banking system, in part because banking is inaccessible and people often don't have access to KYC documents.
Unsophisticated semi-literate farmers are the last demographic anyone is reasonably expecting to open their crypto brokerage accounts and start trading synthetic USD derivatives.
These are just not realistic scenarios. This is what people say when they rack their brains trying to come up with some reason stablecoins might be useful. I feel like you're just confirming that they're a solution in search of a problem.
> You realise you can walk into any US bank right now and they'll just open an account for you with nothing more than some accurate ID?
There's an ocean in the way, not to mention how risky visiting looks right now. I changed my name recently and the one US bank that I managed to get an account with (so that US clients can pay me without weirdness) won't accept any kind of documentation without going there in person (and I'm not sure I can provide anything they'll accept even if I did go there in person). What now?
Well no matter what you say it's always nuh uh, doesn't count or some variation of why can't you just be an "everyman." It's hard to argue with a dogmatic position that is based on feelings. You can tell such person what's actually happened to me when I tried to open an account with only "accurate ID" (a US passport) and they literally won't do it while you are homeless because they require a proof of address for KYC even if you have none. Almost everything they have asserted is plainly false. They also claim to have used their bank account to pay for trade in North Korea, a comprehensively sanctioned entity, which seems to be a public written confession of committing a serious crime just to own the crypto use crowd for internet points lol.
People in the middle bands of uses are just ignorantly bliss. And moving between "2 continents" in some vague most likely semi-developed white listed countries in most cases doesn't fall outside the middle bands of uses. So you end up with people shaking their fists at the sky crying that crypto exists, with their fingers in their ears and loudly proclaiming anyone using it are just making up absurd contrived scenarios.
>> They also claim to have used their bank account to pay for trade in North Korea, a comprehensively sanctioned entity, which seems to be a public written confession of committing a serious crime just to own the crypto use crowd for internet points lol
Lol. Thanks, Mr Google Esq.
I was indeed in North Korea. It was not particularly hard to get to before COVID (I'm told it's harder now). You have no idea what the laws of my jurisdiction are were at the time I went, or the purpose of my visit and whether sanctions even extend to it, whether I sought any exemptions from my government, etc - but please tell me more about all these alleged serious crimes you've just discovered on Wikipedia.
>> So you end up with people shaking their fists at the sky crying that crypto exists, with their fingers in their ears and loudly proclaiming anyone using it are just making up absurd contrived scenarios.
See, the problem with all your posts is that you're just spinning one tale after another. You need crypto for all the orphanages you're building in war zones. You need crypto for illiterate Iraqi farmers. You need crypto for your Comoros citizenship purchases. Never mind that none of that makes any sense - it's everyone else who's not listening to you! And all your super legitimate, not at all made up, not at all tax fraud related use cases for stable coins!
Why is it more absurd to want to build an orphanage in Iraq or buy a residence visa somewhere off the beaten path than it is to proclaim you've gotten sanctions exemptions for North Korea in the context of you explicitly pointing to the use of US bank accounts? Why is your anecdotes somehow more valid than mine?
Suddenly when it comes to your North Korea escapades (while proclaiming about mr. "everyman", lmao) I just don't have all the facts and nuance, but you just handwave away any of the uses I point to. Get real.
I never said I obtained sanctions exemptions, I merely pointed out you're just straight up making stuff up when you're concocting "serious crimes" with no knowledge of the underlying facts whatsoever. Which seems like a bit of a pattern with your posts, to be frank.
It's relatively trivial to visit North Korea, and there are many reasons one might do so that may not fall afoul of any sanctions (journalism, research, aid, and so on). It's ludicrous to proclaim you're building orphanages in Iraq for which you require crypto stablecoins. These are not even remotely comparable claims.
It's funny how you can know all the facts to be sure stable coins aren't applicable to some others' scenario but if someone dare point out that you paid a comprehensively sanctioned country by god they're not allowed to use the same evidentiary standards you have presented. And for the record, I said it seems as if a confession to a crime, not that it actually was one.
Seems as if you don't like it when your own logic is used on you. Which seems like a bit of a pattern with your posts, to be frank.
Lol. Evidentiary standards? Mate, I don't give a flying fig if you believe me or not. You asked for my experiences, so I gave them to you. I certainly don't believe you, so you're free to not believe me. Seems only fair.
Your claimed use cases for stablecoins are utterly fantastical and I think your posts speak for themselves.
I did not ask for your experiences. You were the one asking ("waiting"). Then just dismissing anyone that told you because it was never a genuine question.
Pick an FATF grey list country that isn't sanctioned by your country. Then try to wire money there. Let me know how it goes and whether you really aren't asked to explain anything.
Running down a list of corner cases means that you've already accepted the central idea. It's a classic internet troll-as-in-fishing gambit for derailing conversations that's been weirdly normalized.
1) To encourage good security practices in the event of compromise or technical improvements. Original '90s "export approved" SSL certificates were only 56-bits. If sites still used those today, they could be easily cracked.
2) To guarantee a recurring revenue stream for TLS/SSL issuers. Originally certificates were $50 to $100/year and there was a big process around renewal and verification. I remember having to fax in corporate paperwork. What a pain!
not the author of the gea but from what I can see in the readme, the ideas go back to 2017, erste.js and regie were earlier versions of the same concept.
As much as I love Java, everybody should just be using Rust. That way you are actually in control, know what's going on, etc. Another reason specifically against Java is that the tooling, both Maven and Gradle, still stucks.
Gradle does suck, it gives too much freedom on a tool that should be straightforward and actively design to avoid footguns, it does the opposite by providing a DSL that can create a lot of abstractions to manage dependencies. The only place I worked where the Gradle configuration looked somewhat sane had very strict design guidelines on what was acceptable to be in the Gradle config.
Maven on the other hand, is just plain boring tech that works. There's plenty of documentation on how to use it properly for many different environments/scenarios, it's declarative while enabling plug-ins for bespoke customisations, it has cruft from its legacy but it's quite settled and it just works.
Could Maven be more modern if it was invented now? Yeah, sure, many other package managers were developed since its inception with newer/more polished concepts but it's dependable, well documented, and it just plain works.
Just wrote a comment how I've always liked Maven. It's perfect for small and medium sized projects, and for service-oriented architectures/microservices - it seems like it was designed for this! It's main goal is to help you figure out the libraries that you're using and build them in a standard way.
It isn't great for really strange and odd builds, but in that case, you should probably be breaking your project down into smaller components (each with it's own maven file) anyways.
I would disagree that either "plain works" because to even package your app into a self-contained .jar, you need a plugin. I can't recall the specifics now, but years ago I spent many hours fighting both Maven and Gradle.
Well, yes? It's a feature provided by a plugin, like any other feature in Maven, you declare the plugin for creating a fat-jar or single-jar and use that. It's just some lines of XML configuration so it plain works.
Like I said, it's not hypermodern with batteries included, and streamlined for what became more common workflows after it was created but it doesn't need workarounds, it's not complicated to define a plugin to be called in one of the steps of the lifecycle, and it's provided as part of its plugin architecture.
I can understand spending many hours fighting Gradle, even I with plenty of experience with Gradle (begrudgingly, I don't like it at all) still end up fighting its idiocies but Maven... It's like any other tool, you need to learn the basics but after that you will only fight it if you are verging away from the well-documented usage (which are plenty, it's been battle-tested for decades).
You "need a plugin" in the sense that every component of maven is a "plugin". The core plugins give you everything you need to build a self-contained jar - if you wanted to, you don't even have to configure the plugins, if you want to write a long cli command instead.
Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code.
The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times.
Actually, really like maven, it's focus on building in standard way is fantastic (but agreed, it look messy, with all its xml and necessary versioning).
Actually, I like Maven. It's perfect for code that is broken into medium-sized projects, which makes it great for service-oriented architectures (would have said microservices here instead, but think we're learning that breaking our services too finely down is generally not a good idea).
Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.
I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately.
I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.
LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.
* The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java.
* Log4shell, amongst other vulnerabilities.
* Super slow to adopt features like async execution
* Standard repo usage is terrible.
There is no point in using Java anymore. I don't agree that Rust is a replacement, but between Python, Node, and C/C++ extensions to those, you can do everything you need.
> Python, Node, and C/C++ extensions to those, you can do everything you need.
Or you can use Java and have libraries that cover almost anything provided in those languages, having access to a massive pool of labour when needed.
> * Log4shell, amongst other vulnerabilities.
As if no Python, JS, C/C++ libraries ever had vulnerabilities? That's a non-sequitur, every ecosystem has security issues, the most important aspect is how quickly they are fixed. Given Java's massive size, a lot of libraries see high usage, and are actively developed, so security patches are released quite quickly.
> * Standard repo usage is terrible.
What does this even mean? Standard library?
Java has its place, it's boring technology that gets things done, and let companies hire from a immense pool.
By the way, over 25 years of carreer I have professionally worked with Java, Scala, Kotlin, Clojure, Obj-C, Go, Python, Ruby, PHP, JS, even ASP 3.0, and some .NET (C# and F#). I'm not a Java purist but I call your arguments a bit bullshit, all of these languages have their places, strengths and weaknesses, the sooner you realise they are tools and if they are generally used perhaps there's something valuable about each of them, the sooner you stop wasting time trying to argue why "X sucks, use Y".
Use the best tool for the job, knowing more tools is never bad.
> Java and have libraries that cover almost anything provided in those languages,
This is pretty funny.
or example, the other day I wrote a menu for mac os using rumps. Simply pip install rumps, write code, run, boom Mac os menu. Let me know when I can do the equivalent for java, or any other "performant" language.
>As if no Python, JS, C/C++ libraries ever had vulnerabilities?
Comparing the severity of log4shell to any python vulnerability is beyond crazy.
You have the Apache foundation, pushing its logging library as the industry standard, and multiple people saw no problem with not only the idea of a log statement being able to execute arbitrary code from the internet, but also making it the default behavior.
If at that point, everyone would instantly abandon any software from Apache in Java, I would have more respect for Java devs. But of course, they can't, because the ecosystem is so small that there is no replacements, so everyone is forced to cuck out to Apache, and who knows what and when other idiotic decision they are going to make.
There are plenty of other issues to cover on Java, but the log4shell pretty much is indefensible. Even if Im wrong about everything else, my argument still stands on that alone.
Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here?
Show me a language without vulnerabilities.
It has virtual threads for quite some times and it is a much much better choice for most use cases than async.
Are you arguing that the Android Ecosystem uses Java? Because it most certainly moved to Kotlin, and will soon move even off of that.
>Show me a language without vulnerabilities.
There is a scale of vulnerability severeness in terms of severity and how the vulnerability was introduced.
Most every language has libraries with bugs that can create vulnerability. Log4shell wasn't a bug - it was introduced intentionally without anyone at Apache looking at it and thinking that it was wrong, knowing that log4j is the most widely used logging library for java.
> Are you arguing that the Android Ecosystem uses Java
Now you are just arguing in bad faith. Who talks about Android, which historically lagged a decade behind OpenJDK and not particularly good at being up to date even today, so people moved to kotlin vs java without goddamn lambdas? Is that your argument? Especially that it's a tiny segment compared to the vastness of web backends. Are Google's, apple's, alibaba's backends, amazon cloud etc insignificant in your mind?
And you may want to browse the list of vulnerabilities, there are plenty interesting ones.
Rust has no place other than deployment scenarios where any kind of automatic resource management, be it tracing GC or reference counting, is not wanted for, either due to technical reasons, or being a waste of time trying to change people's mindset.
I'm a fan of Rust too. But there are millions of Java applications running in production right now, and some of them are running these anti-patterns today. Not everyone has the option to rewrite in a different language. For those teams, knowing what to look for in a profiler can make a real difference without changing a single dependency.
I think that right now it is easier than ever to rewrite your app in Rust, due to LLMs. Unfortunately there are still people out there who dismiss this idea, and continue having their back-end written in much inferior languages, like JavaScript or Python. If your back-end is written in Java, you aren't even in the worst spot.
"You think" is cheap, try doing it, rewrite an existing library in rust and see how it goes. Doing a rough prototype is easy, but the real work starts after that.
Programming in Rust is a constant negotiation with the compiler. That isn't necessarily good or bad but I have far more control in Zig, and flexibility in Java.
Yes, there is a learning curve to Rust, but once you get proficient, it no longer bothers you. I think this is more good than bad, because, for example, look at Bun, it is written in Zig, it has so many bugs. They had a bug in their filesystem API that freezed your process, and it stayed unfixed for at least half a year after I filed it. Zig is a nice C replacement, but it doesn't have the same correctness guardrails as Rust.
Assuming we're talking about the same bug, The filesystem API freeze wasn't caused by Zig's lack of correctness guarantees, but a design flaw in Bun's implementation.
Maybe I'm stupid, but I never actually understood people who blame programming languages for bugs in software. Because sure, it's good to have guardrails, but in my opinion, if you're writing a program and there's a bug, unless this bug lies somewhere in implementation of compiler/interpreter/etc, you can't blame the tooling, It's you who introduced this bug. It was your mistake.
It's cool when your tooling warns you about potential bugs or mistakes in implementation, but it's still your responsibility to write the correct code. If you pick up a hammer and hit your finger instead of the nail, then in most cases (though not always) it’s your own fault.
When millions of users constantly make the same mistake with the tool, there may be a problem with the tool, whether it's a defect in the tool or just that it's inappropriate for the job. Blaming the user might give one a righteous feeling, but decade after decade that approach has failed to actually fix any problems.
That's why I say "in most cases" - so not always, actually. There might be problems with tools, I'm not trying to deny that. And by the way, what if some (or even most) of the users just don't have enough skill to use the tool properly? Again, there could be a problem with tool, yes, but you can't always blame only tools for mistakes users make.
I am talking about this bug. It looks like it is still unfixed, in the sense, there is a PR fixing it, but it wasn't merged. LOL.
Regardless of whether this specific bug would be caught by Rust compiler, Bun in general is notorious for crashing, just look at how many open issues there are, how many crashes.
Not saying that you cannot make a correct program in Zig, but I prefer having checks that Rust compiler does, to not having them.
It does do a fair amount of filtering of submissions, and it's a long term archive (e.g. for the next 100+ years). I suspect both (but with the former dominating) are the issue.
Well, technically, it can also compile your tex file if you upload the tex file instead of the pdf directly, which helps a lot in standardizing the stylistic structure between preprints. Most other repositories are wild west and inconsistent. I really appreciate the similarity in style applied to most preprints there. Moreover, this means you can also download not just the pdf, but the source tex file to, which can be very useful.
The similarity in style comes from conference and journal templates, not from Arxiv. You can style your paper with latex in any style, Arxiv doesn't care. On Arxiv you mostly see preprints that people submit to conferences and journals and they enforce the style.
Drivers, kernels, firmwares, low-level networking, the likes. Some higher-level infrastructure, like compilers, interpreters, runtime systems (Qt/Glib-like code).
I'm not sure where the question comes from? The divide between systems and app programming is almost as old as coding itself; it's not some distinction without difference - it's the difference between writing a TypeScript microservice for handling CRUD on some tables versus contributing to the TypeScript compiler, Node runtime (eg. uv), and PostgreSQL query planner.
Both kinds of programming are needed; both require specific (diverging in places) skills to do well. FWIW, I don't think systems programming is any safer (maybe a little bit) from AI than making apps, but the distinction between the two kinds of programming is real.
I'm not sure. You'd have to define "level of rigor". TypeScript has a vastly more expressive type system than C, for example, so given their respective prevalence in their domains, you could easily say that coding apps nowadays is actually more rigorous. There's Rust, but somehow people write lots of apps in it. And so on.
I don't think systems programming is inherently harder than writing apps. You deal with different sets of problems (users stubbornly misusing your UI vs. hardware vendors notoriously lying in the manuals; hundreds of dependencies vs. endemic NIH syndrome; etc.), but coding is, for the most part, the same thing everywhere. IME, the "level of rigor" (as in "kinds and pervasiveness of actions taken to ensure correctness") depends much more on actual people or organizations than on the domain.
