Expurple

10 ms·

91.
by Expurple 1y ago
You're being pedantic and trying to argue as if I misunderstand language runtimes and am speaking against language runtimes in general. That's not true. I qualified "the language runtime that's installed on that OS &quo
92.
by Expurple 1y ago
Rust doesn't need a formal document so badly, because (in safe code) the punishment for not following the rules is much more clear and small. It's either a logic bug that doesn't lead to memory-related vulnerabilities, or a
93.
by Expurple 1y ago
Copy by default wouldn't be so bad if the move was destructive
94.
by Expurple 1y ago
I meant a runtime that has to be installed separately. It's possible to statically link a C runtime if you use musl, for example
95.
by Expurple 1y ago
> Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Not sure what you're talking about. Any specific examples? > Also it requires everything to be compiled with the same compi
96.
by Expurple 1y ago
Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere
97.
by Expurple 1y ago
They are all fragile for different reasons: dynamic typing (that always leaks through bolted-on type hints anyway), implementation inheritance, null, exceptions, uncontrolled mutation, abuse of reflection and downcasts, weak leaky interface
98.
by Expurple 1y ago
Idk, I'm not familiar enough with Zig to say
99.
by Expurple 1y ago
I'll put it like this. Rust causes you to refactor more often and do a full refactoring at once (because the interfaces are so rigid), but it makes it easy to do a full (and correct) refactoring very quickly. Think of it as docs being
100.
by Expurple 1y ago
> There's so many good high-level languages to choose from We have many popular high-level languages, but I disagree that they are good. Most of them are fragile piles of crap unsuitable for writing anything larger than a throwaway
101.
by Expurple 1y ago
> in the end, you can write Option just fine it C. No, you can't. In the sense that the compiler doesn't have exhaustiveness checks and can't stop you from accessing the wrong variant of a union. An Option in C would be th
102.
by Expurple 1y ago
Fair enough. That's what they seem to be saying. But then I want to chime in and argue that the repetitive syntax isn't even close to being the main problem with Go: https://home.expurple.me/posts/go-did-not-g
103.
by Expurple 1y ago
> although that is very rarely done in practice. That's one difference. And the other important differences are: - Rust apps can depend on library "headers" written in other editions. That's the whole deal with editio
104.
by Expurple 1y ago
> The "70%" is just nonsense. Care to elaborate why? > And cherry picking individual benchmarks too. Do you have any general, comprehensive benchmarks or statistics that would indicate the opposite? I would include one if I
105.
by Expurple 1y ago
That's a really weird example to give. You can write unreadable code in any language if you're determined enough
106.
by Expurple 1y ago
They complain that Go is too low-level for their needs. Zig, with its explicit allocators, is definitely even lower-level. Rust seems low-level too, but it isn't the same. It allows building powerful high-level interfaces that hide t
107.
by Expurple 1y ago
> In practice, I never had a problem with "restrict". That's exactly because it's too dangerous and the developers quickly learn to avoid it instead of using it where appropriate! Same with multithreading. C leaves a
108.
by Expurple 1y ago
I agree that in practice NULL checking is one of the easier problems. I used it because it's the most obvious and easy to understand. I can't claim which kinds of unsoundness in C code are more common and problematic in practice.
109.
by Expurple 1y ago
No problem, get some sleep in that case :D
110.
by Expurple 1y ago
> A line of code does not depend on a million other things. But it does! To qoute my top-level comment: > What about about race conditions, null pointers indirectly propagated into functions that don't expect null, aliased poin
111.
by Expurple 1y ago
The deal with strict Rust-style references is that they solve mutable aliasing bugs (data races, iterator invalidation, all kinds of unexpected mutation really). That's the deal with Rust. The whole "memory management" thin
112.
by Expurple 1y ago
> Many binaries also depend on shared libraries. Yeah, and those are also the opposite of "solid" :) That's why I qualified with "static". I'm so glad that Go and Rust promote static linking as the default (
113.
by Expurple 1y ago
> frequently I could not _do_ a very straightforward thing, because, for example, some function is a fnOnce instead of fnMulti, or the other way around [..] It became clear to me eventually that some very minor changes in requirements co
114.
by Expurple 1y ago
I don't think you need an elaborate comment when one of your axioms is "must not read the post that you're responding to".
115.
by Expurple 1y ago
> such programs are often more, not less, sensitive to OS changes. You may be technically correct that they are more sensitive to the kernel interface changes. But the point is that native, static binaries depend only on the kernel i
116.
by Expurple 1y ago
I agree so hard. That's why I use Hugo for my website. Speed was always only a bonus
117.
by Expurple 1y ago
re:crates https://web.archive.org/web/20250420085150/https://wiki.alop...
118.
by Expurple 1y ago
> If someone posts a patch or submits a PR to a codebase written in C, it is easier to review than any other mainstream language. There is no spooky at a distance. [..] Changes are local. Lol, wut? What about about race conditions, null
119.
Non-Profit FOSS Solves the Conflict of Interest(home.expurple.me)
1 points by Expurple 1y ago|0 comments
120.
by Expurple 1y ago
As far as I can tell, the AGI fantasy is the usual counter-argument to this. "AI is going to make everything 10x more productive", "AI is going to invent new efficient energy for us", etc. And it's always "just

More ›