I can't help but think at this point that Ghostty's "departure" from GitHub is unserious. It's been two and a half months now and not even a single peep of discussion about where they may be migrating to or what they may be doing.
I'm honestly a bit shocked this was done entirely using declarative macros. Normally when I see such arbitrary syntax I assume it's implemented as a proc macro.
I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex<T> and enough operator overloading to type vector expressions like a human being.
Rust has never been about outright eliminating unsafe code, it's about encapsulating that unsafe code within a safe externally usable API.
When creating a dynamic sized array type, it's much simpler to reason about its invariants when you assume only its public methods have access to its size and length fields, rather than trust the user to remember to update those fields themselves.
The above is an analogy which is obviously fixed by using opaque accesor functions, but Rust takes it further by encapsulating raw pointer usage itself.
The whole ethos of unsafe Rust is that you encapsulate usages of things like raw pointers and mutable static variables in smaller, more easily verifiable modules rather than having everyone deal with them directly.
>when you a pass a pointer to my function, do I take ownership of your pointer or not?
It's honestly frustrating how prevalent this is in C, and the docs don't even tell you this, and if you guess it does take ownership and make a copy for it and you were wrong, now you just leaked memory, or if you guessed the other way now you have the potential to double-free it, use after free, or have it mutated behind your back.
I remember talking about this concept with my brother a while back. Since LLMs have no neuroplasticity, they are locked in to what they were trained on in the time they were trained in. A model trained in 2026 would stay exactly the same for use by someone in 2126 to gain an insight on our time. Like a book that you can actually talk to.
I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.
GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
PCIe is probably the most future proof technology we have right now. Even if it is upheaveled at the hardware level, from the software perspective it just exposes a device's arbitrary registers to some memory mapped location. Software drivers for PCIe devices will continue to work the same.
The other day in a Facebook Messenger group chat I tried to link to https://motherfuckingwebsite.com/ as a joke, but Messenger kept blocking it. It's quite overzealous with its blocking.
>Further down the article, the author suggests bubbling up the error with a result type, but you can only bubble it up so far before you have to get rid of it one way or another. Unless you bubble everything all the way to the top, but then you've just reinvented unchecked exceptions.
Not necessarily. Result types are explicit and require the function signature to be changed for them.
I would much prefer to see a call to foo()?; where it's explicit that it may bubble up from here, instead of a call to foo(); that may or may not throw an exception my way with no way of knowing.
Rust is absolutely not perfect with this though since any downstream function may panic!() without any indication from its function signature that it could do so.
>every one of them seems to have some huge caveat which makes them useless
They were added into C before enough of the people designing it knew the consequences they would bring. Another fundamentally broken oversight is array-to-pointer demotion in function signatures instead of having fat pointer types.
Alright, I don't agree with half of what he said here, but really? Is that supposed to make him look like some irredeemably bad person?
Are we seriously going to pretend that men and women—on average—do not differ in their general interests, and furthermore get mad at people for pointing that out?
And I'm not fond of the current administration, but it's a bit extreme to write someone off as a person for liking who is president. You would be writing off literally half of the entire country, and no, that's not something to feel virtuous about, that's just nonsense.
Frankly I think I would rather have a conversation with someone like him instead of someone who would get disproportionately upset at those points.