ff_

Those projects are in good hands!

There are a few of us still at it :)

Though with the advent of LLMs it became very easy to spin up alternate backends for it, so it's very much alive outside of JS as well.

second paragraph of the article starts with:

> The sector contributed 0.25% to GDP and enabled savings on consumers' electricity bills of more than 4.6 billion euros in 2024, with an average reduction in the wholesale price of close to 20 euros per MWh.

(in mice)

To yourself - the code you just merged is now yours to maintain

Fresh pasta is an entirely different beast from dried pasta, so the two are hard to compare. I never made dried pasta at home, but I find it impossible (even in Italy) to buy fresh gnocchi that are as good as the ones that you can make at home.

I am all for improving the conditions so that signs can be removed (and this is valid with code too, e.g. a strong type system removes the need for a lot of documentation), but again we should not advocate for not documenting things, that's just asking for trouble.

And speaking of signs, we definitely don't have a good balance there either - in some places I experienced confusing situations where adding a few more signs could have helped.

Sure, but then the advice we should give is "please please document the WHY", rather than "stop commenting"

In any case, I personally find it very useful when I come to a new piece of code to find comments that summarise what it's happening in a few words without having to parse 10-100 lines of dense implementation - I have so much cognitive ability I can apply in one day, and any effort to optimise its usage should be welcome

"Remove half of the signs, they become outdated whenever we change the roads"

Software is written by humans for humans, and documentation is a fundamental part of it, and needs maintenance just like the rest. It is beyond me why one would want to maintain only half of the thing and say "discard the rest"

In all the Haskell teams I worked in, the candidate knowing Haskell was rarely a significant advantage (except for cases where the most experienced Haskeller leaves, and then you need to hire someone to direct your GHC-internals questions to).

If you are interested in a job using a functional language you can pick basically any of them and then jump ship to a different one. I wrote Clojure for many years before switching to Haskell.

> As for myself, I think what foods I choose to consume are none of the government's business

There is a difference though: it's not about choice as much as it is about "good defaults". As a state you should want your folk to have better food, but if some person wants the choice of micromanaging their diet then sure, go ahead.

I shouldn't be struggling to find non-processed food in a supermarket. This is often the case right now, which is why I would very much welcome some more regulation on this.

This game is very good, congrats!

I would like to play more, but the games seem to be unreliable - the moves from my opponents stop getting through at some point, typically after a few moves.

I've been fighting with the automatic accumulation of downloads for years now - it really makes it impossible to figure out if whatever I downloaded can safely be deleted - so my current system is similar to the OP's one, but a little gentler: I have a launchd task that runs every day and warns "I'm about to delete these things that are older than two weeks", which lets me salvage anything I might have forgotten to archive.

Source here in case it's useful for anyone: https://github.com/f-f/home/blob/ee0ae5dd201ac6e8ffa60fff71b...

I've been looking into this (thanks for the pointer to Sensitronics!), do you have any pointers to a manufacturer of squishy material pads? (silicone I guess)

There's also the thing that while modern keeled sailboats are able to sail well upwind, that is not the case for these classic vessels which have a much smaller/shallower keel, and have a lot of trouble upwind. So if the wind is not right and you're on a schedule then motoring is the only option.

Sailor here - an 8 meters boat is in that awkward spot where it's big/heavy enough that it can do damage if incontrollably drifting against something (e.g. the wooden vessel itself) but light enough that you can literally just push it with the strength of two people if that happens.

So I'd argue it's more safe to have some crew on it in case you need to be hands-on, and just talk over radio while being towed.

Be very careful, it's surprisingly hard to eventually get out of it

The most impressive thing about this is not the overtone singing - one can learn that given some practice time - but to me it's how LOUD the quartet sounds.

I'd recommend being in the same room with them if you can, the feeling is just incredible, and videos and recordings absolutely do not render how powerful this kind of singing can get with the years of practice that they put in.

How is the working environment in PA tech? Would you recommend working there?

Sorry, I meant Duna Jam.

Do you know anything about what happened to Duna Rock?

Companies don't do this because they can get away with it.

Unions are usually the most effective countermeasure to these kind of things.

Here in Finland the tech-sector union just agreed to a 2% salary increase (inflation is at 2.5% this year [1]) after having threatened strikes if the conditions of the agreement were not good enough [2]

[1]: https://yle.fi/news/3-12143521 [2]: https://yle.fi/news/3-12262577

I'll give this a try, thank you!

I 100% relate to this, so the smartwatch bit is very interesting as I didn't think of using it for this - what's your workflow like? Do you just have calendar events on your wrist, or a more custom solution?

Are you aware of PureScript on Erlang?

https://github.com/purerl/purerl

Just yesterday afternoon I picked up my old laptop from 2015, and thanks to NixOS [0] + versioning my home folder [1] in a couple of hours (of mostly waiting for the thing to finish downloading stuff) I had my usual setup running with everything configured - like everything: settings, packages, emacs, shell, wallpapers, etc

NixOS stable is "extremely stable" (i.e. it never broke for me in three years that I use it) and "upgrading it" is still two commands away

Another interesting part is that now that I run it on all machines it is really easy to sync the configuration between machines, as they _literally_ share the same config barring something like 20 custom lines for every machine

This stuff used to take _days_, I'm so happy with this thing

[0]: https://nixos.org/ [1]: https://github.com/f-f/home

The facts the article refers to happened two weeks ago and have since been resolved, taking further steps to reduce the chance of this happening again in the future (e.g. by vendoring a lot of code)

Yep, we use the Haskell implementation as a library in Spago [0] and automatically migrating the configuration from old versions is a breeze as we can just manipulate the AST by pattern matching on it, e.g. see [1]

The above is quite standard in JSON/YAML too though, but an awesome thing you can do in Dhall is that - since you have functions - you can write migrations for Dhall data in Dhall itself, e.g. see [2]

[0]: https://github.com/spacchetti/spago [1]: https://github.com/spacchetti/spago/blob/a77b869edcfddd592f4... [2]: http://www.haskellforall.com/2017/11/semantic-integrity-chec...

From a cursory look to SANE and SCL it looks like Dhall still offers some more:

- functions

- a powerful typesystem

- remote (HTTP) imports with sha256 checksums

It really didn't take long for libraries to catch up, we already released a Package Set compatible with 0.13, two days after the release. That's a set of the most used ~200 libraries in the ecosystem.

https://github.com/purescript/package-sets/releases/tag/psc-...