
Developing GHC for a Living - jacobwg
https://serokell.io/blog/developing-ghc-for-a-living
======
_bxg1
> I’m an idealist, and I believe that a perfect programming language with
> perfect tooling (or, at least, Pareto-optimal language and tooling) can
> exist. This is in contrast to people who just see languages as tools to get
> the job done. For them, a language is probably as good as the libraries
> available for their tasks.

I used to think that way. But it only took me half a decade of professional
development (and reading/discussing in circles like HN) to see that it's a
fallacy. A programming language cannot be perfect because it's made for
humans, who are not perfect (and runs on computers, which arguably are not
perfect).

Accepting the fact that there's no singular, perfect way to express a given
idea has been freeing, actually. I used to constantly chase the dragon,
getting hung up on refactoring and refactoring and refactoring, trying to
attain that perfect description. I still get caught up in it sometimes. A
little bit of that spirit makes for better code. But you have to be able to
pull yourself away.

~~~
dustingetz
There are a lot of unacknowledged tradeoffs in tools like Haskell. For example
the value of Haskell is balanced against ecosystem value of having 10M people
using the same tools. Getting 10M people to choose Haskell is actually a goto
market strategy problem that could be solved by a charismatic leader, but I
don't hear anybody from that community talking about that.

~~~
Ericson2314
> ecosystem value of having 10M people using the same tools

That is I think one of the fairer criticisms of Haskell. I don't personally
mind, but I respect others that do so.

That said, I wouldn't want 10M more users right now. The Haskell ecosystem
right now has tons of breaking changes, and I think that is important. More
users would freeze things in place until we have the tooling to _both_ have
breaking changes _and_ tool-assisted migrations. Only then would I want rapid
growth in popularity.

(Compare Rust's "backwards compat is really important", ....as if they they
could get everything right the first time ....as if that won't lead the way of
C++. Thank god they relented a bit with "editions".)

~~~
dragonsh
You are absolutely right adherence to backward compatibility will eventually
leads to situations similar to C++ or C. Rust and go eventually will be facing
same issues as C++ or C today, once they reach critical mass like them (which
itself is a question mark for Rust).

Haskell and other FP language is a completely different paradigm and it’s true
unless there is very good tooling which can transparently take old code and
move it to new code with breaking changes every language will go through that
transition, we can’t be prophets, who can know exactly what’s there in future
precisely. Python learned it the hard way as when it was designed didn’t have
Unicode and later to support it gone through 2 to 3 transition disaster. Java
was lucky in 1996 as by that time Unicode was popular and it backed it in
language and JIT infrastructure.

But at present in Haskell tried both cabal and stack to compile elm 0.19.1
compiler and pandoc and found it’s really hard due to version
incompatibilities of GHC. I hope situation in Haskell improves so that GHC can
compile old and new code transparently without too much fiddling and pain.

~~~
aratakareigen
> Rust and go eventually will be facing same issues

Isn't Rust's workaround their "edition" system? It seems to be working pretty
well for them, but it sounds like it could end up being a massive maintenance
headache.

[https://doc.rust-lang.org/nightly/edition-
guide/editions/ind...](https://doc.rust-lang.org/nightly/edition-
guide/editions/index.html)

------
hopia
In terms of GHC's evolution, this looks really promising to me:
[http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/](http://www.well-
typed.com/blog/2019/10/nonmoving-gc-merge/)

~~~
whateveracct
Yeah that is a monumental addition imo. You can find forum posts from just a
few years ago with this on their wishlist. Cool to see it finally happen.

~~~
hopia
Have you tried this yet in practice? I'm expecting it makes Haskell more
suitable for web stuff since that's where low latency is often more important
than computational performance is.

~~~
chowells
In what way do you think Haskell is bad for web use? I can't think of any
runtime performance metric in which it doesn't crush Ruby or Python, and those
are pretty popular for web apps.

~~~
exdsq
Sure but does it have web support like Django or Rails? There’s more to it
than performance when it comes to web dev!

~~~
hopia
Web support...?

~~~
aratakareigen
He means an ecosystem where 99% of the work needed to build yet another CRUD
app is done for you.

------
kossae
For reference, as I wasn't aware myself, GHC stands for Glasgow Haskell
Compiler.

~~~
3wolf
Overuse of esoteric acronyms is OOMBPP.

~~~
cosmojg
One of your biggest pet peeves?

~~~
exdsq
Isn't that OOYBPP? :P

------
yingw787
I would say I have a beginners understanding of Haskell (proof:
[https://bytes.yingw787.com/posts/2020/01/30/a_review_of_hask...](https://bytes.yingw787.com/posts/2020/01/30/a_review_of_haskell/))
and IMHE Haskell is an academic research language for good reason.

For most software, the SDLC is a stream, not tightly scoped like a library or
utility. I haven’t seen migration or upgrade plans, docs aren’t really there,
links rot extensively, and the strangeness budget is a blank check. It’s not
for most developers and it’s not because most developers are “lazy” or “dumb”.
I would have loved to use Haskell for my personal projects, but it didn’t
satisfy my requirements and I’m sticking to Python.

For starters, in Haskell Stack, there’s no uninstall option. You use shell to
rm a package.
[https://github.com/commercialhaskell/stack/issues/361](https://github.com/commercialhaskell/stack/issues/361)

That’s nope territory for most developers.

~~~
aratakareigen
Yep, Stack has an atrocious UX that does nothing but cause progressively
increasing amounts of pain. I wish someone would just write the Cargo or NPM
of Haskell already.

------
goofballlogic
What happened to Idris? As someone who knows absolutely nothing about Haskell,
I thought Idris was essentially Haskell+dependent types?

~~~
saityi
It is, and it still exists... it's also a brand new compiler, instead of one
with nearly 30 years of development on it, and a brand new ecosystem, instead
of having the massive amount of hours that Haskell has in it. Idris is really
nice imo, but Haskell+Dependent Types will likely be usable sooner.

There is an 'Idris 2' being developed, too
([https://github.com/edwinb/Idris2](https://github.com/edwinb/Idris2)), which
is an entirely new compiler with a new type theory (although not entirely
dissimilar), which just makes it even harder to use for real things (again,
IMO).

------
Brave-Steak
How hard is it to start working on a compiler like this?

