rkrzr

This is a good post. AI has changed the programming language trade-offs and, as someone running a company that uses both Haskell and Python, I hope that Haskell can adapt to this new era.

I would like to add one additional observation, since we have been using both Haskell and Python in production for a long time:

Haskell excels at platform work, while Python excels at product work.

Our infrastructure teams work in Haskell (and also Rust nowadays), while our product teams work in Python. This gives us the best of both worlds (in my opinion): fast and rock-solid infrastructure on the platform side, and fast development speed and quick iteration cycles on the product side.

This setup has worked well for years for us, but it remains to be seen how and if this is going to change as well in the new AI era.

It does. See https://ghostty.org/docs/config/keybind/reference#toggle_qui...

This works on MacOS, and on Linux sometimes:

> On Linux, the quick terminal is only supported on Wayland and not X11, and only on Wayland compositors that support the wlr-layer-shell-v1 protocol. In practice, this means that only GNOME users would not be able to use this feature.

Cells may generate their own electrical signals through microscopic membrane motions. Researchers show that active molecular processes can create voltage spikes similar to those used by neurons. These signals could help drive ion transport and explain key biological functions. The work may also guide the design of intelligent, bio-inspired materials.

Lots of interesting points here, e.g.

> We should distinguish between infrastructure code and application code. Often, the two areas need different languages, tools, and techniques. Sometimes, that’s the case even when we use the same language for both infrastructure and applications. The role of static typing should be increased.

The extra emissions come from several factors:

- cows need a lot of land. If you used that land for e.g. efficient crops instead (and if people ate that instead of all that beef) you would free up a lot of land which you could use for other things (say, plant trees for example)

- cows need to eat a lot of feed to produce 1 calorie of beef. It is much more efficient to produce 1 calorie of vegetables and let people eat those vegetables directly instead of having it go through a cow first

- cows emit a lot of methane

- deforestation to produce more feed (like e.g. soy) is indeed also a factor

No. The SQLite bytecode is much higher-level than the instruction set of a CPU.

You can learn the lambda calculus in a few hours.

If you read just the first page of the linked paper and work through a few examples, you will likely already know enough about it to read the book. It's really just like equational reasoning in mathematics.

I suspect that the actual cost to rebuild the bridge will be far higher than that. Initial estimates of large public works projects are virtually always too low, and actual costs can easily be 5-10 times higher.

There is a great book about this phenomenon (and how to avoid it) by Brent Flyvbjerg called "How Big Things Get Done".

I am really glad to see that deterministic simulation testing is getting more coverage on HN lately. It feels like the next step up from property-based testing and (coverage-based) fuzzing.

We have gotten a lot of good use out of property-based testing in Haskell (using QuickCheck) since it is easy to set up and can cover a lot of ground for which you would otherwise have to write a lot of testing code.

I think that techniques like this have the potential to dramatically change software for the better if more of our industry starts adopting them (and it feels as if this is happening more and more!).

Thank you for all the great products that you have created! Your vision on infrastructure has always been inspiring to me and you are one of the few engineers who has truly moved the field as a whole forward.

Channable - https://www.channable.com | Utrecht, The Netherlands | ONSITE

Join one of the fastest growing scale-ups in the Netherlands. We currently have several open engineering positions to join our team in Utrecht. We are a young company with a strong engineering culture and some unique data problems, which we are solving for our customers.

You can read more about our work on our tech blog: https://www.channable.com/tech

Our Stack: Haskell, Python, JavaScript, TypeScript, Ember.js, React, PostgreSQL, Redis, Ansible, Terraform, Nix

We currently process more than 100 billion products per day and offer technically interesting and challenging work. We are looking for highly motivated and skilled engineers to join our team.

Open positions:

- Haskell Software Engineer - Infra team: https://jobs.channable.com/o/haskell-software-engineer-02-20...

- VP of Engineering: https://jobs.channable.com/o/vp-of-engineering

Channable - https://www.channable.com | Utrecht, The Netherlands | ONSITE

Join one of the fastest growing scale-ups in the Netherlands. We currently have several open engineering positions to join our team in Utrecht. We are a young company with a strong engineering culture and some unique data problems, that we are solving for our customers.

You can read more about our work on our tech blog: https://www.channable.com/tech

Our Stack: Haskell, Python, JavaScript, TypeScript, Ember.js, React, PostgreSQL, Redis, Ansible, Terraform, Nix

We currently process more than 100 billion products per day and offer technically interesting and challenging work. We are looking for highly motivated and skilled engineers to join our team.

