chipdart

> It sounds like we’re converging on the same Twitter workflow over time, which is to just never use it at all, haha.

True, it boggles the mind the extents to which some people twist and turn to salvage the usability of a system that's compromised and managed so that it actively works against your best interests.

It's like enumerating a list of pro tips on what sprinkles to pour over shit sandwiches to make them less revolting. No, sprinkles are not a solution. The solution is to not eat shit sandwiches.

> I doubt there are even real humans behind some posts.

The topic of Russian bots pushing all sort of propaganda designed to destabilize western countries is a well known problem. There are already multiple discussions on stunts like blatant sock puppet accounts and poorly-built LLM-powered bots dumping massive volumes of propaganda.

This problem is well established. Until now the answer to this problem was relying on social networks to moderate abusive content and actively fight state actors from totalitarian regimes engaged in what is ultimately warfare against democratic nations. What makes Twitter stand out is how one of these totalitarian regimes ended up compromising a major social network and is using it's leverage to attack other nations with free reign. This is what makes Twitter stand out.

> Gosh you're totally right, the article has pitched this as a problem unique to Twitter, but of course Facebook and Tiktok et al (...)

Why do you think this is relevant, if the subject is Twitter's algorithm?

Your comment reads like whataboutism.

> If a $600 Mac lasts 5 years and still worth $150 and another machine loses all its value in six months (...)

Your hypothetical scenario is so absurd you didn't even noticed your catastrophical scenario falls well within any warranty period.

In the meantime, I own cheap miniPCs that I used as daily drivers, and they soldier on for years.

I mean, do you really believe that NUCs from Intel and AMD will simply fall apart if they don't have an Apple sticker on them?

> From my experience, TCO on most apple products ends up being roughly the same when you factor in resale value.

This reads like the epitome of Apple's reality distortion field. I mean, you're trying to convince yourself that a product is not overpriced when compared to equivalent products and subjecting customers to price gauging by asserting that you might be able to sell it later. That's quite the logical leap.

> You may just not be seeing the visual artifacts on your screen because you don't know what they look like, or mentally adjust to what that screen looks like.

Does any of that matter, though? Who bothers with the existence of hypothetical artifacts in their displays they cannot even see?

> I think this easily beats any sort of desktop PC you can buy at that price

Not really. Do a quick googling for cheap miniPCs from brands such as minisforum or Beelink. Years ago they were selling Ryzen5 and Intel i5 with 16BG of RAM for around $300. No "educational software" bullshit either, just straight from Amazon to anyone who bothered to click on a button.

> But wow, 16’th page of Google, that really is uncharted territory.

Would it make a difference if instead of querying google he was at the library of a Mexican organization for environmental monitoring reading obscure reports?

> So does the frontpage of WSJ (...)

Apples and oranges.

Reading the WSJ is a kin to subscribing to a specific Twitter user: you know what content to expect, and you are interested to read more.

Being force-fed political content you explicitly have not subscribed to is like you're reading the WSJ and out of nowhere you get pages from, say, MAGA's newsletter.

Not the same, is it?

> Oh, please. Nobody is saying that Rust is perfect (...)

This is the kind of fallacies that dominate Rust fanboy's discourse.

You start off by mindlessly commenting on "constant stream of CVEs", but when you're faced with the reality that Rust also piles up CVEs then you start to try to move goalposts around. Odd how you switched from CVE talk to vague allusions of "perfection", as if now CVEs don't matter.

That's the problem with your type of fanaticism: you stop makint technical claims and instead resort to sweeping baseless accusations,as if that was a positive trait on a language and it's community.

> “Correctly” isn’t a weasel word, especially not in the context of describing how a program functions.

It is. There is no way around it.

> My comment about easier to learn was written in the context of reaching the level needed to reliably write safe code (...)

Again with the goalpost-moving/weasel word combo.

