rkrzr
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.
> 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.
Bjarne Stroustrup on "Software Development for Infrastructure" (2012) [pdf]
- 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.
How we optimized cluster-wide scheduling for sticky workloads
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...
Haskell vs. Zombies
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).
Ask HN: What are you using for Continuous Deployment (CD)?
We are currently working on supporting continuous deployments, but it seems that no suitable tools are available. We don't have particularly outlandish requirements, we want something that:- 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...
You may find some inspiration there: https://www.channable.com/tech
PyTorch has won: 59% of papers use it vs. 5% for TensorFlow
> 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!
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)
Parallel streaming in Haskell: Part 2 – Optimized parallel aggregations
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.
Parallel streaming in Haskell: Part 1 – Fast, efficient, and fun
- 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.
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