Open positions:

- Haskell Software Engineer - Infra team: https://jobs.channable.com/o/haskell-software-engineer-3

- Machine Learning Engineer - AI team: https://jobs.channable.com/o/machine-learning-engineer-ai-te...

- Python Software Engineer - Infra team: https://jobs.channable.com/o/python-software-engineer-infras...

It allows the attacker to steal data like e.g. your (root) password.

Functional languages use recursion instead of for and while loops. Recursion is a more general mechanism that can be used to implement the equivalent of for and while loops.

So in short, functional programmers do not "hate" looping construct, but simply don't need them since you can use recursion instead (in practice you actually rarely use recursion directly, but instead use functions like map, fold, sum, etc. which are implemented recursively).

We have a tech blog that has been on the HN front page several times in the past. We focus on writing in-depth technical articles about how we use Haskell, how we solve scaling issues, and about our open-source work.

You may find some inspiration there: https://www.channable.com/tech

Do you see any new challengers to PyTorch?

Great news!

> Starting with Cachix v1.3, we’re enabling multipart uploads directly to storage.

I would be interested to hear more about the design of the new system.

E.g. does it make use of Cloudflare R2 for storage? How is authentication handled?

Would be great to hear more, if you can share!

We wrote a blog post on how Nix helps us solve some of the problems that we encountered with other package managers like e.g. apt and pip.

https://www.channable.com/tech/nix-is-the-ultimate-devops-to...

(It doesn't go very much in depth on the conceptual model, but touches on the the main ideas)

Thanks for the kind words @WJW, we are pretty proud of our engineering culture as well :)

We are unfortunately not looking for freelance assistance at the moment, but we regularly have Haskell Engineering positions open, so perhaps that will be interesting to you in the future.

This looks incredibly ambitious:

- There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values.

- Verse uses a so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between ("Everything is eventually evaluated, but only when it is ready")

- an expression does not evaluate to a value (like in Haskell), but instead to a sequence of zero or more values

- tries to bring functional logic programming into the mainstream

- Verse uses an effect system for I/O instead of monads

- A type in Verse is "simply a function". E.g. int is the identity function on integers, and fails otherwise

This all looks very mind-bending to me (in a good way). Perhaps Verse will one day be as influential for PL design as Haskell has been.

Channable - https://www.channable.com | Utrecht, The Netherlands | ONSITE or Remote EU (in consideration)

Join one of the fastest growing scale-ups in the Netherlands. We currently have several open engineering positions to join our team in Utrecht. We are a young company with a strong engineering culture and some unique data problems, which we are solving for our customers.

You can read more about our work on our tech blog: https://www.channable.com/tech

Our Stack: Haskell, Python, JavaScript, TypeScript, Ember.js, React, PostgreSQL, Redis, Ansible, Terraform, Nix

We currently process more than 100 billion products per day and offer technically interesting and challenging work. We are looking for highly motivated and skilled engineers to join our team.

Open positions:

- Haskell Software Engineer: https://jobs.channable.com/o/haskell-software-engineer-3

- DevOps Engineer: https://jobs.channable.com/o/devops-engineer-3

- Python Software Engineer: https://jobs.channable.com/o/python-software-engineer-5

- Frontend Engineer: https://jobs.channable.com/o/frontend-developer-utrecht

Stack comes with built-in Nix integration: https://docs.haskellstack.org/en/v2.9.1/nix_integration/

By default this will mean that Stack will use Nix to download non-Haskell dependencies. E.g. GHC and external C libraries will be downloaded by Nix.

This allows you to pin all dependencies that you have, including the compiler and external libraries (make sure to pin a specific version of nixpkgs though). And it will give developers a reproducible build environment.

It is also possible to take this Nix integration even further and make Stack download all Haskell dependencies from Nix as well. However, this requires to write a custom `stack-shell.nix` file, so I would only recommend this for people who are already familiar with Nix. This file must then be configured in `stack.yml`

Example `stack.yml`:

# Using a `ghc-*` resolver means that stack won't try to download and build any packages itself, # instead it will only use the packages that are shipped with the compiler. # In `./nix/stack-shell.nix`, we ensure that the compiler indeed ships all the packages we # need. resolver: ghc-9.0

packages: - "."

# This makes stack pick up our nix environment for building by default. nix: enable: true shell-file: nix/stack-shell.nix path: ["nixpkgs=./nix/nixpkgs-pinned.nix"]

> How is package management these days?