Rust is notoriously unfriendly to beginners and imposes an unparalleled learning curve. Around a quarter of new developers outright give up and quit over how unusable it is to them. This is acknowledged by the Rust community itself as demonstrated by the last annual Rust survey. There is no way around it. I don't know why anyone would try to waste time handwaving over this.

> For example, Android reports halving their code rollback rate and a significant reduction in the number of vulnerabilities by (...)

Here's the problem with this sort of specious reasoning. You are cherry-picking an example of how a project invested heavily in memory safety and therefore ended up lowering vulnerabilities. You ignore how much work was invested into processes and prioritizing specific types of problems. You instead decide to ignore everything and anything, and opt to go the simplistic path of pretending that the only step required to achieve these gains is onboarding a magical tool, as if nothing else was a factor.

Do you understand how this blend of cargo cult mentality is silly and unproductive?

I get it that you feel the need to promote a tool you like. That's fine. But if you had a case you wouldn't feel compelled to frame all your arguments on artificial scenarios you try to pin on all other tools, would you?

> Well, that depends on information you haven't provided. Maybe your system does have an extra 900 MB of memory hanging around;

That's not how it works. You cannot make sweeping statements over how something is bad when you fail to consider how it's used and what are the actual real world constraints.

For example, you're arguing that minimizing memory consumption is somehow desirable, and if you're making that claim you need to actually make a case. I clearly refuted your point by clarifying how things work in the real world. If you feel you can come up with a corner case that refutes it, just do it. So far you haven't, but that didn't stopped you from making sweeping statements.

> The constant stream of CVEs (...)

It's a function of popularity and widespread use. The only languages that do not feature CVEs are the ones that are not used.

Eve Rust started to feature in CVEs, including memory safety problems in it's standard library. Somehow that fact is omitted from these discussions.

> (...) even experts failing to use those languages correctly (...)

I couldn't help noticing you felt the need to resort to weasel words like "correctly" to add color to an unsubstantiated personal assertion.

What's the best example you can come up with to support your opinion?

> C++ isn’t horrible but it’s harder to use, harder to find good developers (...)

This personal assertion is comical, as recruiters are systematically targeting C++ developers for Rust positions, and Rust is notoriously bad for newbies to onboard onto.

I'd prefer these debates were kept at an objective and substantiated level, but it seems that's too much to ask. It seems it's easier to throw unsubstantiated claims around and wait to see if half the bullshit sticks.

> Rust is the only mainstream language with an ergonomic modern type system and features like exhaustive matching on sum types (...)

This reads like a parody of Rust's fandom.

> Given that compute is often priced proportional to (maximum) memory usage, (...)

Let's look at numbers.

Hetzner sells vCPUs with 4GB of RAM for less than 5$/month, and 8GB of RAM for less than $10/month.

https://www.hetzner.com/cloud/

In my example, the cost of having garbage collection generation 0 events triggering twice a year would be an extra $5. If I wanted the frequency of these events to double, in theory I would save perhaps $2/month.

If I ran a web-scale service with 10 times the nodes as-is, we're talking about a $50/month price tag difference.

How much does a company charge for an engineer's hourly labor? How many years would it take to recover the cost of having an engineer tune a service's garbage collection strategy?

People need to thing things through before discussing technical merits.

> I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.

You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.

Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.

> Flutter is the best thing that happened to UI development since Qt. Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell.

Electron-based apps are also everywhere and they are through and through bad and a step backward. I would take caution to not do appeals to authority. I would extend this assertion over any javascript-on-a-webview-based GUI framework. Awful concept from start to finish.

The fact that you failed to give any specifics to support your superlatives leads to suspect that the comparison with Electron is well suited.

> Even whatsapp had about 50 members when they were handling billion users

I would add that running a service deployed to N regions is considerably more demanding and work-intensive than working on a releasable software package.

No one working on Flutter is woken up in the middle of the night by a pager because a user was not able to install a package, to then create a call to pull in half a dozen of Flutter engineers.

> This could explain a lot.

Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.

> A bare metal systems programming language can be used for web backend development. Let that sink in.

