scala3-migrate VS bytestring

> If I recall, there's a compiler plugin they put out that could automatically make many of those changes

Actually, there are compiler options to rewrite the sources to/from scala3, I have tried this in more complex projects and it worked nicely (see https://docs.scala-lang.org/scala3/guides/migration/tooling-...)

This is the link to the plugin you mentioned which is supposed to avoid the manual syntax updates but I haven't had the need to try it, like you said, most of the times the changes are trivial enough (https://docs.scala-lang.org/scala3/guides/migration/scala3-m...).

> An example of one of the programmable games in action

This comes handy to me, looks cool! For one or another reason, I ended up in this page which seems to intend hosting the same app but it doesn't work, just wanted to let you know (https://www.wbillingsley.com/lavamaze)

There is a similar nice project which I have been looking into (https://www.kogics.net/kojo).

I'm using scala3-migrate as reference, although I haven't really done any Scala that much to know that issues this has.

The documentation is itself fairly funny, for those who don’t care to click ahead:

> This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.

> Witness the trail of destruction:

    https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7

If you bring in efficient strings from bytestring, densely packed arrays from vector, and an in-place sort from vector-algorithms, you can bring it down to 275ms (uses 19MB of mem).

bytestring

Note that this release is broken for Windows.

I've opened https://github.com/haskell/bytestring/issues/455 so the situation can be improved. You're very welcome to chime in on the discussion or to contribute some of the missing documentation yourself! :)

Highlights from the changelog:

Well, ByteString in particular should not have an IsString instance in a new report. That's pretty clear by https://github.com/haskell/bytestring/issues/140 : the concensus is that there is no good solution right now, but it should not have gotten an IsString instance in the first place. If a theoretical new Haskell Report 202x includes OverloadedStrings (as it should) to handle string literals analogously to numeric literals, I'd expect it to not give ByteString (which is really just a collection of octets) an IsString instance, with all it's issues and rattail due to the encoding question being implicitized.

Standard streaming libraries. They are being written by people that make the effort to understand performance and I have a hope that they make sure their streams run in linear space under any optimizations. It is curious and unsettling that we have standard lazy text and byte streams at the same time — and the default lazy lists, of course. I have been doing some work on byte streams and what I found out is that there is no way to check that your folds are actually space constant even if the value in question is a primitive, like say a byte — thunks may explode and then collapse over the run time of a single computation, defying any effort at inspection.