robertlagrant

Indeed. It's the same principle[0] the other way too - start a timer from user typing for an autocomplete function and only refetch after the timer expires.

[0] https://developer.mozilla.org/en-US/docs/Glossary/Debounce

I've used Proton for a couple of years and have never had problems before today, so I think their engineering is of a high standard.

In fact, I applied for an Engineering Director role there not too long ago and they rejected me, so they must have extremely high standards!

Oh - that's interesting too! But I meant more as a frontend across various integrations a business might have. E.g. having a bot that tells you if your CI failed is currently likely surfaced inside Teams or Slack. Having an internal chat service feels like a big win so companies don't need to integrate private companies' tooling so deeply.

I like this article, but I would take some issue with the concept of the percentage of time taken up being a major issue.

If you go from taking 2 days to write some code and 20 minutes to type check (which does seem long, don't get me wrong, but still) to 10 minutes to prompt some code and 20 minutes to type check, that percentage increase to me isn't enough to justify switching.

You're still almost 2 days ahead, and converting those 20 minutes to 20 seconds are not going to make you ship a feature appreciably faster. But those types stand strong and I don't believe they can yet be replaced by an LLM believing they're correct.

Having said that, I also think that Haskell should massively speed things up. Having strong types if nothing else should surely produce some amazing type-checking speed wins.

Very good. I was wondering about this a while ago - lots of companies want something to aggregate notifications and perform simple bot actions, but don't necessarily want to lock into a chat provider. Having this as the frontend to a load of integrations (or even just internal chat) would be really interesting.

> and can have access to an increasingly vast back catalogue of older games

By this I meant via a subscription.

I see what you mean, but I think gamers on a budget will cancel. Other gamers would've paid full price for 12 games and instead paid $15 each for 12 games.

> So if you put your new game that you would have sold for $60-80 dollars to me directly and it translates to three weeks of engagement on your $15-ish/month (depending on level) subscription, it's hard to see how that is an economic win. Put that game on Gamepass in a year or two, sure, that can make sense, but on release?

I think that's what I thought it would be, too. XboX has a really good track record of backwards compatibility. I can (and do, occasionally) play 360 games on my series X.

A model where people can buy the latest games, can not only keep them but play them forever on future consoles, and can have access to an increasingly vast back catalogue of older games, seems like a huge win. And maybe each full price new game gets them a bit of a discount on their next month's game pass, to make it slightly better value than the playstation equivalent full priced game.

But they didn't seem to want to do anything like that.

Very interesting! How are those garages coordinated? Who designs and who commissions?

Some people will exaggerate one way, and some the other way. The internet is big and you can say, and substantiate, "people said" for any opinion you choose, and show that it was wrong later.

I think it's an 8% drop on the previous usage, not 8% of total compute drop.

That's fair enough - I see what you mean. I think I read the case I was thinking into the article. Now I re-read it, it is saying what you're saying, which does make a lot of sense.

Using types like this also means you can more easily avoid assignment errors, as everything will have a very specific type (e.g. Age instead of int).

This feels right, and I also have never done it (or had the guts to get others to do it).

The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right.

The classic answer is to move the logic inside the domain object, or have a helper function outside the object, so you aren't constantly checking for field presence/absence, but are instead writing the logic once and calling some code.

I'm not sure in practice types can help with this. But I'd love to be proven wrong.

Thank you - great blog post.

Will Self[0] is going to love this.

[0] https://en.wikipedia.org/wiki/Will_Self

Thanks - interesting. Very odd, though.

> Forcing hand written should really not be necessary. It would be very cheap in terms of old computing hardware to set up a test room with old desktop PCs that have wired only NICs (with a network connection that goes to a switch in the same room with no uplink, connected to a decent size laser printer only), running something like lubuntu and libreoffice writer as a basic word processor.

Exams that only require paper, tables, and chairs can be done anywhere, and require minimal setup/set down, transport, or power, and no tech support.

I tried this with my CV, and it somehow scored me bonus points for GSoC!

   BONUS POINTS: 5.0
  ------------------------------
     Google Summer of Code (GSoC) participation: +5

Even though I've never done this, and don't claim to have done it in my CV.

That is a very confusing state of affairs!

Why would you need to pay $40 for a PDF of a paper published almost a hundred years ago? What makes the paper not public domain?

> I'm not saying that we shouldn't do security review of open source libraries, just saying that this situation puts a lot of pressure on the maintainers.

This is true, and worth saying, but it is also a problem of the OSS philosophy. All software is used at your own risk, so if maintainers want their software used they need to keep up, and the (true) promise of "more eyeballs means more secure software" has this downside built in.

But then "meant to" is doing the heavy lifting here. You could (and should) say that a JWT library is meant to default to secure.

I'm not the previous poster, but in my experience you can get a lot of mileage out of having dev teams (tediously, at least the first time) go through all potential vulnerabilities, decide how risky each one is based on likelihood and impact, and then get them to address the high/highs somehow (e.g. by upgrading a dependency, or writing extra code to guard against the issue, or fixing the issue if it's a home-grown vulnerability).

I'm not sure that's true. Jobs have moved overseas at a rapid rate in the past. What careers have been eliminated, and over what time period?

True. Perhaps it could be done using a Link header, although that won't give you the total number of records.

> That's a pretty simple view of native app vs web. Web will always have a lot of baggage that native apps simply won't have, layers and layers of abstractions that still needs to load.

Well, as I say, you can definitely have webview apps that start fast and aren't taking ten seconds to do things. Not just blank canvasses.

> https://www.rfc-editor.org/info/rfc10008/#section-2.8

Having a standard way to do pagination would be extremely useful. If we could add an items (or similar) range header type that would be excellent!

For example, in the HEAD response (and the QUERY response):

  accept-ranges: items
  items-length: 342

In the QUERY request:

  Range: items=0-9

You can definitely make a webview app that starts as quickly as most native thing (sub-1s start). We used Tauri and you wouldn't be able to tell the difference.

You could have a SQL library that defaults to inserting "OR 1=1" to every update query, which the SQL standard allows. I would blame the library.

E.g. doesn't mean historically.