Does ZGC not also have an incremental marking phase?
63 karma · joined August 9, 2023
Does ZGC not also have an incremental marking phase?
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
Doesn't most modern Erlang code use binaries instead of charlists? Elixir and Gleam certainly do.
Could you give some examples?
[1]: https://doc.rust-lang.org/reference/statements.html
[2]: https://play.rust-lang.org/?version=stable&mode=debug&editio...
On the other hand, I've found normal threading in Rust quite simple (generally using a thread pool).
Thanks for the link to the LCF text though :^)
pub fn play<lifetime p>(in out self, player: mut ref AnimationPlayer lifetime p, new_animation: AnimationNodeIndex, transition_duration: Duration) -> mut ref AnimationPlayer lifetime p
But, this is still confusing! Let's remove even more symbols, and make the syntax more obvious by removing abbreviations: PUBLIC FUNCTION Play
LIFETIMES
P
PARAMETERS
IN OUT Self
Player AS MUTABLE REFERENCE TO AnimationPlayer WITH LIFETIME P
NewAnimation AS AnimationNodeIndex
TransititionDuration AS Duration
RETURNS MUTABLE REFERENCE TO ActiveAnimation
BEGIN
...
END
IMO, using keywords instead of symbols for references, lifetimes, etc, would just make Rust overly verbose, and there's a reason BCPL used braces instead of BEGIN/END :^)[1]: https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/... (can be spotted on page 353)
True, but to make use of Rc/Arc in Rust comparable to the use of GC in Java, almost evrery value would have to be wrapped in one, something I would think is quite rare.
> only that most programs do use it
I would still be interested in seeing statistics for this though. I have only ever used Arc once, and it was only to share a Mutex containing the program's database across threads.
> What's the difference between a standard library and a runtime?
I would say there are three main differences: - A runtime is (usually?) not optional - see languages like C#/Java/Python that require some sort of higher 'power' to manage their execution (interpreting/JITing code, GC management, etc), or crt0 - compared to a standard library which is just some extra code - see the C standard library function strlen() - A standard library can generally be implemented in the language itself. I think this is where the distinction starts to get a little fuzzier, with languages like Roc (its standard library is implemented in Zig), and Haskell (I would assume much of the side-effecty code like the implementation of IO is in C) - The purpose of a standard library is generally to provide 'helper' code that you wouldn't want to write yourself, e.g. Vec<T>, HashMap<T>, filesystem functions, etc. On the other hand, the purpose of a runtime is, per the first point, to manage the execution of the language, etc.
> I never said that LLVM was a JVM
True again, my point was worded badly. I didn't mean to suggest you thought LLVM was a JVM, rather to draw a distinction between LLVM and a Java/.NET style VM. LLVM used to stand for Low Level Virtual Machine, and the JVM has instructions like instanceof (which, fairly obviously, checks if a reference is an instance of the named class, array, or interface type). They operate at quite different abstraction levels, and the JVM is a lot more similar to the CLR.
> Now, it is true that Rust is typically (though not always) compiled to native code AOT
I would be genuinely interested in finding about a JIT compiler for Rust.
EDIT: it's worth me mentioning none of this is backed by any formal education (I'm 18), so it is very possibly wrong.
type 'a t = 'a option =
| None
| Some of 'a
I think this is the case because IIRC this function: fn slice<'a>(s: &'a str) -> &'a str { &s[0..2] }
Is generic over the lifetime of `s`, and it I assume it would have been difficult to distinguish generic types and lifetimes.[0] https://g.co/gemini/share/fa9d60da921d
[1] https://g.co/gemini/share/e20655d06292
[2] https://g.co/gemini/share/f11bc9f7e658