Is there a list of MEPs who are just right, without the far prefix?

Just as with most parts of the EU (imo both it's strength and it's weakness) there is some complexity and bureaucracy involved with founding out the political spectrum of MEPs. You can research the EU political groups and the political alliances and the corresponding positions on these Wikipedia pages.

https://en.wikipedia.org/wiki/Political_groups_of_the_Europe... https://en.wikipedia.org/wiki/European_political_alliances

Yes. But if you look into the policies they push, they are all progressive for some reason.

Yes ?

> ASML relies on the United States for several of its components, and it’s this very reliance that has allowed the United States to use the Foreign Direct Product Rule and impose export controls on ASML products. However, there are signs of a shift. ASML has already started to reduce its dependence on American technology, aligning with the EU’s goal of strategic autonomy. Earlier this month, ASML announced a major investment in Mistral, France’s flagship AI startup. The Dutch firm invested $1.5 billion in Mistral, becoming the company’s largest shareholder. The deal was widely seen by policymakers as a move that strengthens European ‘digital sovereignty.’ In a sector dominated by American tech giants, ASML’s Mistral investment represents a growing realization from Europe: cooperation within the bloc is necessary for the EU to stay competitive in the AI race.

---

I don't follow, how exactly does the investment into a French AI startup reduce ASML's "dependence on American technology"? Is it a supply-chain dependence, or a revenue-making dependence?

> ASML

Who's the customer base of ASML? Are they predominantly based in Europe?

They are predominantly Taiwan, and South Korea.

> When you add distribution you cannot make as many assumptions

You absolutely can make all assumptions relevant to the handling/dispatching logic expressed at type-level.

> and as such you encode that into the type with a bunch of optionals.

Not necessarily, it can be `Alternative f` of non-optional compound types that define the further actions downstream.

> Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.

Not true, your business logic can be dispatched based on a single pattern comparison of the result of the `Alternative f`.

> handling dynamic messages

the dynamic messages have to have static properties to be relevant for the receiving program, the properties are known upfront, and there's no "decades-running trap of trying to solve this".

> there's no "decades-running trap of trying to solve this".

I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something. The fact that, even given a very popular alternative in that list, or super tightly integrated RPC like sending terms between BEAMs, basic questions like “should optionality/absence be encoded differently than unset default values?” and “how should we encode forward compatibility?” have so may different and unsatisfactory answers says something.

Not as an appeal to authority or a blanket endorsement, but I think Fowler put it best: https://martinfowler.com/articles/distributed-objects-micros...

It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

> I’m not as certain. The fact that we’ve gone from ASN.1 to COBRA/SOAP to protobuf to Cap’n’web and all the million other items I didn’t list says something.

> It absolutely is a decades old set of problems that have never been solved to the satisfaction of most users.

ASN.1 wasn't in the same problem space with CORBA/DCOM, both CORBA and DCOM/OLE were heavily invested in a general-purpose non-domain-specific object model representation that would suppot arbitrary embeddings within an open-ended range of software. I suspect this is the unsolvable problem indeed, but I also believe that's not what you meant with your comment either, since all the known large-scale BEAM deployments (the comment I originally replied to implied BEAM deployments) operate within bounded domain spaces such as telecom and messaging, where distributed properties of the systems are known upfront: there are existing formats, protocols of exchange, and the finite number of valid interactions between entities/actors of the network, the embeddings are either non-existent or limited to a finite set of media such as static images, videos, maps, contacts etc. All of these can be encoded by a compile-time specification that gets published for all parties upfront.

> basic questions like “should optionality/absence be encoded differently than unset default values?”

However you like, any monoid would work here. I would argue that [a] and [] always win over (Option a) and especially over (Option [a]).

> and “how should we encode forward compatibility?”

If you'd like to learn if there's a spec-driven typed way of achieving that, you can start your research from this sample implementation atop json: https://github.com/typeable/schematic?tab=readme-ov-file#mig...

When you say "any better than" are you referring to the runtive vs comptime difference?

You're conflating types with the encoding/decoding problem. Maybe your paying jobs didn't provide you with enough room to distinguish between these two problems. Types can be encoded optimally with a minimally-required bits representation (for instance: https://hackage.haskell.org/package/flat), or they can be encoded redundantly with all default/recovery/omission information, and what you actually do with that encoding on the wire in a distributed system with or without versioning is up to you and it doesn't depend on the specific type system of your language, but the strong type system offers you unmatched precision both at program boundaries where encoding happens, and in business logic. Once you've got that `Maybe a` you can (<$>) in exactly one place at the program's boundary, and then proceed as if your data has always been provided without omission. And then you can combine (<$>) with `Alternative f` to deal with your distributed systems' silly payloads in a versioned manner. What's your dynamic language's null-checking equivalent for it?

The article provides a contrived example and doesn't prove that ad-hoc polymorphism reduces type-safety. Even when `Maybe [a]` is being folded via `Foldable f` the claimed type-safety isn't reduced, it's the context of the folding that's being changed from `[a]` to `Maybe a`, and everything is type-safe. Secondly, if you really want to distinguish between the empty list and disabled allow-lists within your type-system you do define your own data type with that representation, and you don't declare it foldable, because the folding algebra doesn't make sense for any practical use-case of the disabled allow-lists. The language actually provides you with the means to reduce evaluation contexts your types can be part of.

> "Who cares?" was glib on my part, I admit. It was obviously stated from the perspective of an American relying on that power, towards other Americans.

> there is no "teacher" to stop the "bullying" here.

It's funny how the same person can mention "realism" and then proceed to "leverage" in the same conceptual realm of thought about the present day US. Just wait until three to four (insignificantly) smaller powers collude, target, and act against you like hyennas do, then try applying your leverage of ... what exactly?

"Realism" is not being used in the sense of the colloquial word, but as in "political realism," the framework that governs international relations between most superpowers today and in which "leverage" through hard or soft power is the core concept.

Cool beans