Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.
> Are people making user facing apps in rust with uis?
We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser!
At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely appreciate a 16x speedup if possible.
The engine being written in C++ does not mean the application is. You're conflating the platform with what is being built on top of it. Your logic would mean that all Python applications should be counted as C applications.
When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust!
(And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)
You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning.
In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been brought up as evidence in the first place.
Plus if things like work-stealing queues and complex synchronization are not relevant to editors, then editors are a poor example for demonstrating Rust's concurrency story in the first place anyway.
Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?
Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are.
To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law).
Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful.
The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
It reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer.
- "That's not even close"
- "Yeah, but it was fast"
Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty?
And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
It did not contribute to a yes/no answer, which is good, because it is not answerable with "yes" or "no", and the article points that out and explains why. So I would disagree; it does contribute to answering the question, in the form of spelling out why it is unanswerable.
Compare:
"Have you stopped beating your wife yet?"
"I do not beat my wife."
The response contributes to the answer, even if it brings you no closer to "yes" or "no".
The statement that is published places blame, if not accusations of criminal behaviour, on their business partner.
IOW, they already overshared with the intent of damaging the reputation of their business partner.
In my mind, they are already behind; had they released the standard business line "Our relationship with $X has come to an end; we apologise for any inconvenience caused" I wouldn't be so quick to judge them.
But, now I *am judging them, because they clearly felt personally aggrieved by what happened, enough to imply the worst without actually coming out and saying what happened.
There certainly could be harm if it's false though, which is the whole point. And they did not give any information to affirm who's fault (if anyone) it was besides hearsay
I would rather they published nothing. There is no need to make any of this public. Just stop selling Adafruit products and stop selling to Adafruit. If anyone asks, then you can say "we don't do business with them any longer". The public doesn't need the rationale.
That's it. Everything else is dragging the community/customers into a fight that they didn't ask for.
Something more concrete like "on Tuesday at 9pm an adafruit employee sent an aggressive email which violated our COC by calling one of our employees a 'stupid fuckface'".
I don't think that level of detail would be a privacy violation legally and imo not morally either
How about nothing and continue to resolve the matter privately? If you intentionally leave out important details and context then you're just manipulating public sentiment to gain leverage on the other guy.
If you can't publish a complete, detailed, specific description of what you're alleging, with names, dates, quotes, and whatever, then you publish absolutely nothing. Publishing vague and unanswerable accusations is scumbag behavior.
if they didn't want to say more, they should have said less.
the way that normal serious businesses handle situations like this is to simply stop carrying the product, instead of publishing vague, unverifiable accusations of wrongdoing. and then if somebody notices and asks questions, you'd give a statement like "unfortunately we could not come to an agreement to continue our relationship with this vendor, but we're happy to be able to continue offering a number of other comprable products".
There is no right to privacy, but they may have an NDA. Also, if they get too specific, they could open themselves up to a libel lawsuit. Though, if they were consulting a lawyer I don't think there would be any release. Simply cut business ties, and move on, it happens all the time, and would leave room to patch things up later.
> Maybe the AdaFruit founder said something unacceptable like "it's OK to be white" or "a man can't become an actual woman just by pretending that he is." That might explain the conflict.
Why would you just invent identity politics issues to be mad about?
> That person died in a car accident and they were wearing a seatbelt! But in any story not about this car accident people generally cast them as the useless.
This story isn't evidence that IRBs are always useless, but also it's not an example of them being useful. The thing this story shows is they are sometimes useless.
That seems like a bad faith reinterpretation of the context that the question was being asked in. The statement that the question pertained to was, "in any story not about this Linux kernel fiasco people generally cast them as the bad guys."
If a lot of money is involved, it's only a matter of time before all oversight is corrupt. Similarly, you can safely assume all data that is on an important (big money) topic is fake.
I did. Different genetic expressions. The intelligence to realize language is just memes, not truth.
Scott Adams put himself on a pedestal above anyone else in his comics; he was Dilbert. The only smart person in the room. He was always a celebrity obsessed with his own existence. Little difference between him and Tim the Toolman or a Kardashian.
Low effort contributor whose work people laughed at due to social desirability bias. No big loss.
That's a really wild, miserable reading of the strip. For one, Adams himself was a manager, not an engineer, so he had more in common with the PHB, or even dogbert/catbert than Dilbert. For another, he explicitly said Dilbert was based on a specific, undisclosed person he knew. For yet another, many strips were based on anecdotes/stories sent to Adams by his readers.
it doesn't take even a serious reading of Adams to realize he was dogbert, not Dilbert. He mocked Dilbert, he thought he was a loser that did understand how to manipulate the system.
We can't know for every possible program if it halts or not, but the complexity of programs we can determine is increasing as tools and techniques get better
That clearly may be doing some heavy lifting. It is assumed that trivial answer wasn’t what was intended for the problem, but unless someone asked Erdos, I don’t think we know.
Considering that he did some work towards the problem, tackling non-trivial cases, I think we do know. There's no way he wouldn't have perceived trivial solutions at some point.
http://scw.us
reply