If any EU government people are reading this, I'd like to send you a short message:
Please stop thinking about the kids on the internet. But here's a brief list of things you must work on with higher urgency:
- taxing more large corporations,
- taxing more ultra-rich people,
- funding EU-made (open source) tech and infrastructure,
- let parents spend more time with their kids so they can actually protect their offspring and keep them safe from predators, more than any stupid law you think you can devise can do,
This! More taxes and - yes - more state-controlled tech! Wait. Why stop there? Let’s just bring back the SED and the Stasi too. Also, prevent people (the rich? yeah!) leaving Europe too with big walls [1]! I love your ideas comrade! LOL. Seriously, you should read more history books (and read it to your kiddos while you're at it, please). Peace.
I don't think that from my comment anyone can infer that I'm opposed to reducing general taxation. I'm, in fact, in favor in increasing taxes for who owns too much, not against reducing taxes to population with lower income.
Still, more tax burden for companies won’t make eu more competitive against the rest of the world. We need to dramatically cut down all the regulations, have a true one market, open capital market. I am still very much pro EU, but it needs to be reformed.
Honestly, I don't think the EU problem is taxation. Really, there's a long list of things that have higher precedence over that, for example, not being so immigration-adverse.
I don’t know where you live, but generally EU’s governments are much more in support of migration than their citizens. The big corporations want that cheap labour and they won’t pay the secondary cost.
One should care about tests more than how code was coded.
If I had a codebase with lots of tests and asked someone else to rewrite it to another language passing the same test suite, I honestly wouldn't expect a great quality job.
I say this because it happened 3 times in the company I work for: we conducted experiments by tasking different companies to rewrite the same code in another language. All of them passed (most) of the tests, but code quality was low. If the job is a black box, rely on the I/O to determine quality, not the inner workings.
I care that runtime developers know and understand their codebase deeply. 1M LOC written by 1 dev in a short time does not inspire confidence in such an important dependency.
There's no way this code is understood fully by the original author, let alone anyone else. I wouldn't accept this from an intern, let alone in code that's fundamental to my business.
I have seen, many times, code that has lots of tests but don't work.
Why?
Some of the patterns that I saw:
* The code is only called from tests but never called in production
* Tests are not testing the actual application logic, or the logic that matters. In some cases, the tests have nothing to do with the application code at all, because it does not even run any application code.
* Tests repeat the same logic as in application (tautology). All the time.
* Application code is actually incorrect. But tests just end up using the wrong expected value to make tests pass, disregarding what should happen.
That's using the latest models.
To make things better, apparently people never bothered to go through the manual workflow at least once to verify the behavior.
I think you and I don't share what is a "test". Are you thinking about unit tests? I'm thinking about unit tests, smoke tests, integration tests, e2e tests, functional tests, manual QA tests and probably even "the-product-works-as-expected-as-I-can-see-from-the-amazon-reviews-of-our-clients tests".
I agree with your point of view in general, but "having tests" doesn't mean "having great tests". If I rewrite my code and give the binary to our clients and they don't see any difference or bug, well, that means the rewrite passed the ultimate test. In fact, the percentage of our clients that care about implementation details (such as PL) is precisely 0%.
Sadly, yes. I feel too much "violence" on both parts.
Honestly, Zig community seems the most bitter for whatever reason, while on the Rust side it seems to me that are simply overstating how great the language is and are pushy in trying to convince the other of their ideas.
If this goes through, we can all take SWE lessons from it, but I think the communities will suffer.
Zig is a very interesting LOW level language, but honestly I think it should be considered for what it is: a better C. I don't think it fits for anything that someone would have written in C++, Java, Haskell or C#. Instead, Rust is competitive with all of these languages when it comes to safety, abstractions and speed. And also C and Zig itself.
Zig has a couple very interesting ideas that make it stand out: comptime and the zig build system.
Alas, Zig is still far from being stable. Rust came out to the public in 2012 and became stable (1.0) in 2015. Zig came out to the public in 2016, and it's 10 years now and someone says it's still years away from 1.0.
So, while rust took 3 years of public development to become stable, zig is taking 10/15 years. I love the language, but TBH I don't see a great future ahead, especially with LLMs advancements that can use safer languages to do the same work. There's no point in risking more memory bugs when the effort for writing code is the same.
Thank you, Jarred, for your work. It’s unfortunate to see so much backlash toward legitimate research. Bun is often seen by some as “the flagship project for zig” - especially among those frustrated with rust who want zig to "win over rust" for whatever reasons. At the end of the day, you should do what makes the most sense for your project and your circumstances, regardless of the language or tools involved.
Personally, I find this experiment interesting and I’m curious to see how it develops. Writing idiomatic rust requires a shift in mindset, so it’ll be worth watching how well LLMs adapt to that over time.
I can only speak for myself... but I've found at least Claude Opus to handle Rust very well, and in my own use cases WebAssembly (wasm) and FFI for interoperation with TS/JS has been pretty smooth.
Honestly, I don't know. I think it's because of frustration, but the community attitude is part of it. I experienced first hand people frustrated with Rust moving to Zig and finding other people to pick onto Rust and finding fertile ground (especially if moderators and heads of the community let this kind of behavior continue).
I wonder - has it been confirmed that no LLMs for PRs literally means no AI assistance for code?
While I haven't codified it anywhere, the policy I would like is for issues and PR descriptions to have no LLMs - there is no reason to ban code completely though IMO. I would say that would be pro human-communication and a stance I would like a lot.
Good, pro AI people produce poor quality in everything they do. They are the least creative and worst problem solvers. I don't want them near me or my work.
Yep, war is the shittiest of things and rarely it is described completely for what it is. Humans following orders are well known to be ruthless and humans in power places are known to abuse their power. Add this to brainwashing and religious propaganda and beliefs, makes this kind of war a particularly shitty one.
Please stop thinking about the kids on the internet. But here's a brief list of things you must work on with higher urgency:
- taxing more large corporations,
- taxing more ultra-rich people,
- funding EU-made (open source) tech and infrastructure,
- let parents spend more time with their kids so they can actually protect their offspring and keep them safe from predators, more than any stupid law you think you can devise can do,
- more trains.