baridbelmedar

Let’s not romanticize it too much... A lot of enterprise systems are built by developers copying an old AbstractBeanFactoryFactory from a 2011 stack overflow thread without really understanding it :)

The EU as a whole is walking a tightrope. Its largest economies still depend heavily on the US market. If the current US regime perceives that US companies are being targeted by EU "taxes", regardless of whether those laws are legitimate, there is a real danger of US retaliation.

Key sectors could take the hit, including automotive manufacturing, industrial equipment, chemicals, electronics, fashion, textiles, and luxury food and wine.

Given that these nations are already managing high debt loads while funding generous social welfare programs and expanding their defense budgets, trade sanctions could cause serious damage...

So yeah...EU is performing a delicate balancing act here.

I'm not sure the "a year of document processing for under 100 USD/y" is such as great thing as you think it is (at least not for European competitiveness)... It means Mistral is essentially setting a revenue ceiling very low. OCR is a commodity at this point, and open source models, AWS, etc already do it out of the box.

Plus, you can't really build loyalty on a 100 USD/Y price tag. Since there are no switching costs holding them back, those buyers will leave the moment somebody offers a lower rate. An easily cloned, low cost tool with zero customer lock in is not a business. It is a feature.

That might sound great for the buyer (you), but it is a terrible strategy if we want a European company to compete long term against global competitors on actual product merit instead of just regulatory arbitrage.

The problem is that it encourages people to use excel for things that should never be in a spreadsheet in the first place. I mean if you're reaching for VBA, building complex PowerQuery pipelines, and writing nested LAMBDA functions just to process your data, imho you have outgrown excel. Just because you can build an entire solution in Excel because you already know the interface, doesn't mean you should...

Also, don't get me started on the newer functions such as XLOOKUP and Dynamic... Relational data belongs in a relational database. If you are joining tables and filtering massive arrays, you should be using standard SQL Arrays, it makes it so much easier to troubleshoot long term.

It's pretty common for business contracts to just end up stuck on mainframes or scattered across various systems from vendors like Oracle (the paper trails are often thrown away long time ago).

And let's be honest, a lot of folks in IT aren't exactly top performers and don't seem to care all that much. It's really the developers you find on forums like this who are genuinely passionate. You're not likely to bump into the people actually buying those big Oracle or IBM systems around here though :)

Playing devil's advocate...

Yeah, the ad supported model has its problems, but it also makes the internet way more accessible. If we think about it, companies and people with more money are basically subsidizing these services for everyone else. They're the ones seeing the ads that keeps the lights on for users who can't afford to pay.

If everything was subscription only, a ton of people like students, low income families, people in developing countries would be shut out. "Free" services, even with their flaws, create a kind of digital subsidy. It's not perfect, but it means way more people can use these tools.

Yes, but that's partly a consequence of how the German electricity market operates and the neglected state of its infrastructure, isn't it?

Wind power and other intermittent sources create grid instability, which drives up costs.

And to my knowledge, Germany has chosen not to have different bidding markets within the country (or has at least kept prices consistent across its four markets) to protect vital industries in the west?

Well, many industries rely on advertising to sell their products, and I wouldn't say those industries are inherently worse than others.

I understand your point of view, and I'm not saying you don't have a point. But something tells me that you would take a more pragmatic approach if your livelihood or that of a close relative were directly affected by the company's poor sales as a result. Remember, everyone's job contributes to sales, whether they like it or not :)

Agree, and Cloud Run's upcoming application canvas feature appears to offer a simple way to integrate the various GCP services together seamlessly without much hassle.

Imho, I think we've gone a bit overboard with Terraform at my company. Sure, it'll automate a bunch of stuff, but only a handful of people will really "get" it.

I think the rest of us who interact with it don't really fully understand what's going on. We've basically traded one set of scripts only a few folks understood (bash, perl) for Terraform in this case.

I totally see the benefits, but sometimes I feel like we try to force everything into it, even when it might not be the best fit.

> Unpopular opinion: I blame the new age devops culture that made cloud app deployments unnecessarily complicated with k8s and cool new tech (that'd get them high profile jobs.)...

Ah yes, time for the annual debate on the complexities of Kubernetes versus the unparalleled genius of custom scripts that seem to work...sometimes. Because reinventing the wheel is always superior to something with a standardized API.

And let's not forget the sheer elegance of a homegrown scripts that rivals the structured approach of Kubernetes. A true testament to intuitive design.

Sure, Kubernetes might have a few minor benefits beyond 'scaling out'. But honestly, who needs the ability to manage complex applications with any semblance of ease?

Maybe I'm doing something wrong here, but one issue I've faced when integrating third-party external systems with Pub/Sub and Cloud Run is the lack of an easy way to throttle the data flow when the external system falls behind. It would be really helpful if the Cloud Run service could easier support pull from Pub/Sub instead, allowing it to consume messages at a pace the external system can handle.

I could of course do flow control myself in the Cloud Run service, but it'd be nice if I could just switch to pull.

Same here! We're fans of Cloud Run at my company, but it'd be great if they made it easier to pull messages from Pub/Sub using Cloud Run. Sometimes you just don't want push.