Hacker Newsnew | past | comments | ask | show | jobs | submit | zmxz's commentslogin

European here. You're spot on with your question. Europe is an extremely hostile place to start a business compared to USA.

USA embraced capitalism and is geared towards proving concepts FAST and enabling networking. I love that about USA and I miss that in Europe, when it comes to IT/Tech sector in particular.

I'm not aware if Europe produced anything of significance in the past 30 years, we're lagging heavily behind USA/China and that's a fact. One could argue that Linus Torvalds is European hence Linux === European but I won't resort to such petty claims.

We produced very little value. We're having issues due to language discrepancy. Even though a lot of people speak English, it's often the case that we Europeans aren't able to communicate as well using English as we can in our native tongue. The lack of unified language is visible. The diversity in culture drives people to favor their own, we're bad at teamplay (this is from my personal experience and I am guilty of this).

There's many valuable lessons we could have learned from USA but we failed to apply them. We have various freely available systems that are great at, say, education - but education means nothing when it's difficult to apply it once people are done with it.

I worked with plenty of people from USA and I had huge prejudices towards them, in terms of "they talk a lot" or "they are not as competent, they are really slow when it comes to pumping out code" but I learned I was wrong to the point it's not funny. If anything, USA is really good at starting and pushing projects out that actually work.

