> 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 end of that paragraph. I don't think you can get "equivalent tooling" for such things the languages you list without raising interesting questions about what actually counts as Pascal/C/Zig.
I know what they were talking about. It was clearly intended to be a cheerfest for Rust.
> I don't think you can get "equivalent tooling" for such things the languages you list without raising interesting questions about what actually counts as Pascal/C/Zig.
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).
> 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 were talking about some hypothetical tooling that gave you something approaching Rust's feature set.
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.
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 "mode" (e.g., passing -ffreestanding to GCC/Clang)
> 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 action. Sometimes they exist purely for informational purposes.
> 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 "current long-term plan is to implement a second Hegel server in Rust" [0], so the current state of affairs is probably a compromise between getting something usable for end users out and something more "sane", as you put it.
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).
> 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 is due to the high implementation effort as it requires special handling for the async state machine. This restriction can be relaxed by a future RFC.
> Using `become` on a `.await` expression, such as `become f().await`, is also not allowed. This is because `become` requires a function call and `.await` is not a function call, but is a special construct.
> Note that tail calling async functions from sync code is possible but the return type for async functions is `impl Future`, which is unlikely to be interesting.
> 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 attribute.
The first RFC for guaranteed tail calls stated an attribute on `return` was a possible alternative "if and when it becomes possible to attach attributes to expressions" [0]. That was from pre-1.0, though; I believe Rust now supports attributes on at least some expressions, but I don't know when that was added.
The second RFC [1] doesn't seem to discuss keyword vs. attribute, but it does mention that the proof-of-concept implementation "parses `become` exactly how it parses the `return` keyword. The difference in semantics is handled later", so perhaps a keyword is actually simpler implementation-wise?
There's some more discussion on attribute vs. keyword starting here [2], though the attribute being discussed there is a function-level attribute rather than something that effectively replaces a `return`. The consensus seems to be that a function-level attribute is not expressive enough to support the desired semantics, at least. There's also a brief mention of `become` vs. `return` (i.e., new keyword because different semantics).
See my prior comment: IMO it's the caller's issue that (guaranteed) TCE is needed. The callee should not have to do anything.
One of the things I forget to give thanks to the Rust designers for is the default of immutability. I remember my days in a Java environment where policy was "everything needs to be declared final" (so "final" got spattered all over the place) with zero nostalgia. Requiring TCE callees to explicitly represent themselves as TCE-friendly would be the same sort of abomination.
I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. 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 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 essential for some cases, yes. GP's question, though, was why a keyword specifically and not a hypothetical attribute that effectively does the same thing.
A keyword seems nicer to me. I think the only reason to use attributes is to avoid the work of adding actual new syntax, but seeing as they've already done that...
- 2016, 64 comments (https://news.ycombinator.com/item?id=11309907)
- 2017, 44 comments (https://news.ycombinator.com/item?id=15254506)
reply