230 karma · joined July 4, 2025
I think many people understand this subconsciously, and that this is what drives some of the more performative security culture in Rust spaces (superfluous safety comments, shunning of certain crate authors, `forbid(unsafe)`, push-back against syntax sugar, etc.).
> C [community] wants to still code
> many still don't know to distinguish
> the culture that... despite easy proof that isn't the case
> devs wrongly assume
> self inflicted complexity
> considered an advantage when argued by C folks
> when the same crowd points
> as the C crowd pretends it to be
You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.
JS:
let person_1 = { };
let person_2 = { parent: person_1 };
person_1.child = person_2;
use std::cell::Cell;
struct Person<'a> {
parent: Option<&'a Person<'a>>,
child: Cell<Option<&'a Person<'a>>>
}
let person_1 = Person {
parent: None,
child: Cell::new(None)
};
let person_2 = Person {
parent: Some(&person_1),
child: Cell::new(None)
};
person_1.child.set(Some(&person_2));
scrolling: used by games, maps, image viewers
link navigation: used for client-side routing (youtube/twitch, any website with a chat window)
text selection and copy/paste: word processors, spreadsheet editors, forum software, etc.
I'm not sure if your question was sincere or if you were trying to say that the web should not support these use cases.
https://ldjam.com/events/ludum-dare/59/setidream/about-ai-ar...
For what it's worth, the non-AI-coded entries were still quite good relative to the winners, so it's not so obvious that AI use confers an unbeatable advantage.
We kinda sorta almost had that for a short period with Flash (and Java, I guess): a webpage either didn't use flash and was secure and efficient like opening a document, or it did use flash and was featureful and interactive like an application. Users and system administrators could block Flash or enable it conditionally while expecting most of the web to continue to work, which in hindsight was actually pretty nice from a security perspective.
Piracy websites use a similar system. It's not nothing, but it's not enough for me to install pirated software.
The AUR is an official part of Arch Linux. It's hosted on the archlinux.org domain with a prominent link to it from the main page. You enable package installation from it either using one of the many transparent pacman wrappers recommended in arch community spaces and on the arch wiki, or by ticking a checkbox in a graphical package manager like pamac. IMO a one-line disclaimer on the aur main page doesn't fix the problem at all.
Security isn't about the trustworthiness of the code you're running, it's about the trustworthiness of the person who's giving you the code. No matter how good you are at auditing bash scripts, there's a malicious bash script that will slip by you, even if you're diligent (which most aren't, even among so-called "power users"). With official packages, I have to trust the people who distribute my OS. With vendor-distributed software (Windows software, PPA, curl | sh) I have to trust the person who wrote the software. With the AUR, I have to trust the first person to park the name of the package.
The world wide web was invented in 1989, Javascript was released in 1995, and the term "web application" was coined in 1999. In other words: the web has been an application platform for most of its existence. It's wrong to say at this point that any part of it was primarily designed to serve documents, unless you completely ignore all of the design work that has happened for the past 25 years.
Now, whether it was designed well is another issue...
This is true only if you use zero javascript, which isn't what the article is advocating for (and even with zero javascript there's quite a bit of client-side interactivity built-in to CSS and HTML). Besides: in practice most interactions in an SPA also involve network round trips, in addition to that slow react render.
https://tartanllama.xyz/posts/inline-hints/
This library seems to have the annotation on every function, though, so it's possible the author is just following a convention of always using it for functions defined in header files (it'd be required if the functions weren't declared `static`).
A big complaint I hear about OpenGL is that it has inconsistent behavior across drivers, which you could argue is because of the amount of driver code that needs to be written to support its high-level nature. A lower-level API can require less driver code to implement, effectively moving all of that complexity into the open source libraries that eventually get written to wrap it. As a graphics programmer you can then just vendor one of those libraries and win better cross-platform support for free.
For example: I've never used Vulkan personally, but I still benefit from it in my OpenGL programs thanks to ANGLE.
It's arguably irrational to evaluate a language based on this, but you can think of "this code could be better" as a sort of mild distraction. C++ is chock full of this kind of distraction.
#define foo(a) a = 12I'm not a good advocate for IMGUI; there are resources available online which explain it better than I can. I'm just trying to point out that the claim that immediate mode GUIs are some sort of CPU hog isn't really true. That's what I meant by "doesn't necessarily sacrifice performance," not that there is literally zero overhead (although I wouldn't be surprised if that were the case!).
> ...The browser's task manager shows this tab never goes idle...
As far as I can tell, the demo you linked appears to be bugged. You can see from poking around in a profiler (and from the frame timer under the "backend" popout) that the UI code does in fact go idle, but the requestAnimationFrame loop is never disabled for some reason. Regardless, even if this particular GUI library has problems going idle, that's not an inherent problem with the paradigm. I get the impression you understand this already, so I'm not sure why you've brought it up.
It's surprising the number of people for whom that series appears to have completely rewritten their understanding of programming. It's almost like when someone reads Karl Marx or Richard Dawkins for the first time and finds themselves questioning everything they thought they knew about the world. It's such an outsized impact for such a seemingly straightforward tutorial series.
Compare a hypothetical "Immediate Mode" counter:
void render_and_handle_button_click(struct ctx *ctx){
draw_text(ctx, "Count: %d", ctx->count);
if(draw_button(ctx, "Increment")){
ctx->count++;
}
}
void render(struct ctx *ctx){
set_textbox_text(ctx->textbox, "Count: %d", ctx->count);
}
void handle_button_click(void *ctx_in){
struct ctx *ctx = ctx_in;
ctx->count++;
render(ctx);
}
void init(struct ctx *ctx){
ctx->textbox = create_textbox(ctx);
ctx->button = create_button(ctx);
set_button_text(ctx->button, "Increment");
set_button_click_handler(ctx->button, ctx, handle_button_click);
render(ctx);
}
- It's UB to alias one struct pointer with that of a different struct type, even if the two structs have the same first few members. Clang and GCC both exploit this for optimizations, although you can configure them not to.
- Casting function pointers is also problematic, although I think that one is more of a portability issue.
- If you want to "downcast" from a "base" struct to an "inheriting" struct, you can use the `container_of` macro, which is robust against member re-arrangement and supports multiple inheritance:
#include <stdio.h>
#include <stdint.h>
#include <stddef.h>
#define container_of(p, t, f) ((t *)((char *)(0?&((t *)0)->f:p)-offsetof(t, f)))
struct reader { size_t (*read)(struct reader *self, uint8_t *p, size_t len); };
struct zeros { struct reader base; size_t total; };
size_t zeros_read(struct reader *self_, uint8_t *p, size_t len){
struct zeros *self = container_of(self_, struct zeros, base);
//...
}
#include <stdio.h>
#include <stdint.h>
typedef size_t read_fn(void *ctx, uint8_t *p, size_t len);
size_t work(void *ctx, read_fn *read){
uint8_t buf[8];
return read(ctx, buf, sizeof buf);
}
struct zeros_reader { size_t total; };
size_t zeros_read(void *ctx, uint8_t *p, size_t len){
struct zeros_reader *self = ctx;
for(size_t i = 0; i < len; i++) p[i] = 0;
self->total += len;
return len;
}
int main(void){
struct zeros_reader z = {0};
work(&z, zeros_read);
work(&z, zeros_read);
printf("total = %zu\n", z.total);
}Meanwhile:
- One of the two themes is always worse, but which one it is is different from application to application
- Despite the above, I'm required to decide globally whether I'm a "dark mode" or "light mode" person, with no option to just let the application or website decide on its own which theme is best.
- Because designers now need to support inverted contrast everywhere, everything has to be monochrome, including icons, text, backgrounds, etc.
I'd honestly rather people just picked one theme and directed their efforts towards making it look as good as possible. Or, you know, add support for real custom theming so I can make it look however I want.
10 years ago in the US I met someone who owned a company of about 5 people that he largely built off of the acquisition of a single broken pick-and-place machine which he repaired himself. They applied the solder paste manually and finished the boards in what looked like a toaster-oven. Each production run consisted of around 100 units which were sold at $50 apiece. The company is still in business today, as far as I'm aware.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
INTERP 0x0000000000000088 0x0000000000010088 0x0000000000010088
0x000000000000001c 0x000000000000001c 0x0
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
DYNAMIC 0x00000000000000e0 0x00000000000100e0 0x6c2f343662696c2f <-- "/lib64/ld-linux-x86-64.so.2"
0x2d78756e696c2d64 0x732e34362d363878 0x322e6f
readelf: Error: the dynamic segment offset + size exceeds the size of the file
LOAD 0x0000000000000000 0x0000000000010000 0x0000000000000000
0x0000000000001dc0 0x0000000000005660 RWE 0x1000
1. Was this done manually or is there a tool you're using which does this? I see other size-reduction tricks in here as well.
2. Does anybody know of a tool for examining executables which doesn't crap out on binaries like this?
> How are secret keys managed?
Stored on proton's server, encrypted with a passphrase known only to the account holder. I believe they allow you to upload keys as well.
> How are public keys managed? (Trust on first use, web of trust, etc.?)
ProtonMail supports WKD: Email clients can automatically query a proton account's public key using HTTPS. You can also send your public key to people using all the old ways.
> Where does the encryption take place, and where does that code come from?
Proton distributes a FOSS application which integrates with a standard email client. Yes, I imagine most people use the webmail client. Not offering a webmail client was not an option.
> What doesn’t get encrypted? (Subject lines, etc.)
Yes, I believe Proton only does the message body and attachments.
> How does this work for people not using the same service? Does everything silently downgrade to plaintext?
Yes. This behavior is important to increase adoption, and is a similar compromise to the one that allowed the HTTP => HTTPS transition. Once encrypted email is normalized we can tighten the screws.
> I know that sounds rude or dismissive, but the situation is completely terrible and there’s no real political will to fix it. And you *need* political will to fix it.
You point out that email encryption is a political problem. The folks at Proton are aware of that and are actively working to solve that problem. Part of the solution requires having a simple thing you can point people to that they can use to encrypt their emails with no fuss, even if that thing isn't perfect.
A quote from the linked video starting around 8:30:
> All of the advice you see online pretty much is for people thinking at this level, which is not where you want to be. You're gonna have to go through it at some point to understand what's going on, but your goal is to go from [individual element thinking] to [grouped element thinking], so advice like 'use smart pointers' or the rust borrow checker, all that stuff? Those are for people who are still not very good at programming.
To be clear: I do not agree with this position, but I thought it was important to clarify what I believe to be the intended message of this article (and others that you see coming from this group of people).