Ultimately, do we even have a microchip factory (we might, but I'm unaware of it)?

Sorry for the wall of text, I just wanted to explain my POV and agree with you.

Personally, I'd love to see movement in EU's tech sector. We're 30 years behind USA in tech. I won't touch upon quality of life or similar topics because I'm interested in exploring technology.


Your mobile phone is most likely running a CPU invented in Europe (ARM). The next time you fly you are most likely going to fly on an airplane built in Europe (Airbus). When you buy your Ozempic you are buying a product invented in Europe. When you buy your prestige car you are buying a European car (Porsche, Mercedes, Ferrari, BMW, Roles Royce etc.) When you buy toys for your kids your are typically buying a European product (LEGO). When you buy your furniture you are very likely to buy European products (IKEA). I could go on and on ...


I am an American but the idea of Germany not having a competitive LLM right now is pretty sad and embarrassing.

As an American, It is really hard to understand how this can be for a country with such an incredible intellectual and engineering tradition.


It's not a lack of local talent. It's a combination of two governance problems:

1. Europe has no large data centers. It has no such datacenters because the Green movement is much more powerful in Europe than in America, and they have systematically blocked the expansion of gas turbine power in favor of over-builds of renewables. The result is Germany having the most expensive electricity in the world. It just isn't affordable to train an LLM in the EU. Notice how Elon Musk has imported gas turbines from around the world to power the xAI datacenter; that just wouldn't be allowed in the EU.

But, still, a German company could do so using US datacenters. Mistral in France has probably done it this way. But then you hit:

2. Copyright laws in Europe are more restrictive. Even in the US it's very unclear whether training an LLM on copyrighted works is actually legal, but the US courts are fairly efficient and US law has the concept of fair use, which is flexible enough to give them the leeway to decide it's legal. In Europe the fair use equivalents are either more restrictive or don't exist at all, and courts follow the local culture of being much less business friendly, so it's much riskier to attempt this. The EU as a set of institutions is much more in hoc to the press than people realize, and MUCH more so than US administrations are. They regularly side with copyright holders over tech companies in disputes in a mostly successful attempt to curry positive PR for the EU project.

It won't win me any friends on HN but both of these factors boil down to a lack of a strong Republican Party equivalent in Europe. I don't think Americans appreciate the extent to which their economic success is dependent on the strength of the Republicans, and they really should. If American conservatism collapsed or was taken over by the left, as has happened in parts of Europe, you'd be seeing the EU-ification of America very quickly.


> I am an American but the idea of Germany not having a competitive LLM right now is pretty sad and embarrassing.

> As an American, It is really hard to understand how this can be for a country with such an incredible intellectual and engineering tradition.

As a German, I would claim that getting Germans on a hype train is incredibly hard.

I also cannot see anything that is "intellectual" about these LLMs. To me, the whole LLM scene is rather like "rich alpha tech bros are tech-broing; a lot of sycophants in the inner circle of these tech bros attempts to use the dictate of the moment to become rich fast; and a lot of real or feign AI fanbois attempts to rid the hype wave to make easy money".


I think the hype train was the polymath omniscient oracle. With agents sanity seems pretty much restored.

With the absorption of entire markets the sober European view should be that the US approach was correct. Throw things at the wall until you have a wall full of things that stick. It looked pretty stupid until it didn't.


> With the absorption of entire markets the sober European view should be that the US approach was correct. Throw things at the wall until you have a wall full of things that stick. It looked pretty stupid until it didn't.

This approach only works if you have an insane amount of capital to waste ...


You don't know if it works, that's the whole point. European investors are like: How do I know 100% for sure this company will be a success? Why do I need this product? I have a car with chauffeur, why do I need a taxi app? I have a cook and a butler, why do I need a food delivery app? Pitching the LLM would be outright offending.


> You don't know if it works, that's the whole point.

I am aware of that, and this is actually my point:

Since you don't know what will work, you can easily have a long phase of "duds" in your investments until you get one big hit. If you don't have a huge mount of additional capital lying around, as an investor you will go bust during such a long "starvation period".

That is why I wrote that this kind of investment approach only works if you have an insane amount of capital to waste.


I think one can be more selective. Skip the unlikely long shots. Being first has its advantage and disadvantages, doing something reasonably early is good enough.

With an insane amount of capital you do get a more reliable % of success but with a single lottery ticket you still have odds to win.

If you are not in the game at all you certainly wont.


Europe backs up tons of hardware design which without that the software companies in the US would crumble like dust.


Looks like Elon was too busy farming in Path of Exile and now Tesla's customers have to wait until he asserts he's the god's gift to gaming first.


He paid account boosters and got mad when people called him out


There are claims this is faster. It's not. I used it, together with other "alternative" runtimes which are just PHP command line interface long running scripts with some sort of task distribution balancer in front. Just like PHP-FPM is.

The apparent speedup comes from the fact it's not shared-nothing, meaning that objects from previous requests (and variables) are persisted and present in subsequent requests. This makes it work exactly like Node.js, removing the wonderful part of PHP which is that it automatically cleans up all the crap devs created and creates clean slate when next request is to be executed.

All of these "alternative" runtimes are false positives, because they're quick for first few requests but get slower and slower for the subsequent ones. Then, the workers are killed and restarted (precisely what PHP-FPM does too).

Since there's no new engine behind executing PHP, the only way FrankenPHP (and others) can yield any performance is when they're benchmarked against misconfigured PHP-FPM (opcache off, JIT off, persistent connections off).

It's not my cup of tea. I like that there are attempts at doing <something> but turning PHP execution model into Node.js execution model isn't the way to go.

I find it cheaper to throw a few bucks at stronger hardware compared to risking accurate execution to become flaky because shared-nothing is now unavailable.


The right answer, as always, is: "it depends." There's no definitive "faster" or "slower" anything and the claim is "up to" not "you will get."

Some workloads won't see any benefits, others will. While your anecdata might be useful, it is just that, an anecdote.


It doesn't even depend. The underlying engine that executes opcodes is the same. Minimal speedup from not having to execute several "new objectname" commands isn't even a drop in the sea when it comes to what servers do.

I, for one, would love to be wrong about this and that FrankenPHP with all the other alternative runtimes actually brought benefits.


It absolutely does depend and "several new" might be "thousands new". It literally depends on what you're doing.

> The underlying engine that executes opcodes is the same.

Not exactly. FrankenPHP uses a ZTS build of PHP, which includes thread-support. Meaning you can actually spawn real-life threads in your PHP code with just a bit of work.

I've actually been working on a Parallel drop-in replacement that uses FrankenPHP/go instead of maintaining its own thread system.


It's obvious you have no idea what ZTS build of PHP does and you're just spewing nonsense at this point.

Creating a few thousand "new object" takes less than 5 msec. Test it. I have.

FrankenPHP uses a Go-based balancer that distributes requests to array of pre-started workers. Just like PHP-FPM does.

If you already used PHP's parallel extension, then you should at least know the difference between thread and process instead of typing buzzwords, thinking it makes you look cool if you use them :)


As a part-time contributor on FrankenPHP, from fixing bugs on PHP-src, and implementor of RFCs, I can assure you: I know what I'm talking about.

> Creating a few thousand "new object" takes less than 5 msec.

It depends on what you're doing in the constructor as to how long it takes.

> FrankenPHP uses a Go-based balancer that distributes requests to array of pre-started workers. Just like PHP-FPM does.

No, it doesn't work anything like FPM. Like, at all. There's basically nothing in common between FPM and FrankenPHP. (at least until I merge this next PR for non-worker requests that makes it work like FPM for non-worker requests)


> "there is no way I can get an error code from fopen()",

You can, it's via `error_get_last()`. We've had that for 17 years..


How do I test if this is EEXISTS and not, say, a full disk? Or too many symlinks? Or something else? Because last time I check it's not really possible, but maybe this has changed?


The problem is that you're trying to use PHP as if it's a different language.

If I have to deal with files, I'll create a class and I'll combine functions file_exists, is_file, is_writable, file_get_contents, file_put_contents (and new fsync) in conjunction with stream_context_create. I can even get the errors that OS spits out and test for what exactly went wrong, but you obviously ignored that and gave up. I can tell you used the language sporadically, not professionally.

You're taking a small, localized issue that arose, while your job as programmer is to get around idiosyncrasies in programming languages with the focus on achieving the end goal.

I've a list of terrible things that PHP does but I have one for JS/TypeScript/Go/Rust/<you name it>.

My job is to know these and achieve goals, not to criticize languages because file handling in it is not the same as in C++ and language didn't fire up 50 AWS instances to spam X.com with messages in hopes that I somehow notice them.


> I can even get the errors that OS spits out and test for what exactly went wrong

Coolio, so how do you do this?

I spent several years full-time working with PHP. I ran in to this several times. It's not a small issue. And my entire point is I can't work around it, because as near as I can tell, it just doesn't offer me the required primitives. That was certainly the case when I last looked at this, but that was a long time ago so maybe things changed?


Agreed and just to be clear, fopen() returns false if an error happens. If you don't check your return values, it's not on php, you're just not very good at your job.


Can you share precisely what "mishmash with a bunch of hidden landmines" is?

It's hard to trust a stranger from internet claiming something, but we are in IT so it should be relatively trivial to prove your claims, right?


One somewhat famous hidden landmine is in_array('0010e2', ['1e3']);

And that will return true, because you forgot the third "strict" parameter. This is really something strict_types could/should have fixed, but it doesn't.

You can have code reviews and static analysers and all of that to catch this, but it's definitely a landmine. I've seen some pretty serious CVEs that were fixed just by adding that last parameter to some in_array() call.


But I didn't forget the third strict parameter, because I'm diligent in reading documentation and at my job.

Was that everything? You basically state there's a problem because you didn't use the function correctly and language didn't fall head over heels to stop you from doing silly things due to slopiness?

P.I.C.N.I.C.


People forget this things all the time because people's brains don't work like Spock's brain. There are plenty of junior programmers around that will have to be taught this. It's a footgun. Is it manageable? Sure; I already said that. But that doesn't make it not a footgun. Anyone who says anything else is not serious.


Check this - if it's something important.. don't forget it and implement something called "function" that would pass the third parameter by default?

Anyone who is not capable of taking care of what you called footgun in a way where they automate - that person is not serious.

If there's a pretty huge problem - manage it. That's your job as programmer. If you're lazy, sloppy and prefer whining online over being proud of your work - there's no programming language that will take care of that for you.


If a function that causes security vulnerabilities if you fail to read the documentation diligently doesn't count as a landmine to you, what does?

Please provide examples in other languages (eg rust) so that I can answer your original question properly and to your satisfaction


No, it's not a function that causes it. It's the dev who is sloppy and causes issues. Would you blame the scalpel or brain surgeon for mishap while cutting important bits in the brain?

What kind of logic is this, to blame the tool because you have no clue how to use it?


That's a very good analogy because they had to stop using scalpels in brain surgery because the surgeons kept making mistakes.

Tools must be designed so that they're difficult to use incorrectly. That's why we have guards and interlocks on any tool more complicated than a shovel.


Function has 3 arguments. It's documented. Use cases are documented. You are trained. You ask for.. even more protection? From what? There's a limit to laziness, it takes more time to do this word-warrioring on HN than to learn how to use the function correctly and how to create a wrapper around it that serves as the protection you seek.

This really isn't that hard, we're not trying to travel to Mars.


Would you buy a car that explodes every time you start it unless you press the “don’t explode” button? And would you blame the people who get killed by this car for not reading the documentation?


So not knowing how to use a function in programming language is equivalent to a car exploding? Man, your logic is broken in ways that actually hurt.


No, a function that does a wrong and dangerous thing by default unless you tell it otherwise is equivalent to a car exploding.


That's why every serious PHP programmer is using a static code analysis tool nowadays.

It would easily catch this. https://phpstan.org/r/a827ff45-4ee2-4bee-8ae0-935832e627b3


You shouldn't trust him. He is sharing his experience with using the language.

I hate Rollercoasters, I hate surprises and strong emotions. So if you ask me how Disneyworld is, I'll tell you it sucked for me. But maybe you are onto that, so you shouldn't trust me.

Back yo PHP I've used it for super fast tiny dynamic websites, and it works wonders. I wouldn't do an online exchange with it though.


Exciting news! Glad to find out Serbia was the pioneer and helped create Apple!


I'm one of those who used Internet Explorer 5.0 and was there to complain about Internet Explorer in general. I'm not sure why you are amazed with Chrome transition, but let me give insights from experience.

We had Firefox 0.3 which was very, very slow browser but still much better than Internet Explorer. There was a lot of mental gymnastics involved to get pages display at least similar for both browsers.

When Chrome 1 was released, it was absolutely awesome. Minimal interface. Focused on browsing. Incredibly fast, it just executed JS stupidly quick and we could create web app interfaces that didn't lag

You can still download Chrome 1 and see what it's about. It was basically what users wanted: supports more CSS features than other browsers, starts fast, executes JS fast, provides adequate developer console, renders pages correctly.

It took all of us by storm because it was genuinely good software. That era was the era of good software, not spam advertising.

Today, in 2023. this is not true any more and you are entirely correct when asking why people would use Chrome. Answer is: laziness, lack of info, apathy, lack of knowledge.


> This protocol seems to also depend on JS

It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token.

> but some web apps use JS and sessionStorage on browser to store session token instead of using cookie

This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.


There are valid use cases and complex interactions between multiple systems where the only solution is client handling of user token.

Also, sessionStorage is a web standard and it is designed to store data to be used in the session. If you think frontend devs shouldn't use it because they are incompetent at handling XSS, then maybe backend devs should also not use databases because they might leave the port open to public internet.


> then it's gonna leave a bad impression

My company's frontend team (comprised mostly of people who believe anything written) jumped the wagon on Bun.

After a few days of working with it, it turned out that Bun isn't really faster in real world scenarios.

This brings up the question - why market it as so much faster then?

Many frameworks and tools market themselves primarily as faster than $otherThing but it won't fix suboptimal code, wrong choices for data structures, silly things like "let's select * and sort in browser". When you remove those mistakes that bad devs make, it turns out node/deno are more than fast enough. What we need is less bloat, more engineering and no lazy development by "packagemanager install lib-that-could-do-my-work"


>This brings up the question - why market it as so much faster then?

Speed is somewhat the main selling point. It loses in most other metrics to node or deno. I think speed is a dumb thing to have as a main selling point too; nodejs/v8 are already quite fast, if I needed more speed I'd try to optimise it, before then rewriting it to rust. I want stability, soundness, features, a good toolchain etc.


> After a few days of working with it, it turned out that Bun isn't really faster in real world scenarios.

Which scenarios? Are you sure it was using Bun and not Node? Is it using bun’s tools for things or the same tools as it did in node?


What parts of Bun were you using? All the features I've used (that work*) are faster, the hard part is the compatibility is still lacking so turning on the Bun runtime over just using Node is tricky.


> What we need is less bloat, more engineering and no lazy development by "packagemanager install lib-that-could-do-my-work"

Millions of voices suddenly cried out in terror, and were suddenly silenced.


So it wasn't the language, it was you? But it was the language?


Just like in C, where every buffer overflow bug is the programmer’s fault.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: