aw1621107

7 ms·

121.
by aw1621107 6mo ago
The question then becomes what, if anything, should take its place, and what are the corresponding tradeoffs?
122.
by aw1621107 6mo ago
> Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me. Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time
123.
by aw1621107 6mo ago
Rust chose a different design space for their async implementation though, so what works well for Go wouldn't work well for Rust. In particular, the Rust devs wanted zero-cost FFI that external code doesn't need to know about, whi
124.
by aw1621107 6mo ago
The archive says "12/14", so 2014 seems about right.
125.
by aw1621107 6mo ago
Interestingly, it looks like the `file == Path::new("/")` bit was basically unchanged from when it was introduced... 12 (!) years ago [0] (though back then it was `filename == "/"`). The change from comparing a
126.
by aw1621107 6mo ago
> and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. Probably will depend on what platform(s) you're targeting and/or your appetite for dealing w
127.
by aw1621107 6mo ago
Strictly speaking it doesn't preclude eventually producing a production-ready drop-in replacement either, though evidently that needs a fresh set of eyes.
128.
by aw1621107 6mo ago
Looks like they've been doing at some kind of automated comparison against the GNU test suite since 2021 or so [0]? [0]: https://github.com/uutils/coreutils-tracking/commits/main/?a...
129.
by aw1621107 6mo ago
> Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a
130.
by aw1621107 6mo ago
> How did this article get back on the front page with all its comments time-shifted? Sounds like the second-chance pool (dang's description at https://news.ycombinator.com/item?id=26998308 )
131.
by aw1621107 6mo ago
> The interoperability problems came from a design choice they made: they wanted to invisibly swap between OS threads if a blocking call was made. From what I understand the interop problems are more fundamental than that. The Rust devs
132.
by aw1621107 6mo ago
> And as for Rust - that's beyond inexplicable. Rust has green threads in the early days and abandoned them in favour of async / await. There was a fair bit of time between the two, to the point I'm not sure the latter can
133.
by aw1621107 6mo ago
I think so, assuming I'm thinking of the same thing you are, but I think that's somewhat besides the point. What I'm trying to say is twofold: - The presence of a GC doesn't guarantee memory safety since there are source
134.
by aw1621107 6mo ago
> They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining &qu
135.
by aw1621107 6mo ago
> I see that repo is two years old If the repo is what I think it is, the underlying bug is over a decade old [0]. From what I understand the devs have known how to solve it for pretty much this entire time, but their desired solution is
136.
by aw1621107 6mo ago
> I said builds. All of the languages I mentioned have "equivalent tooling" for that (i.e. compilers—to produce builds for the programs you choose to write in those languages). Oh, my mistake. Given the context I thought you we
137.
by aw1621107 6mo ago
Previous submissions with comments: - 2016, 64 comments ( https://news.ycombinator.com/item?id=11309907 ) - 2017, 44 comments ( https://news.ycombinator.com/item?id=15254506 )
138.
Statically Recompiling NES Games into Native Executables with LLVM and Go (2013)(andrewkelley.me)
1 points by aw1621107 6mo ago|1 comments
139.
by aw1621107 6mo ago
> than if you were using the equivalent tooling for Pascal, C, or Zig. I think GP is talking about not-directly-related-to-safety things like sum types/pattern matching/traits/expressive type systems/etc. given the en
140.
by aw1621107 6mo ago
The performance hit comes from the extra work Fil-C does over regular C, so if your decompilation/recompiliation process preserves semantics that extra work (and thus the performance hit) will remain in the final product.
141.
A simplified model of Fil-C(corsix.org)
208 points by aw1621107 6mo ago|136 comments
142.
by aw1621107 6mo ago
At least as far as major C++ implementations go you pretty much already have a freestanding stdlib since the standard-specified freestanding parts are a subset of the hosted parts. It's just a matter of compiling in freestanding "
143.
by aw1621107 6mo ago
> I feel like it said a whole lot without giving me much to take action on. Like great, you summarized the current state of affairs but it doesn't make clear what I am to do about it. To be fair, not every article is a call to actio
144.
by aw1621107 6mo ago
> A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off. For what it's worth the devs say their &
145.
by aw1621107 6mo ago
A bit of an intro/announcement blog post for Hegel ("Hypothesis, Antithesis, synthesis", [0]) was submitted here ~2 weeks ago [1] and got a fair bit of discussion (106 comments). [0]: https://antithesis.com/bl
146.
by aw1621107 7mo ago
> does this work well with async or is it purely sync tail calls for now? The current RFC generally does not allow `become` to be used with `async` for now [0]: > Tail calling from async functions or async blocks is not allowed. This
147.
by aw1621107 7mo ago
> Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity. Having a way to guarantee TCO/TCE is essen
148.
by aw1621107 7mo ago
> I wonder why they went with a new keyword; I assumed the compiler would opportunistically do TCO when it thinks it's possible, and I figured that the simplest way to require TCO (or else fail compilation) could be done with an att
149.
by aw1621107 7mo ago
That touches on why TCO/TCE is desirable, but it doesn't address why the Rust devs chose to use a keyword for guaranteed TCE.
150.
by aw1621107 7mo ago
Hrm, OK, that makes sense. Thanks for taking the time to explain! Guessing optimizing x+y*z would entail something similar to the third eval() definition but with Expr<L, Expr<L2, R2, Mul>, Add> instead. I think at this point I

More ›