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.

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.

Comments URL: https://news.ycombinator.com/item?id=46289587

Points: 2

# Comments: 1

> 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.

Comments URL: https://news.ycombinator.com/item?id=41998717

Points: 3

# Comments: 1

- 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

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.

Comments URL: https://news.ycombinator.com/item?id=40066464

Points: 5

# Comments: 0

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

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!).

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

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...

Comments URL: https://news.ycombinator.com/item?id=37172784

Points: 9

# Comments: 0

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).

- Can be triggered via a webhook or from a GitHub PR/comment - Can queue up multiple releases (of the same or different services) and deploy them in series - Flexibility (works not only with Kubernetes)

So far we've looked at Tekton, Buildbot, and GoCD. It seems none of them support our use cases: GoCD and Tekton don't support queuing of releases and Buildbot requires so much customization that we might as well continue building our own solution.

What do other modern medium-sized software companies use to make continuous deployment a reality?

Comments URL: https://news.ycombinator.com/item?id=36292110

Points: 5

# Comments: 4

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