di4na

I would not call it harm. The use of uring in higher level languages is definitely prone to errors, bugs and security problems

Depends who you talk to.

You are getting this wrong.

Basically the framework, like the Shield before, is the Commission trying to show "look, we fixed it".

Sadly, for the previous two times, the ECJ pointed out after the fact that no framework can fix the lack of data privacy law in the US, and that as such, the Shield, just like its predecessor, was not allowing what it claimed to do.

The Framework has not been tested in the ECJ so far, but the US has not significantly altered its laws so...

Why would you owe them something if you already provided the code and docs?

Can I recommend looking at what people studying Experts at work and how they manage to do better than they "should" be able to have found? There are tons of domains looking at this empirically :)

There is work in progress in the high-level inquiry that should manage to produce most of it. Besides that, you can try to check the appeals court reports, which are not too bad.

It happens to be even worse.

Because we have no way to detect all the cases.

A lot of the cases were handled in the "Post Office courts" (I don't remember the correct name, not a British), and there are more or less no records of them. So you need to ask people affected to come up and find ways to validate them, then create a case for quashing it. It is a total FUBAR mess.

I recommend reading https://pressgazette.co.uk/news/post-office-horizon-it-scand...

Private Eye definitely did a lot of work, but they were not the only ones, and multiple freelancers and journalists worked on it "in the shadows" for years.

The Post Office tactics of calling editors to make threats and play down the stories were also quite influential.

Note that there are already some of this stuff in the compiler for AOT. Using these new specs for AOT optimisations is going to be a far taller problem than catching some of the errors

Yes and that is what these analyzers do.

The problem is that your space grow really fast and that your compilers are really not built to extract that information in a few ms.

Even less to regenerate only part of it based on partial input. Even less when the input may not be correct syntax.

Also that linkage being kept is exactly what this post talk about. How to keep it intact through the different steps and transformations in your pipeline in a way adapted to the kind of queries you are going to need is... Actually hard and dependent on the query.

Which means that adding new features to your IDE would regularly need (and actually does need) a new way to store and query that data.

But yes. Reusing part of the rust compiler (or replacing some of them) in rust-analyzer is already something that happens and that maintainers work on.

It is just not that easy. But yes, C# and Roslyn in general was built with that in mind. Typescript too.

If you are interested in writing down more of what problems you have with scripting languages, feel free to shout me an email. Should be in profile.

I have been slowly working on a model of what problems i see in this domain and my own ideas to "fix" (or more like try to) them. So would love to see other perspectives.

yes but it is portable. On the lisps machine, you could not port to a different type of machine by another producer in general, even less across version. The Linux ABI is stable.

One thing i think forgotten here, which actually is in the Worse is Better talk. But people tend to miss it.

These ST and Lisps systems failed at another aspect. Reuse. The biggest change of the past 2 decades in software engineering compared to previous generations is the amount of reuse. It is tremendous.

It is hard to talk of cause and effects here, but mostly this is due to the Internet. At this point, the vast majority of code running on any proprietary system is... Open source infrastructural packages.

This condition a lot of the current ecosystem. You can only reuse code on systems in which said code runs well. As such, the Linux "stability" combined with x86 won, same as C and friends because of the tooling that made the code "portable".

Yes i know. It is far from magically portable, but it is far more than full machine living image SmallTalk or Lisp like.

As such, these "living code" are fundamentally evolutionary deadend. They are amazing but they cannot easily move to different machines and sharing parts of them is hard to separate from the rest of the living organism.

On top of this, a lot of the elements to make this kind of machine works does necessitate deep in depth expertise. As the piece shows, the Newton is a pale copy of the goal because they did not have that knowledge in house nor the time (or money) to create it.

Same thing all over the stack. A good efficient logger need deep expertise. Same for a good localization library. Same for a good set of graphic servers. Same for audio servers. Same for a http parser or a network library. A good regexp engine is knowledge knows by less than 10 people in the world probably.

Once you realise that, you realise that at scale reuse is the only realistic way forward for software so ubiquitous as it is today. And that is how we got the current FOSS ecosystem, not because the code is better but because it would need too many licences to be manageable without breaking the bank in numbers of lawyers.

Same thing for the Worse is Better. It works because it provides extension points and can adapt. Something the Lisp and SmallTalk machines fundamentally failed to provide. And that is something Richard Gabriel focuses on far more than the whole New Jersey schtick in his talk.

Google has longer tenure.

The thing you seem to miss are the other common denominator.

Huge amount of money and unreasonably far into the future expectations of returns.

Means there is no short to medium term pressure to optimise for efficiency or returns, which means one of the fundamental element of good engineering environment is missing.

These companies build in a vacuum of limitations in term of cost and a vacuum in term of goals.

Promise yes.

Reality on the ground is that there were governmental subsidies to implement them, so everyone got them.

How much they actually help vs create problems is still an open research problem

Tbf, i was working at one at the time. Finding the space in the chassis for the battery and adapting it and suspension to the weight of an EV meant they had to develop platforms for EV nearly from scratch.

Without any idea of the market demand. At the current cost of developing new Platforms (a few billions), you could understand being risk adverse. Low sales would have killed the whole companies.

Yeah a problem we were talking about a lot a few years back, before Starlink, was that SpaceX could not find enough market for the amount of launch they needed.

Starlink has been their solution to that but it is still an open question how well that makes money and for how long...

And we have not really seen a space market exploding behind it.

Ecto documentation is definitely i think one of our weakest point.

Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc.

But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest.

Sadly i do not have solutions rn but if people have ideas please come offer them.

You need both. As there are some things you cannot conpromise on. Like. Idk. Things factually impossible. Or Human Rights.

I spent 6 months exploring the Haskell ecosystem for these. The answer is no.

They are nowhere as easy. At the very least because their documentation is usually non existent or non comprehensible.

In my experience... Nope it is not really. Not to that extend. But sure i get you.

To extend, the answer is the BEAM itself. It ships with these tools built in.

From the whole zoo of system probing stuff or the downright amazing dynamic tracing.

Have a quick look at https://www.erlang-in-anger.com/

You are not wrong on that level, i have been slowly writing a language in Rust anc all these point are deeply felt.

And yet... The Rust ecosystem win. Easily. For a simple reason.

Salsa. Oh and also clap. Lsp bindings. Ungrammar. Miette. Clap. Parsers. Etc

At every level the Rust packages are far better and allow to drastically reduce the cost of building this stuff.

Note that illich is against cities. In his mind, a more atomised world would emerge from such a ban, more localised and focused on communities in neighborhood, with less dependencies outside.

So the only thing using roads would be emergency. Food would need to be local too or transported slowly by speed of walk or bicycle.

Which means that we would all be taxed pretty high for something rarely used.

You forgot the road themselves. Note that Illich also refuse train, so you have to build them with all logistic to build them on bicycles cargo.

On top of this, the ambulance we know how to build today are not the one from when we first managed to go faster than a bicycle (average human).

Which means you would be stuck at state of the art engine, car, brakes, etc from the 30s. Or maybe the 10s even, as it was already valuable in first world war.

Same for planes. Trains. Etc

And would we really build the infrastructure for them to actually drive on if it was so limited?

As the other answers point out, this fails to acknowledge the systemic impact of such rules.

My usual test for a lot of critics of current systems that offer something "far better" with nearly no downside compared to the current one is to ask if they could invent, develop and produce MRIs in enough quantities.

It is actually really hard to build systems that would. This is a taller order than you think.

I have. And I think it is definitely worth it to read it, because he brings a lot of clarity to a lot of things.

Buuuuuut. In the end, I think Illich fail his own test. He claims to analyze systemic impacts, but fail to recognize the systemic impacts of his own solutions.

I always use the "speed" example for this. Illich basically advocate for more or less banning the use of any mean of transportation faster than a bicycle. The arguments do make sense actually, in a lot of ways, and it is important to keep these in mind. But he acknowledge that there are real use case for engine driven vehicules and fast speed, for things like medical or emergency needs. Make sense right?

So from his pov, noone should have engine car, except for ambulance, medical transportation (like transplant), fire engine, etc. Where it becomes a net good.

What he utterly fail to realise is that without the fast transportation and the whole system built to ... actually build and distribute these cars to everyone, then building these emergency vehicules and developing the engineering for them cannot happen.

Not only it is cost prohibitive (because of reuse of means of production, mass production impact on cost, etc) but also it is really hard to actually engineer this stuff without a lot of experiments and needs for it, which do not happen if you restrict the use of these stuff to a limited niche.

Engineering need practical use of the tool to be able to learn about the use to make it more efficient and better to the point that it benefits everyone. That of course does not negate the point that these technologies do have negative impact on society. But thinking that you can wholly separate the positive from the negative, banning the later but getting the former, is not as simple as calling it out. You need to consider the systemic effects and really think through the long term and systemic impact of your action.

Something that Illich seems to only apply to other people actions, but not to his own remedy or analysis.

I am unashamedly stealing this one, it is both apt and making me smile. Kudos

Yes, mostly on the durability side. NVMe actually has the relevant API to be sure that a write was flushed, while posix like filesystem API usually do not handle it.

Yes. That plus the way apple implemented it.

In my case i was already on passkeys and google decided to just... forget them all on my other computers. I can't use them to get in anymore. Why? Who the heck knows.

This whole passkey shit is going to be a nightmare for UX.

I mean the problem is that we have quite good evidence of how to handle architecture and system designs problems. And it is not by finding them earlier.

But by reducing their costs through looser coupling and incremental work. That is where all kind of agile and DevOps research showed.