Hand-roled assembly too, and even brainfuck. What an epiphany.

Meanwhile this cargo cult is invested in toy projects to meet the bandwagon quotas of their cargo cult while the rest of the world goes on adding feature sets with a couple lines of code. And what's their tradeoff? At best saving cents on vCPU costs? Totally worth it, I suppose.

> There is no reason data isolation should cost you 100x memory usage.

It really depends on what you mean by "memory usage".

The fundamental principle of any garbage collection system is that you allocate objects in the heap at will without freeing them until you really need to, and when that time comes you rely on garbage collection strategies to free and move objects. What this means is that processes end up allocating more data that the one being used, just because there is no need to free it. Consequently, with garbage collecting languages you configure processes with a specific memory budget. The larger the budget, the rarer these garbage collection strategies kick in.

I run a service written with a garbage collected language. It barely uses more than 100MB of memory to handle a couple hundred requests per minute. The process takes over as much as 2GB of RAM before triggering generation 0 garbage collection events. These events trigger around 2 or 3 times per month. A simplistic critic would argue the service is wasting 10x the memory. That critic would be manifesting his ignorance, because there is absolutely nothing to gain by lowering the memory budget.

> There's no good reason to pick C/C++ over Rust in most of these cases...

What leads you to believe in that?

> Or, in other words, it's the unavoidable result of insisting on using a language created for the frontend to write everything else.

I don't think this is an educated take.

The whole selling point of JavaScript in the backend has nothing to do with "frontend" things. The primary selling point is what makes Node.js take over half the world: it's async architecture.

And by the way, benchmarks such as Tech Empower Web Framework still features JavaScript frameworks that outperform Rust frameworks. How do you explain that?

You should see the stuff that comes from Reddit.

> (...) the new Raspberry Pie Pico 2 is both orders of magnitude more capable than the chip used here and also around half the price.

That's cool and all but what are the tradeoffs?

Looks like a non-issue, and nothing left to debate.

I wonder why anyone would be trying to make a storm in a tea cup.

> I think one could claim that the editorial department was trying to make a decision that could/would be interpreted as a company stance, rather than a department stance, to the average person.

This makes no sense whatsoever. It is the editorial board deciding what candidate is endorsed by the paper. It is a company stance, made by the company's representatives on behalf of the company and based on the company's editorial guidelines.

> I think the implicit argument is that he wants to avoid more canceled contracts, along with other forms of retribution like personal attacks he experienced a few years earlier.

That makes no sense at all. If the primary concern was avoiding canceled contracts, it would be in his best interests to ensure that the guy who is threatening to cancel contracts out of spite would not be elected.

Pressuring the Washington Post to not endorse the candidate who does not pose that threat goes exactly against that.

It's something else.

> AWS provides latency numbers between regions, AZ's and within an AZ in network manager.

AWS also provides dashboards that shows what regions/services are down, and history tells us those are not to be trusted for precisely the same reasons.

> For this project and its day-to-day maintenance, unequivocally.

Insisting on personal assertions does not pass as a justification, particularly one based on such specious reasoning.

> One of Richard's philosophies is "freedom means being able to take care of yourself," (...)

That's fine. Irrelevant to the discussion, though. If you're really really concerned with somehow losing access to a build tool managed by a third-party, nothing prevents you from storing the tool anywhere, including in a separate Git repository.

Just say it's personal taste and technical merits play no role in the decision. All these wild claims just sound silly.

> The data remains standard JSON and so standard JSON parsers wouldn’t be affected (...)

No, not really.

The blog post talks about storing JSON data in a column-oriented database.

The blog post talks about importing data from JSON docs into their database. Prior to this, they stored JSON documents in their database like any standard off-the-shelf database does. Now they parse the JSON document when importing, and they store those values in their column-oriented database as key-value pairs, and preserve type information.

The silly part is that this all sounds like a intern project who was tasked with adding support to import data stored in JSON files into a column-oriented database, and an exporter along with it. But no, it seems an ETL job now counts as inventing JSON.