GHC 9.8.1 | Hacker News Reader

GHC 9.8.1

discourse.haskell.org

108 pointsnjaremko24 comments

Woop! My timerfd change is finally out in the wild!

This will make it so that (on systems with timerfd) the runtime will no longer have to wait for the next runtime tick before exiting. This saves on average 5 ms per program run, and up to 10 ms for programs with a very short runtime. Not much for server programs with an expected lifetime of days/weeks, but potentially quite nice for CLI programs like hledger or for programs that invoke many other Haskell programs.

I accidentally discovered this when trying to optimize an Advent of Code problem and couldn't get it below 10 ms no matter what I tried. Eventually I discovered that "hello world" also took 10 ms so I assumed it was just runtime startup costs. Decided to look anyway and found out it was actually runtime shutdown costs, where the runtime would `join` the rts "ticker" thread. The ticker thread would only check for a shutdown flag once every loop, so 10 ms with the default settings. Now it can be shut down immediately, which makes small programs much faster.

Oh wow. I’ll have to recompile some of my old AoC Code to see how fast it really runs now!

Like you I had assumed this was simply runtime startup / teardown overhead.

> I specified text: 2.1 (a number) instead of text: '2.1' (a string) - causing Stack to complain vigorously

lol, not even Haskell can escape YAML being YAML.

Of all the complaints about YAML, I never understood this one, which is actually the correct way to handle it. Of course N.M (without some kind of quotes) is a floating point number and not a string!? The other way around would be _really_ strange.

On a general case, yes. But we are talking about Stack, a system for managing software dependencies. When was the last time you put numbers intended to be real numbers in a dependency declaration file? In different words, when was the last time you added, subtracted, multiplied or divided versions?

Version numbers are always strings with special comparison semantics.

I'm sorry, but I fail to understand the point you are trying to make.

Their point is that standard YAML is a poor fit for dependency config files.

My point is that all the numbers in a dependency configuration file should be automatically converted to strings, because they are really strings. Yaml doesn't do that.

Asking as a Haskell dabbler - why are features like `ExtendedLiterals` behind an opt-in language extension? Why not just turn it on for everyone?

This happens with the most used"(?) extensions after some time. Now for example there is Ghc2021 which sets the following extensions: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...

One possible reason could be that haskell has specifications (latest version is haskell 2010) and multiple implementations. So GHC cannot change the default language like this.

Hiding language features behind opt-in flags seems weird, but after some thought I like it. Consider if C++ had similar flags, people are always saying to choose a subset of C++ to use, and flags would make that explicit and enforceable. Also, when you see a weird bit of syntax you would have an idea what to search for.

> We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years.

Is GitHub sponsoring Haskell development? Or is this them providing some free services (e.g. more Runners) because it's a large and importans OSS project?

GHC is hosted on Gitlab, the Github repo is just a mirror. So money.

https://github.com/ghc/ghc https://gitlab.haskell.org/ghc/ghc

Don't forget that SPJ had been working for MS for quite some years.

Github is using GHC to analyze source code, that might be why they're sponsoring.

https://github.com/github/semantic

I am surprised just how much Cardano is responsible for the funding of GHC and what would happen if that stopped - 4 of those supporters are directly related to Cardano and a fifth is somewhere related. I don't know what GitHubs relation is with Haskell and wonder if that's some hosting/CI runners or something?

GHC uses self hosted gitlab for its source hosting and review. The gitlab-runners are largely provided by the mentioned support in the announcement, including anonymous and in-kind contributions. The ZW3RK stake pool provides 7 linux, 2 windows, and 3 mac builders.

I only see two directly related supporters? IOG and the stake pool?

And stack LTS is still on 9.4...

The very nature of coordinated package sets makes it impossible to have LTS package sets for the last version on release day. Stackage's policy is to use nightly for the latest release, and publish LTS versions for older compiler versions.

If you want to be on the cutting edge of releases and ignore packages coordination delays and package maintainers taking some time to respond because they actually have a life, you can move to the nightly. Smaller package sets but closer to GHC releases. If you want someone else to solve dependency hell for you and take the time to upstream that fix, you need to give people some time to do it.

> [...] nightly. Smaller package sets but closer to GHC releases.

Nightly has more packages than LTS. Currently 3213 (nightly) vs. 3010 (LTS).

That number grows over time.

Although, you're right, the nightly was 3005 packages when stackage moved to 9.4 [1]. I guess taking a few months for compiler version bumps in stackage helps that.

[1]: https://www.stackage.org/nightly-2023-06-21

so what? you can ask your refund to snoyberg.

Snoyberg is no longer doing Haskell, I think. Stackage is being handed off to the Haskell Foundation.

The correct snapshot would be nightly (which is on 9.6.3).

Reply on news.ycombinator.com