Zag Smalltalk (2022) [video] | Hacker News Reader

Zag Smalltalk (2022) [video]

vimeo.com

https://github.com/dvmason/Zag-Smalltalk

"Smalltalk VM Written in Zig with methods stored as type-annotated ASTs"

This looks interesting. Just yesterday, I was thinking of hacking up something Smalltalk-ish. I'll def take a look here.

is there any benefit from using zig in this project

i see that Pharo is implemented 99.5% in smalltalk, which seem like a more reasonable target, implementing a language in itself is usually desirable

or is zig used just to bootstrap this implementation, and if so, how will this be better than Pharo

Smalltalk aside, how safer makes you feel Zig than C?

It provides proper strings, arrays that don't decay into pointers, strong typed enumerations, and no need to do sizeof math for heap allocations,

That alone is something C failed to improve in 50 years of history, features already provided by other languages of similar vintage and older.

If Zig manages to take a few developers away from C, that is already a win.

i am a big fan of zig, i am just wondering, how does a zig implementation improve on a smalltalk implementation

Zag is 66% Smalltalk and 33% Zig (approx.).

[~/ghq/github.com/dvmason/Zag-Smalltalk]$ cloc .

Language files blank comment code

--------------------------------------------------------------------------------

Smalltalk 306 4483 2203 18669

Zig 46 137 1000 10959

Didn’t have time to go through it all, but quickly scrubbing I didn’t see any mention of a UI. doesn’t SmallTalk by definition include a UI component?

Normally they do, but some implementations (notably GNU SmallTalk) are so afraid of the SmallTalk way of doing things that they use source files instead, which IMO removes a large part of the attraction of using SmallTalk at all.

And in the 1980s there was Little Smalltalk, which ran on UNIX systems normally accessed via terminals, so it was also file-based without a GUI.

https://en.wikipedia.org/wiki/Little_Smalltalk

As a full-stack engineer and old-time smalltalker I wholeheartedly agree.

Minimal images without UI and a kick-ass package management system should be the foundation of whatever else you want to build with it.

The image-based nature of Smalltalk-80 is both a positive and a negative. Inability to interoperate seamlessly with a "standard" developer workflow (editors, revision control, deployment) has, I'm pretty sure, hampered adoption.

I know there are tools and workarounds, and I'm quite familiar with how things are done there, and I used to be a huge advocate of the Smalltalk style approach. But over time, I've come to see two sides to this discussion.

No, not necessarily. Various Smalltalks have a wide range of different approaches to UI and IO more generally. This (their "operating system aspect" https://eighty-twenty.org/2019/01/13/why-learn-smalltalk) is the area in which they're most diverse, in fact. For instance, GNU Smalltalk has, by default, only a REPL, while Smalltalk 80 has a bitmapped GUI.

how hard it would be to get from squeak a minimum subset of objects required for basic repl (excluding graphics and sound) for bootstrapping?

It can already kind-of do a REPL, so it'd be about making sure access to that functionality was robust, and then it's a matter of removing packages from the system until it's as small as you'd like. Assuming a subtractive approach, of course. There are other interesting subtractive approaches like Craig Latta's "Context" (nee Spoon) http://www.netjam.org/spoon/ which does something a bit like a page cache, marking used methods, classes, etc and eventually garbage-collecting those not used. In Craig's system, there's an upstream over the network from which missing classes/methods/etc can be faulted in, so this isn't as scary as it sounds. Then there are the additive approaches, which I've kind of lost track of, but there are several on the go, for compiling a fresh image from scratch from sources.

Let's not couple concerns prematurely please.

I need Smalltalk for a lot of backends that have nothing to do with UI.

if you are already running backends in smalltalk, which implementation are you using?

Pharo 10 instances at this time.

I saw Pharo 6 and 7 and some 10 instances serving dozens of thousands operations per second in production reliably for years.

i haven't looked at pharo in a while. but when i did the thought of running it headless seemed a bit daunting. has that improved in any way?

You kind of need to know what you're doing to evade pitfalls.

ST 4U 282: Preparing a Pharo Image for Production - https://www.youtube.com/watch?v=TQfKnSR6izY

Overview of Pharo Web Stack [W4S7-EN] - https://www.youtube.com/watch?v=okHHUu9jsw0

How to setup a Pharo project - https://www.youtube.com/watch?v=Wnt3OBhR18I (although for CI I recommend using GitHub workflows these days)

Application development with Pharo - ESUG 2022 - https://www.youtube.com/watch?v=FdZUAWH__vk

Lastly, I'm working in using htmx and use Smalltalk stateless - https://www.youtube.com/watch?v=4_gmvN0pimI

Also this little handy thing can help you feel powerful to examine images running in production https://github.com/sebastianconcept/REPLEndpoint

that's neat! i can see myself using that.

but there is also a commandline repl: https://github.com/svenvc/NeoConsole

and other tools: https://github.com/svenvc/minimal-pharo-server-tools

and thank you for all those links. i hope other readers will find them as well

Glad it help! If you find any other bump don't hesitate to ask in the Discord server - https://discord.com/invite/QewZMZa

The guys there enjoy being helpful.

I can barely believe this comment was downvoted. For design sake, I hope the downvoters were not Smalltalkers.

Reply on news.ycombinator.com