Scrapscript: A functional, content-addressable programming language
github.com
github.com
> it’s JSON with types and functions and hashed references
> it’s tiny Haskell with extreme syntactic consistency
Content-addressability is one of the main features of Unison [1]. How do the languages compare? Why did you feel the need to create a new language (especially since both have a strong Haskell flavor).
I'm guessing lots of people will have these questions so it could be good to mention Unison somewhere in your materials. The language seems to have big goals, so it doesn't seem that you are working on it "just for fun" :-).
Are there other "content-addressable" languages out there other than these two?
--
--
> Why did you feel the need to create a new language?
Well when I started on this language in 2017-2019(?), I definitely wasn't aware of Unison.
I remember talking to Richard Feldman about scrapscript when he first started working on Roc (fun fact: I was the first person Feldman added to the private repo!).
I spent a long time on the initial Scrapscript implementations, trying to compete in some similar applications as Roc, and Feldman just absolutely crushed it. I felt (and still feel) that Roc is doing a great job at the low-level "platform" experience I yearn for.
Eventually I met some Unison folks at Strange Loop (2019?), and we had very different inspirations and goals. That seems to still be the case.
There are some hard-to-articulate things I want out of the web, and Unison's architecture doesn't seem suited for it.
Anyway, Scrapscript only got a bunch of attention a year or two when I started working on it in public a bit more. I think defeating alcoholism also made me much more productive haha
--
> How do the languages compare?
From what I understand, Unison has very little in common with Scrapscript.
"Content-addressibilty" is really more of a mechanism than a "feature". Kinda like how AI is not really a "feature". You can't just sprinkle SHA on something and go raise venture capital haha
I think one major difference is that Unison opted for a more traditional git-based paradigm and then built some stellar dev tools on top of that. So far, Scrapscript is a bit more ambitious in its plans.
So go try out Unison! And come back and play with Scrapscript too, when it's more mature :)
I think you should read up on Unison a bit more, I see a lot of overlap.
Both identify code with hashes, and implement code sharing through hash based syncing. Builtin serialization is also present in both, and both are very Haskell inspired.
One difference I see is the sharing mechanism, where Unison has a local sqlite repository and tooling for uploading, while Scrapscript seems to be built more around IPFS. But that seems like an implementation detail rather than a fundemantal difference.
Unison supports algebraic effects, aka abilities with handlers, which is a much more powerful and general concept than the platforms in Roc.
At a glance to me, Scrapscript looks very traditional and easy to grok from a regular programmers perspective, there are build steps, you can use an IDE or editor etc.
Unison feels more like "Smalltalk Squeak" and Scrapscript feels more like "GNU Smalltalk". Come live in our new world, or integrate new stuff into your existing world kind of vibe.
Just out of curiosity and because we all have different limits - how much do you think you used to drink, generally, and what helped you quit?
Here's the essay I wrote when I decided to quit:
[1] https://taylor.town/1000-weekends
Here was my 8-week progress report:
[2] https://taylor.town/8-weekends
Right now I'm 96 weeks in! Going great!
If you need any support/encouragement, always feel free to email me at hello@taylor.town :)
• https://scrapscript.discourse.group
• https://news.scrapscript.org
Max's brilliant dev insights:
• https://bernsteinbear.com/blog/scrapscript
• https://bernsteinbear.com/blog/scrapscript-baseline
• https://bernsteinbear.com/blog/scrapscript-tricks
I posted a brief update here this morning:
• https://scrapscript.discourse.group/t/2024-07-23-design-deve...
Stay tuned! Lots of cool stuff coming :) Some sneak previews:
Unison makes reference to a node I also could find scant details of rust.
Each expression is a hash of (its ancestors - not too sure) but the implication is sort of the git dag is built into the language. Looks like that has deepmimplications for releases, deployments, inspecting code chnages
There is an implication that my-labcorp is using scrapscript. Which is interesting as it seems to be a health based platform - tracking and dealing with test results, X-ray images etc etc
So I love committing to one of the most basic CS concepts (cryptographic hashes)
And I love the implications for code management. What I am not sure is why that helps with things like labcorp platform - I also love those implications (encrypt and store and just shuffle that data) because cannot any language use the concepts ?
Some Tricks from the Scrapscript Compiler - https://news.ycombinator.com/item?id=40933250 - July 2024 (6 comments)
Scrapscript - https://news.ycombinator.com/item?id=40613756 - June 2024 (1 comment)
A Baseline Scrapscript Compiler - https://news.ycombinator.com/item?id=40551583 - June 2024 (4 comments)
scrapscript.py - https://news.ycombinator.com/item?id=39104504 - Jan 2024 (75 comments)
Show HN: Scrapscript “guide”, proposals, and community chat - https://news.ycombinator.com/item?id=36519579 - June 2023 (2 comments)
Show HN: ScrapScript – A tiny functional language for sharable software - https://news.ycombinator.com/item?id=35712163 - April 2023 (135 comments)
The killer feature would be pulling in other scripts as libraries (they may be published anywhere) but I can lock down the hash of these dependencies inside of my script file.
Is this possible?
There's a great list here
https://dbohdan.com/scripts-with-dependencies
but be aware that a lot of those are through third party tools and therefore don't have proper IDE support etc.
There's a few reasons why this might be annoying to deal with in practice, so we're working on a few different ways of managing versions throughout your script
* you said locking the hash in the script, and in the nix approach these are generally locked in either a lockfile or in the nix expression.
Can elaborate if you're curious.
I would love for the Nix lock to somehow be embedded in the script.
At the risk of overstepping (it sounds like you might be a little interested) here are a few links in to some basics just-in-case.
For context, I extracted my bashrc into its own repo, and it in turn sources bash libraries for my shell history and git status plugins. It's also leaning on some libraries that are pulled in through those two. (To be clear, this is just a general example of the flake pattern with a separate lockfile. I can find or synthesize something with the inline script pattern if you ask.)
- Source statements: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- Nix expression responsible for resolving and ~linking these two dependencies in to the final script: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- Flake inputs for the two dependencies. Note that these can be specified as just the repo or a branch and updated by updating the lock through Nix, or they can be ~pinned to a specific rev: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- A gist with examples of the entire chain of scripts that get resolved together here: https://gist.github.com/abathur/09f06f1f34b003376017d7a5c031...
These all get handled separately, so they can technically have divergent implementations of the same external command (for example, one library could depend on libressl and one could depend on openssl--and each resolved library would independently point to the correct one.