It's not unheard of, like when the South Korean government lost a bunch of its data in a data center fire. Don't have the only copy of your data in a data center, and you won't have to worry about such a thing happening to you.
It's a clumsily made point, but I think the gist is that the letter asks AI to align to a certain ideal vision of the field of math, that the math community itself is not well aligned to. I don't think the article makes this point well, though, just by listing these incidents. Don't get me wrong - each incident is important and worthy of attention in its own right, but I find the overall argument to be pretty weak and strongly reeking of whataboutism.
If it primarily targets infinite scrolling and autoplaying videos, those are straight-up dark patterns, and having less of them is good in my opinion. That said, I have no idea how likely any of this is to withstand the inevitable lawsuits.
This is by far the most perplexing part of this article for me:
> People at Git has started to work on a proposal to make the Rust programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip.
I've been programming for a longish time, and I've acquired my own set of opinions about programming languages, but I can't think of any that I dislike so strongly that I would need to boycott projects that use them under the hood. Moreover, even if we accept the "community of little extremist characters" claim for the sake of argument, is that at all relevant to the Git situation? I haven't seen any evidence that introducing Rust into the code base is the result of extremism, rather than just a mundane technology choice. Finally, when Rust is made "mandatory," it does not mean you must use Rust now, it just means that Rust is required to build the source code. The vast majority of people wouldn't even know that Rust was used. Even most Git developers wouldn't need to use Rust, since after more than a year from the original proposal, the Git source tree is still almost entirely written in C and shell scripts, and the amount of Rust code is basically a rounding error.
The whole Rust issue seems like a big nothingburger, and this reaction seems completely irrational to me.
rust solves a real problem. It makes it much harder to create a large class of bugs, bugs that are in most C and C++ projects (and many other languages). Sure, maybe rusteans have bad attitudes. Not sure that's true but I do get the annoyance of "I re-wrote cat in rust!".
We see these C/C++ bugs all over. Mozilla just fixed a ton of them, most of which would not have existed if Firefox was written in rust (see servo). That doesn't mean there would be zero bugs. It means there would be less. But by some accounts, a ton less, especially of the security issue kind.
And it's not just about the op, the op being a perfect expert programmer who never writes bugs. It's about someone quits, someone who doesn't know the code as well and takes over, they quit, someone who knows the code even less takes over, and in that world, the person adding a new feature to the app/tool/library is far less likely to add a security bug to a rust repo than an C/C++ repo.
> rewriting projects that have been working for decades
They have been working for decades AND are full of security bugs!
Switching them to rust generally means (1) the existing security bugs are gone (2) most future updates are far less likely to add new ones.
Note: I'm not a rust programmer. I'm a C++ programmer dealing with the fact that there are so many UaF bugs in our code with > 1000 programmers. We know more will be added because C++ does not prevent them and we're not perfect. Rust does, or at least it prevents enough of them to be worth it.
The friction is not an issue of the language or of toxic communities but the culture of how software is crafted and passed on. I use rust for hobby projects and besides the savety and soundness decisions, i love the tooling. Having countless [0] very restrictive guard rails like deny(clippy::float_arithmetic) for your usecases codifies intent about project structure in a way i have seen nowhere else. Not engaging with the benefits of rust but instead blanket-dismiss projects based on unrelated issues is irrational and i suspect its a phenomenon of older generations that grew up with C and never inherited eg. cobol on mainframes.
Your arguments make sense but I also understand how the OP may have such allergic reaction. I also have seen my share of young devs claiming this new thing is the best thing since sliced bread and that everyone shoud use it. This may be a new language or a new feature like objects. After many slices of bread you may develop an allergy to such fanatics, and react with an opposing force to their eagerness to conquer the world.
Allergy is a poor analogy here, since it develops by not exposing yourself. I can understand your annoyance, i got bitten by hypes aswell, including rust. I am not regretting it so far.
I believe there have been a number of crusades started around people's behavior and usually get a code of conduct book thrown at them. I remember a notable Python dev who had this happen to him, over sharing some humor from an old SNL skit related to a poorly chosen acronym for some tech, an otherwise extremely helpful and resourceful person got hammered and drumed out of the community. The rust community may have that same tone policing vibe. I enjoy and appreciate the value of using rust, and nix, both have this vibe at times and I make sure I "don't cross the streams" it sure has a stifling effect.
I'm sympathetic to hostility towards many members of the Rust development community, many of whom are left-progressives who think it's politically and morally important to exclude and socially-punish people who they view as being insufficiently deferential towards communities they deem marginalized.
But Rust is actually a better language than C, in multiple ways; and it is in fact bad that so much software in common use is still written in C. C is extremely hard to write correctly and hard to maintain; this fact explains a huge amount of security vulnerabilities in the widely-used software written in C. Rust mitigates this to a large extent, and is also just more pleasant to write because it has better syntactic and semantic affordances than C does - also better developer tooling.
I think that people who are not Anglophone left-progressives should use Rust, in part because I think it is bad that a highly useful programming language is associated with Anglophone left-progressives. Certainly, regardless of one's non-programming-related political beliefs, you should not ground your identity in making a virtue out of sticking to C.
I agree that the rust community tends to be pretty toxic, but I don't think that is a good reason to avoid tools just because they use rust under the hood. You don't have to participate in the git dev community, let alone the rust community, to use git as your VCS.
I think one thing about git needing rust (or python or Perl) is that each language dependency adds another good sized chunk of storage for the language and its tools/packager, I have a relatively light project using Tauri Svelte and code mirror, my build directory/cache becomes 18gb in the blink of an eye, that's a whole bloated modern operating system as a side effect of building a text editor, I should just wrap webkit-GTK around a redbean with some js libs in a directory, script the middleware in Lua and call it a day :D And don't get me wrong I like the development workflow with Tauri, it feels very performant, and easy to reason with, just the sheer disk space makes me boggle!
.. and even then there are other solutions like "GoT" - https://gameoftrees.org/ - which is interoperable with Git but written in that lovely OpenBSD C.
Okay, but I fail to see how this eventuality results in the end of ads. Owners of websites, at least the popular ones, won't stop running ads just because they don't strictly need to. We've seen this play out repeatedly with companies pushing ads to paying subscribers who are not paying a small amount to access their services.
The other unfortunate outcome I immediately foresee is that by adding an element of risk to visiting a new site (of wasting money on something useless, even a tiny amount), people will be even more inclined to stay within walled gardens they already know rather than explore the internet. This takes a problem we already have and makes it way worse.
> Okay, but I fail to see how this eventuality results in the end of ads.
I'd bet it goes down to 0 for 99%+ websites. A few big websites might keep it, but anything that inhibits the site from generating (meaningful) data, like users posting, sharing product feedback, describing fun things to do, showing pictures of an area, etc. will be reduced. What I am betting on is most sites opting for monetizing as data generation, rather than ad serving.
Please don't filter your writing through AI or use it to revise your writing. Learn to write well in your own words. Leaning on AI will make you a worse writer, not a better one.
Revision is an integral part of the writing process. I won't say it's the majority of the effort, since in my experience finishing the first draft takes more work than anything else, but I'd estimate revision is still like 25%. If you want to be a good writer, you need to learn how to do it yourself.
I think it's okay to use external tools to find spelling errors and typos. Ideally you fix them yourself, so you train yourself not to make them in the first place. Grammar checking should also be fine, and again, ideally you fix your own words. These are all things with pretty clear right/wrong answers most of the time (although rules of grammar can be broken occasionally by good writers).
You could also have an LLM review your work and give feedback, basically having it play the role of an editor. This might be okay, but I'd advise extreme caution. How well do you understand the biases of the AI model? Studies have shown that people tend to put way too much trust in LLMs, and anecdotally talking to people I know who use AI for various things, I've been shocked at how much they trust it. In any case, in this mode of interaction with the LLM, you keep your own words at the end, but it still won't necessarily make you a better writer unless you can pretty deeply reflect on what it tells you.
However, anything else where the AI directly makes edits to your work is by definition changing your voice unless it's really small stuff. You are no longer writing in your own words at that point.
> I love building startups, and they love writing code. For me, building projects is a way to make money. For them, programming is art.
At its very high points programming approaches art, but programming is primarily problem solving, which isn't fundamentally artistic because its main goal is correctness and fitness for purpose, not aesthetic value. I'm pretty sure for most of us the choice to use LLMs or not has nothing to do with it being art or not art. If I estimate a cost-benefit analysis, the true cost of using the LLM is much more than it would likely ever provide, so it makes little logical sense to use them except in very limited situations.
By the way, I have to say this is a really strange type of article, an explanation of the supposed opinions and attitudes of non-AI-users written by an AI user, seemingly without any input from the former group. It reads a bit as if it's building a strawman to justify the author's own views.
I don't know. I have a fascination with code structure which is definitely primarily aesthetic, not practical --- which is a compulsion I have to suppress when doing code professionally for practical reasons. (Sometimes you have to deliver.)
I find it incredible when the concepts in a system fall into place and start lining up and you get these unexpected relationships that "just work". It's beautiful in the same way mathematics is beautiful. It's lovely when something is made of lots of pieces at first and then suddenly collapse and simplify into a single structure.
I also enjoy other bits of programming. I like the flow state, I like the act of creation, I like feeling like I have an impact, I like being paid. So it's not like people fall into one category or another, and it's not like programming is one single thing. There's room within any discipline for creativity and for art.
I think many professional artists probably spend much of their time problem-solving, too --- authors trying to fit plot points together, sculptors working out which materials will work with which ones.
> problem solving, which isn't fundamentally artistic
I would argue that problem solving is actually what makes any art art. When making "traditional art" you are constantly solving problems. For example, how do I make this piece of rock look like a greek god, what parts to chip off, what tools to use etc.
Art is not always made for aesthetic value, most traditional art is probably created for profit. That doesn't make it not art.
I think you might have the (in my opinion wrong) notion that there is only one "correct" way to write code. This is not true, so much so that you can identify a programmer by their signature style. Similarly to how you may identify a writer by his writing style.
Mathematics also strives for correctness before aesthetics, but is often considered an art. Programming is little different imo.
When you have scoured your deepest understanding for hours - or days - in order to rewrite a function so that it is easier to read, shorter, more correct, and a thoughtful expression of your own insights and understanding; then you will see how programming can be art.
It is more than that in the sense that I have a lot of obligations to understanding the code. The reason is that if I don't understand the code, I will not be able to answer questions that are asked to me. And those answers are generally very important for the future of the business.
Code is art in the sense that I need to arrange it such as I can actually make it maintainable, readable, easy to add new features and make it that I can answers questions very easily.
LLMs remove this ability because it doesn't let me the time to absorb the change as such that I can guaranties those 4 requirements. It just concentrate on adding new features without making sure it doesn't break the other 3 requirements.
To guaranties those for 4 points, I need a mental map of the code which llm generally remove. The more we use llms, the less of a mental map you have of the code
I agree about the cost-benefit of LLMs being negative from a logical perspective, art aside.
I'm bothered by the exact quote you pulled from the article, although I didn't mention it, because it's reticent of a certain hypocritical hot take among founders and business/marketing types who can be "generous" toward their engineers because they believe that their own artistic contribution to the project is some messianic vision of it that far outweighs the quotidian questions about how it's actually built. I didn't really want to weigh in on what I felt was that tendency in the post, because I do work successfully with a lot of people like that and I often admire the sweat and work they put into their own side of running things... but those kinds of statements do come off as somewhat patronizing if they're not backed up by truly massive amounts of hard work.
I'll also paraphrase what I said then: I like the idea in principle, but there's a fundamental problem that makes me think it would be really difficult to use on my website. The problem is that code autoformatters typically work great in like 90% of cases, but the last 10%, they make worse. In "real" code, the programmer can often opt out of autoformatting in problematic cases by adding special comments in the code, but that's a non-starter for code samples on my site because it would look tacky.
So what I actually do is manually format my code and break lines at about 64 characters. This doesn't completely solve horizontal scrolling, but hopefully it's good enough.
That's not to say I would never use this idea. There's a threshold of "good enough" where it could become worth it even if occasional workarounds are needed.
reply