From the same makers or others?

On the website I can find no info whether this project is concluded or not.

Good choice in my opinion, as I hadn't even noticed the animation existed until I looked for something that might make the scrolling slow.

Is it the animation at the top?

In contrast to Gerrit and Phabricator, it needs not "Change IDs" inserted in your commits (easier workflow just using git) and "just works" to review whole branches.

It seems to me that "1 PR = 1 commit = 1 review" and "stacked PRs" workflows are just workarounds for not properly having implemented that as Reviewable has. Am I not seeing something?

Reviewable's main drawback is being for Github only and not open source.

It guarantees that pure functions are pure.

https://www.microsoft.com/en-us/research/publication/safe-ha...

https://downloads.haskell.org/ghc/latest/docs/users_guide/ex...

For those that hadn't read yet (on https://aws.amazon.com/service-terms/):

"Certain models" means "only AWS's own trained models" (Nova etc), so not e.g. Bedrock Claude or GPT.

"Certain limits" means they don't defent if the input to the model is the IP.

    rename to NodePointer instead
    format
    Revert "format"
    Revert "rename to NodePointer instead"
    rename to OptionalNodePtr
    woops
    update comment
    slot renames
    more renames

If every Ctrl+S is a commit, it'll go up fast.

"woops"!

But I self-host email for ~20 years, and I have not managed to get rid of Spam without not also getting false positives.

I first used SpamAssistant, in later years Rspamd, but I feel like they are just not good enough. Also I find Rspamd config pretty incomprehensible.

Hosted email like also does not solve this, e.g. GMail filters way much (e.g. important company correspondence leading to orders almost being lost because they landed in our GMail spam, so I had to turn off the spam filter entirely).

My self-hosted email filters too little spam, while GMail etc filter too much (e.g. important company correspondence leading to orders almost being lost because they landed in our GMail spam).

https://news.blizzard.com/en-us/article/19940901/teaming-up-...

If you changed a function implementation in the libc crate, not changing that function's signature, how much codegen would happen in downstream packages?

The maximally recompilation-avoiding effect would be: Only that one function gets codegenned. Everything else just gets relinked into their final executable or .so.

https://github.com/rust-lang/rust/issues/2369#issuecomment-1...

This would already help a lot.

I recommend anybody who's interested in incremental recompilation to read what GHC does, because the effort to achieve that is relatively low.

Of course there's always desire for more:

GHC currently needs to parse+typecheck+codegen a file before it can process other files that import it. Codegen is slow. Thus, there's currently demand split compilation into "stages", so that the next file can be typechecked after its imports have been just typechecked (not codegenned).

I would also enjoy if recompilation avoidance were to happen at the function level, not the file level.

Macro systems are a key language feature that can destroy incremental recompilation. In theory, Haskell is well set up for that, as its macro system (TemplateHaskell) is fully AST based and _theoretically_ could distinguish "fully pure" macros from side-effectful macros (such as splicing the current git commit in as a string literal). But the recompilation avoidance system does not currently exploit such differences.

Wero app Play Store page: "This item isn't available in your country."

Hard to cheer for a thing when it prevents you to access your own money, and promises to "easily pay" immediately fall flat.

Paypal is bad but at least it doesn't fail at step 0.

    I made that PR number up — I have no evidence a PR `2492` exists.
    That was a fabrication and I should not have written it.

Our company also uses Revolut business, but that requires a phone app to verify online payments with cards. And Revolut recently changed the app so it now requires Google Play Integrity so it doesn't work with LineageOS anymore. So I'm looking to move all new things away from Revolut. I have little patience with companies that want to unbank my company, and decide what hardware or software we use.

Since the pipe is generally unidirectional, the sending process has no way of knowing whether the receiving process has received, or even more successfully processed, anything sent. For that, one needs to make a pipe in the opposite direction and that is not as easy anymore; it also requires building your own protocol to identify and acknowledge sent work items.

LLMs removed some of the difficulty of Haskell, e.g. some interesting ideas to make things safer with sophisticated types or mechanisms like TemplateHaskell are now MUCH easier to implement in a few minutes. Also Haskell's general stance of breaking backwards compat in fundamental places if it's needed to make the language better, thus causing moderate amounds of upgrade grind, completely evaporated as a drawback because LLMs are extremely good at fixing type errors to bring code up to date with the latest changes.

The LLMs are very good at explaining Haskell compile errors.

Learning Haskell and maintaining projects in it is now easier than ever.

Haskell compiles slowly, but we have not found that to significantly inhibit AI-supported dev so far. We use ghci with `-fobject-code`, and our largest leaf module (10k lines of webserver request handlers) takes 8 seconds to `:reload`. To run stuff in it, the agent pipes `:reload`, or other invocations, into `ghci`.

Working on parts parts that are early in the module chain, such as our Prelude, makes the whole-project `:reload` take 50 seconds. Much of that could be avoided if we didn't suffer from the TH recompilation problem (https://gist.github.com/nh2/14e653bcbdc7f40042da3755539e554a). Originally I made a small GHC patch to hack that out (what this conservative recompilation protects from cannot happen in our project), which made the reload much faster, but the logic was changed in recent GHC so that doesn't work anymore.

In C++, we have some individual files (and thus compilation units) that take 45 seconds to compile.

Python is of course the fastest to (build+run). However, Python also has some problems with repeated runs: Once you have many imports, just starting the program (e.g. `--help`) takes ~2 seconds resolving imports. Do `import pytorch`, add another 2 seconds. For repeated runs, this can be a pain; Haskell and C++ are much faster for that, so they win when you don't have to change the code but repeatedly use already-compiled tools in a different way.

In all 3 languages, getting things to typecheck is very fast, because the agent directly reads the vscode LSP typechecking errors which are < 1s feedback. Claude Opus 4.6-4.8 understand all 3 languages very well.

I agree that GHC devs should focus most of their efforts on compile speed, and real-world pain solving. Some parts of that are indeed being done (e.g. newest GHC can write bytecode to disk to make the above workflow much faster, and codegen is by far the slowest part of compilation). But I think the focus should be even more on that. I consider most important and unsolved:

    * solving Generics being slow to compile, especially for types with many constructors
    * solving deriving classes being slow to compile
    * solving TemplateHaskell causing too much recompilation
    * doing staged compilation,
      so that the next module can typecheck as soon as its imports are typechecked,
      as opposed to waiting that codegen is done;
      this unlocks a large amount of parallel work availability

Other real-world production things are being solved quite nicely currently:

    * The new Haskell debugger
    * Much better stacktraces
    * Much better runtime introspection to debug runtime hangs etc

But I find it would not be a great language for the other parts. Its concurrency story is bad, its interpreter is very slow and immediately disqualifies Python when you need to do e.g. a line of code for every 1000 Bytes (say for streaming small data chunks), typing is very useful but bolted-on and not always correct.

Things where Haskell remains best-in-class is anything nontrivial-webservers, I/O, program correctness, the main "general purpose" programming, refactoring and long-term maintainability.