Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Steel – An embeddable and extensible Scheme dialect

github.com

Post reply on HN
Print view View original

51–60 of 192 posts

Re: Steel – An embeddable and extensible Scheme dialect

#51

Post by mattparas »

mst wrote: post #44
mattparas wrote: post #33

Earlier quoted context omitted.

Immutable values are reference counted, so for most code, things will be dropped when they exit scope. For captured mutable values, there is a fairly mundane mark and sweep collector. It is possible to manually control the garbage collector, however I have not optimized it for that kind of workload. If you were embedding Steel in a game, I don't think it would be explicitly necessary to tune the GC as long as you are…

You might find the Recycler algorithm interesting - nim's ORC collector is ARC + Recycler and seems to be working out rather well.

Thanks for the recommendation, with some brief poking around it does seem promising! It looks like the algorithm is this? https://github.com/fitzgen/bacon-rajan-cc

The link to the paper seems dead unfortunately from this blog post https://nim-lang.org/blog/2020/12/08/introducing-orc.html

I could see how it works as a drop in replacement for Rc

Re: Steel – An embeddable and extensible Scheme dialect

#53

Post by mattparas »

CooCooCaCha wrote: post #50
mattparas wrote: post #33

Earlier quoted context omitted.

Immutable values are reference counted, so for most code, things will be dropped when they exit scope. For captured mutable values, there is a fairly mundane mark and sweep collector. It is possible to manually control the garbage collector, however I have not optimized it for that kind of workload. If you were embedding Steel in a game, I don't think it would be explicitly necessary to tune the GC as long as you are…

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and r…

I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs

Re: Steel – An embeddable and extensible Scheme dialect

#54

Post by mattparas »

tucnak wrote: post #52

Is it possible to avoid rust completely when programming using Steel?

Yep - you can write standalone steel code without interacting with Rust at all, just interacting with the interpreter. I've done the first few days of the advent of code in Steel without needing to touch any Rust. Now, I will say that Steel has gotten visibility faster than I've been able to keep up with, so you might find a native function missing, or something that you would like to use that isn't implemented yet - at which point you either need to implement it yourself or open up an issue for someone to get to :)

Re: Steel – An embeddable and extensible Scheme dialect

#55

Post by mattparas »

mst wrote: post #45
mattparas wrote: post #38

Earlier quoted context omitted.

So here is the history: 1. Guy Steele (along with Gerald Sussman) created scheme, and Steel is close to Steele, just drop the e. 2. Steel is a scheme, and I observed that scheme names have a tendency to be named things crime related: Scheme, Racket (racketeering), Larceny, etc - Not a scientific analysis at all, but I found it funny at the time that Steel sounds like "steal". 3. You made the observation, Steel sounds…

Triple pun score! (I always try and cram as many simultaneous jokes as possible into project names - and have a soft spot for lisp - so I wish you much joy and whatever level of success is most fun for you)

Thank you - I appreciate the kind words :)

Re: Steel – An embeddable and extensible Scheme dialect

#57

Post by zozbot234 »

CooCooCaCha wrote: post #50
mattparas wrote: post #33

Earlier quoted context omitted.

Immutable values are reference counted, so for most code, things will be dropped when they exit scope. For captured mutable values, there is a fairly mundane mark and sweep collector. It is possible to manually control the garbage collector, however I have not optimized it for that kind of workload. If you were embedding Steel in a game, I don't think it would be explicitly necessary to tune the GC as long as you are…

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and r…

There are concurrent GC implementations for Rust, e.g. Samsara https://redvice.org/2023/samsara-garbage-collector/ https://github.com/chc4/samsara that avoid blocking, except to a minimal extent in rare cases of contention. That fits pretty well with the pattern of "doing a bit of GC every frame".

(Note that doing GC over large object graphs will nonetheless involve significant overhead, even with efficient implementations as seen here; GC is not at all a silver bullet, and should be avoided if at all possible. The actual point of GC is to enable computing over highly general, possibly cyclical object graphs - if that doesn't apply, other memory management strategies can be used instead.)

Re: Steel – An embeddable and extensible Scheme dialect

#58

Post by CooCooCaCha »

mattparas wrote: post #53
CooCooCaCha wrote: post #50

Earlier quoted context omitted.

Thanks, I think swapping and controlling the GC would be a very useful feature. In the game example I gave performance is important, but what's also important is consistency. Interactive apps rely on a steady framerate so what you want to avoid is accumulating garbage across multiple frames, then doing a single large collection pass. In other words, it's better to do a bit of GC every frame than a bunch at once and r…

I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs

Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.

Re: Steel – An embeddable and extensible Scheme dialect

#60

Post by mattparas »

CooCooCaCha wrote: post #58
mattparas wrote: post #53

Earlier quoted context omitted.

I'll make a tracking issue for it - new GC work is fun! I'll do some research, I have on my back log to integrate Steel into Bevy or some other Rust game engine, would give me a reason to make some fun GCs

Nice! Hopefully my statements didn't come off as demanding. Just providing some info on that use case.

Not at all! I agree it is a useful feature, I'd be curious how much it is necessary if not using any mutation, but the best way for me to find out is to try it out :)
Post reply on HN