go VS Mastodon

Hey, this is mine. Thanks for submitting it. I'll answer some questions.

> Why?

I ported Trealla Prolog to WASM (WASI) and I was looking for something useful to test it against. I found Spin, which can run WASM+CGI, and landed on this. Making this project exposed a number of bugs in my port that have now been fixed, so consumers of more useful projects[1][2] benefit as well. Also, PHP style templates are just fun! There's something valuable to just being able to shove a little bit of code inside some HTML and get it up on the internet.

I started my webdev journey with PHP many many years ago, and it's nice to revisit it from a different perspective. I don't use the real (elephant) PHP anymore, but I've gained a newfound appreciation for how fun its quick & dirty development style is.

I hope this project can serve as an example of how to use Prolog for fun things. It does showcase some of the cooler dynamic aspects of the language, and the PHP parsing code is like 10 lines of DCG.

> Is it a joke?

Yes and no. The name is certainly a joke. I was pondering what 'Prolog on Rails' might be and thought calling it PHP would be funny. This led to the PHP-style templates which were quick to implement and pretty powerful. Despite the humorous presentation, it does actually work.

> Can you use Prolog for web services?

Yes! For example, SWI has a mature HTTP package: https://www.swi-prolog.org/pldoc/doc_for?object=section(%27p.... It's used to power SWISH, an online Prolog code sharing thing: https://swish.swi-prolog.org/

> Next steps?

I would like to support persistence somehow. I think it'd be really cool if you could use Prolog's dynamic database[3] as a persistent store. Spin has components for Postgres and Redis so it shouldn't be too hard to implement, but I lose the WASI compatibility if I do that... which means I can't use the binary from WAPM, etc.

I would also like to experiment with running Trealla on Cloudflare Workers. I have another project, worker-prolog[4], which uses Tau Prolog (a Prolog written in Javascript) on Workers.

On a somewhat related note, I've also been playing around with Cosmopolitan libc[5]. I got Trealla to compile to an APE executable but there's some issues with the embedded Prolog libraries getting garbled, so I need to improve my GDB skills and figure out what's going on there.

Finally, I'd like to say thanks to Andrew Davison (@infradig on GitHub), the author of Trealla Prolog, for letting me add WASM support to his project and helping me with lots of things. For example, PHP led to Andrew implementing improvements for using DCGs to parse Prolog terms, which is now super fast[6]!

[1]: https://github.com/guregu/trealla-js

[2]: https://github.com/trealla-prolog/go

[3]: https://www.swi-prolog.org/pldoc/man?predicate=assertz/1

[4]: https://github.com/guregu/worker-prolog

[5]: https://justine.lol/cosmopolitan/

[6]: https://github.com/trealla-prolog/trealla/issues/53

With trealla-prolog/go on the backend and trealla-js on the frontend, you can share the same validation code.

Other resources for logic programming and Go:

ichiban/prolog - ISO Prolog interpreter in pure Go, getting close to v1: https://github.com/ichiban/prolog

trealla-prolog/go - ISO Prolog interpreter embedded via WASM: https://github.com/trealla-prolog/go

guregu/pengine - library for interfacing with Pengines (SWI-Prolog's RPC protocol): https://github.com/guregu/pengine

biscuit-auth/biscuit-go - Biscuits are a fancy auth token with a little Datalog engine: https://github.com/biscuit-auth/biscuit-go

I'm a big fan of logic programming. We've been seeing a small resurgence of interest in it (for example Yarn using Prolog made some waves) and I have some optimism for its future.

Nice article! I think this is an exciting approach to cross-platform support. I took a similar approach for Trealla Prolog's Go library: https://github.com/trealla-prolog/go

The biggest roadblock at the moment is that Go WASM libraries are not in a very good state, except wazero. My assumption is that wazero will be slower than the cranelift-optimized wasmtime, etc. but I have not seen any benchmarks anywhere.

My impressions of the Go WASM libraries:

wazero: great Go-friendly API, not sure about performance, works on all OS (what the author chose)

wasmer: provides bare-minimum input and output for WASI, fast (it's what I chose for trealla-go). Doesn't work on Windows without significant pain, doesn't static compile the wasmer libraries so distribution is a pain. Seems essentially abandoned as its main contributor left the company.

wasmtime: basically impossible to get input and output in any reasonable way (unable to set stdin or read stdout; it can only inherit the FDs from the host), but might finally get buffers for I/O soon.

wasmedge: haven't investigated this yet, but it seems like it solves many of the problems above, promising

If anyone knows of a benchmark between these, I'd love to see it. I can try to run Trealla's against them if it doesn't take too much work.

It was just made private, I guess. Only the Go WebAssembly project is still public: https://github.com/trealla-prolog/trealla-go

Oh, TIL about https://mastodon.social/ (https://joinmastodon.org/)

Looks like what you describe, doesn't it?

> Social networking that's not for sale.

Interestingly there is some discussion for Mastodon with people asking the limit to be smaller, which raises the question as to the purpose of alt text, and how to properly handle larger text lengths in screen reader programs.

https://github.com/mastodon/mastodon/issues/12268

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

Mastodon DMs have absolutely no privacy: https://github.com/mastodon/mastodon/issues/18079

For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.

Postmortem on what happened here: https://news.ycombinator.com/edit?id=39305884

The v1 API of Mastodon limits the size of the tree that it will expand for users who are not logged into the server: https://github.com/mastodon/mastodon/blob/main/app/controllers/api/v1/statuses_controller.rb . I am guessing that this or some similar limit applies to threads being returned to unauthenticated users of the web UI. It just arbitrarily stops expanding the replies at some point, including the main thread from the OP.

If a thread is truncated, users expect it to expand automatically and autoscroll when you hit the bottom. In my desktop browser, that does not occur, and there is no indication that there is more to see. This is the situation of the web interface as of Mastodon version 4.2.5.

The issue is very sensitive to observer conditions. If you are logged into the server, the behavior is different. If you use a Mastodon app instead of the web, the behavior might be different. As the tree expands, the cutoffs become different. If you look at the thread on a different Mastodon server, the tree is different because every server has its own view of the Fediverse.

HN needs a best practice for linking to Mastodon threads in a way that provides a consistent experience to HN readers. The average Mastodon server would be crushed by hundreds of HN readers grabbing the entirety of a huge thread all at once, so this might involve some thread-unroll-and-cache service. I tried https://mastoreader.io/ but it did not solve the problem.

Alternately, we push changes into the Mastodon web UI to warn users when they need to click to see more and assume that people will get used to the navigation.

Suggestions?

Fixed in Mastodon v4.2.5 https://github.com/mastodon/mastodon/releases/tag/v4.2.5

>You can defeat the Affero clause by putting the software behind a proxy, for example

Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?

[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

Mastodon is free and open-source. Go ahead and add the flag:

https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....