We cannot even include it in stagex because there is still literally no way to compile it from source and thus no way to do a real reproducible build, and there is no one left that cares about the language enough to do this.
Honestly it has to be regarded as a dead language until this is resolved.
Declare something "dead" because it does not fulfill [extremely niche usecase that currently only few people care about] (boostrapped builds) and thus couldn't "even" be included in [project of the post author that takes a while to even find] (I eventually figured it must be referring to https://stagex.tools).
There are probably 100x more people interested in Haskell than in build-bootstrapping (the Haskell reddit alone has 16k weekly users).
What's next, calling JavaScript a dead language until it focuses on dependent typing?
(I think bootstrappable builds are a good thing to strive for, but that should not be confused with language usage or what people really care about.)
I said it has to be treated as a dead language. I did not say it actually is one.
Being able to compile a compiler without binary blobs is a hard prerequisite to using that language for any application where security matters.
A language can have an active community and still be unsuitable for any real world use cases. Fortran is bootstrappable so I consider it more viable than haskell for real world use, even though it has far fewer fans (understandably).
Maybe it is more fair to call haskell an academic language or hobby language since it prioritized language design over basic supply chain security thus far.
If it becomes bootstrappable, then of course all the above critique is immediately retracted.
I cannot comprehend how you can get to the conclusion that a compiler that was litterally made so that people could hack into it and learn from that has no build documentation.
My project has no need of Haskell, but if anyone puts in the work to make haskell compileable from only public source code my team and I will put in the work to reproduce, package, and maintain it for the community for free as we do most other languages.
Your link details building GHC with an existing non reproducible GHC compiler binary compiled by a single individual that must be blindly trusted.
Full source bootstrapping means no binary blobs or trust in anyone else needed, which makes supply chain integrity possible. This is a bare minimum for any language to be considered for production use in any environment where security matters.
To me it -is- crazy when a major language compiler skips something so basic, but Haskell did.
To be fair rust team skipped this too, but thankfully rust is popular enough that a community member cared enough about high security applications to write mrustc, a bootstrap rust compiler written in C++. If not for that Rust would be in the same boat as Haskell.
Meanwhile Go and Zig did it right, and have both provided full source bootstrapping instructions from a C compiler since day 1.
I dug into this and it turns out there's an active, multi year effort underway to solve exactly this, along the exact ways you´d expect, with references to guix and bootstrappable.org etc, making steady progress: https://discourse.haskell.org/t/what-s-needed-to-bootstrap-g...
Reading through that thread gives me a very different idea of the state of haskell than I got from reading your comments.
Efforts pop up every once in a while, usually with no results. As I said elsewhere, if they actually pull it off this time then my tone changes to one of willingness from my team and I to put in the work to use these efforts to support deterministic multi-signed builds in stagex.
It would make GHC (and pandoc) something we could have in tree which would be awesome. I am just annoyed it seems like such a low priority.
So first the data wasn't there, and suddenly it is there. I think the only way to prevent tis in the future is to litigate against those individuals who knowingly lie for a company.
Litigate the company, not the individual. The hiding of the data was almost certainly a result of company ethos and most likely involved multiple levels of people. The maintenance tech was probably the lowest paid of everyone involved.
Taking a bunch of projects and making containers and flexible helm charts for them is kind of an interesting model. It’s what Redhat and Canonical do with raw Linux packages; they charge for premium support and even patches or extended support.
I was going through one of my clusters, I have two bitnami uses and they are both ‘building blocks’ I use Trino, which uses a metastore which uses postgresql and then some other package uses redis. It seems like both postgresql and redis could/would have containers and charts to install their stuff, where it breaks is the postgresql guys probably want to support “current” and not 4 major releases back, which is kind of normal to see in the wild.
It is kind of an interesting model, I’d love it if rancher or openshift or someone started to seriously compete. Shipping a Kubernetes in a box is nice but if they started packaging up the building blocks, that’s huge too.
Bitnami started out (2010? definitely since 2014) distributing virtual machine images (e.g. preconfigured LAMP stack server) and somehow inherited the official kubernetes helm repo several years ago, which even then, I think we all saw the writing on the wall.
At my last gig I avoided Bitnami container images and Helm charts wherever possible. We (me plus an AWS consultant) used Karpenter Autoscaler, Envoy Gateway API, Gatekeeper OPA, Loki/Prometheus/Grafana Stack, EDB Postgres Operator, ... and deployed all through a single comprehensive terraform script to an EKS cluster. I tried to keep reliance on one single company as low ad possible. I even had a Plan B to replace S3 with MinIO in case the company decided to move to another cloud provider or an On Prem Kubernetes cluster.
My recommendation to everyone is to avoid Cloud Vendor Lock-In from the start, and even if it's more initial work, to try to have as much as possible running on Kubernetes.