We use Stack together with Nix to pin all dependencies. That works very well.

> Is cabal hell still a thing?

No.

> How's the IDE situation?

Much better than it was. Haskell Language Server (HLS) has been a game changer. It works very well and can be used with different editors (easy to install for VS Code for example).

I didn't know that you can compile individual modules with mypyc. That's very interesting since it allows a gradual adoption of the compiler, which really helps with big codebases.

Do you know if there are any requirements for which modules can be compiled? E.g. can they be imported in other modules or do they have to be a leaf in the import tree/graph ?

I agree - Nix, the language, really is at the root of many of Nix' problems.

The bad error messages, the useless stack traces, and the overall un-debuggability of Nix are not just minor issues. These are at the core of the steep learning curve of Nix. These are also the reason why with Nix you are often 'dead in the water' and don't know how to fix a problem, and end up googling for hours or asking somebody else who knows more about Nix.

And these issues cannot be fixed by having "better docs" or a better tutorial.

If somebody were to rewrite the language today then my suggestion would be to make it statically typed, like Haskell. I would probably also make it strict, with optional laziness, although that's less important imo. And providing good error messages and good debuggability should be explicit design goals.

Making it statically typed would necessitate a different overall design, since many of the dynamic tricks would not be possible any more, but I suspect that you would end up with a better overall design in the end.

Channable - https://www.channable.com | Utrecht, The Netherlands | ONSITE (post Covid) - Remote EU (in consideration)

Join one of the fastest growing scale-ups in the Netherlands. We currently have several open engineering positions to join our team in Utrecht. We are a young company with a strong engineering culture and some unique data problems, that we are solving for our customers.

You can read more about our work on our tech blog: https://tech.channable.com/

Our Stack includes: Haskell, Python, JavaScript, TypeScript, Ember.js, React, PostgreSQL, Redis, Ansible, Terraform, Nix

We currently process tens of billions of products per day and offer technically interesting and challenging work. We are looking for highly motivated and skilled engineers to join our team.

Open positions:

- Haskell Software Engineer: https://jobs.channable.com/o/haskell-software-engineer-3

- DevOps Engineer: https://jobs.channable.com/o/devops-engineer-3

- Python Software Engineer: https://jobs.channable.com/o/python-software-engineer-5

- Integrations Engineer: https://jobs.channable.com/o/integrations-engineer-python-3

That's how I see it as well - Haskell has been very beneficial for us as a company, so it's nice if we can also contribute something back to the community.

> That said, I'm pretty sure the Haskell runtime is very complex, so it might still be the wrong language.

While the Haskell RTS as a whole is a big (and marvelous) piece of engineering, it is not actually necessary to understand all of it to contribute some smaller patches.

The RTS is written in fairly readable and clean C code and it is possible to make local changes to e.g. the memory allocator without having to touch code in lots of different places.

> Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits.

(Channable co-founder here) If everybody took this view, then a language could never improve. I have actually been very impressed with how far we have been able to take Haskell before having to push its limits. Anecdotally, we previously were using Scala (and Spark) and ran into issues much earlier. In those cases we were pushing the limits of Spark, but underlying those were the limits of the JVM.

> IMHO when you’re providing language patches you probably choose the wrong language.

This is a very myopic view. There is much more to consider when choosing a language (what kind of team do you have, what kind of problems are you working on, maintainability, performance, ecosystem, hiring, etc.).

Channable - https://www.channable.com | Utrecht, The Netherlands | ONSITE (post Covid) - Remote EU (in consideration)

Join one of the fastest growing scale-ups in the Netherlands. We currently have several open engineering positions to join our team in Utrecht. We are a young company with a strong engineering culture and some unique data problems, that we are solving for our customers.

You can read more about our work on our tech blog: https://tech.channable.com/

Our Stack includes: Haskell, Python, JavaScript, TypeScript, Ember.js, React, PostgreSQL, Redis, Ansible, Terraform, Nix

We currently process tens of billions of products per day and offer technically interesting and challenging work. We are looking for highly motivated and skilled engineers to join our team.

Open positions:

- Haskell Software Engineer: https://jobs.channable.com/o/haskell-software-engineer-3

- DevOps Engineer: https://jobs.channable.com/o/devops-engineer-3

- Python Software Engineer: https://jobs.channable.com/o/python-software-engineer-5

- Front-end Developer: https://jobs.channable.com/o/frontend-developer-3

- Integrations Engineer: https://jobs.channable.com/o/integrations-engineer-python-3