I've been locked from my apple id for two *months*.
Even though I:
- had my recovery password
- re-confirmed the email
- re-confirmed my phone
They just kept telling me "we'll contact you in two weeks", and kept not following.
Then after the 4th recovery they sent me my recovery link on email (in any case weeks later).
Worst of all? Their privacy and security they keep repeating like propaganda are beyond bogus. Sure, they de-logged me from all of my accounts, that I appreciate, but I had 0 issues accessing all of the contents on my hard drive if I was a thief with a simple script in recovery mode I could still access everything. Where's the security? Propaganda only non-technical normies believe and then repeat.
I'm never ever buying Apple products ever in my life, I've got MBPs that my clients send me, but that's it.
There's no need to take down and diminish other's contributions, especially in open source where everybody's free to bring a better solution to the table.
Or just fork if the maintainers want to go their way. If your solution has its merits it will find its fans.
While everyone is free to fork and maintain React. It's by no means an easy task, specially if it's not their job like Dan's is.
Plus, industry tends to gravitate towards what is popular. Network effects an all. So if a massively popular tool is subpar, the complications of it aren't without impact.
And no one is immune to criticism. LLMs are criticised for their sycophancy but some humans are no different when it comes to gatekeeping criticism.
Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO.
Little it helped that even React developers were saying that it was the wrong tool for plenty use cases.
Worst of all?
The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.
It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs.
Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant.
In addition, you could more easily inadvertently introduce security problems.
Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
> I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code.
I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation.
For low-level algorithms, of course, it's really hard to beat polished C code.
> Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant.
I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial.
> In addition, you could more easily inadvertently introduce security problems.
Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
The distribution I use already has limited security updates for Rust: https://www.debian.org/releases/trixie/release-notes/issues.... which reduces my security. The cargo supply chain issues are also very obvious, I am far more worried about this than I ever will be about memory safety, but hopefully tor reduces its reliance on random dependencies.
I find that surprising given that Debian breaks Rust programs up into individual apt packages, but ultimately, other distros do not have this issue. It’s also about userspace programs and not the kernel, which does not use external packages and so sidesteps this completely.
Debian forky has Rust in the kernel on by default.
Right, from my understanding, Debian was packaging Rust programs in the same way as C ones. So they’d update the individual library and it should be all good. They deduplicated all of the dependencies in their trees.
Do you think the sibling comment was flagged to "protect me" whatever that means, or is it because "Are you high on Prozac?" is not really a productive comment?
EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well.
The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)?
It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce.
This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
We could move past all the unproductive, polarized online arguments if everyone accepted that:
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.
That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal"
but the problem entirely boils down to what comes next:
3a. Therefore everything should use rust.
3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.)
3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
I want to preface this with "This isn't a gotcha".
I think you make an important oversight with these claims, which is that you can enforce logical safety over a memory unsafe language and have a much higher degree of safety than memory safety. Formally verified C doesn't change the language, you can in principle take C code run through compcert and compile it elsewhere. It's still a memory unsafe language, but we can express a much higher degree of safety than simple memory safety.
Another aspect to consider is that all garbage collected languages are memory safe. A language like Python actually has a far greater degree of memory safety than a language like Rust because it offers no ability to break memory safety (without calling into foreign code), while Rust lets you do it within unsafe blocks using raw pointers. That being said, anybody who would suggest using Python over Rust in a security-focused context is completely out of their mind.
In serious places where security is critical and margin for error is low, formal verification has existed for decades and is the standard. Any operation - specifically in the context where security is critical - which is not formally verifying its software is a mickey mouse operation, because they're fundamentally compromising on security to an unacceptable degree. I think it would be nice to have a formal verification toolchain and language extension for Rust to allow for full logical safety, but last I checked this area was still a work in progress for the language.
I know anytime Rust is brought up, someone brings up logical safety, and patterns are annoying. Rust obviously has a lot of tricks up its sleeve to automatically detect issues that a language like C++ cannot. Naive Rust is preferable over naive usage of a memory unsafe language. The problem is that in a serious security critical context, "naive" is completely unacceptable. If security is a core goal, there can be no replacement for fully blown logical safety enforcing strict behavioral and structural guarantees in every single facet of the codebase. I know the line, that logical safety is excruciatingly labor intensive and so the tradeoff with using Rust is that it affords some of the safety of formally spec'd and proven code. The problem is that the amount it affords you is completely marginal. The safety gap between C and Rust is much smaller than the safety gap between Rust and formally proven correct SPARK. It's just the reality. I'm loathe to see a future where marketing hype sees a degeneration of tools because it was presented as a serious alternative.
C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++.
You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top.
It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
> (So far, it's a not-very-complete client. But watch this space!)
Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job.
The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is.
But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters.
I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
From the looks of it, Rust is usable un a tiny embedded system but it is not "great". I think that out of the recent, trendy languages, Zig is the best suited for this task, but in practice C is still king.
The big thing is memory allocation, sometimes, on tiny systems, you can't malloc() at all, you also have to be careful about your stack, which is often no more than a few kB. Rust, like modern C++ tend to abstract away these things, which is perfectly fine on Linux and a good thing when you have a lot of dynamic structures, but one a tiny system, you usually want full control. Rust can do that, I think, like C++, it is just not what it does best. C works well because it does nothing unless you explicitly ask for it, and Zig took that philosophy and ran away with it, making memory allocation even more explicit.
Rust has no malloc in the language whatsoever. In embedded, you don't even include the libraries for dynamic allocation in the first place, unless you want to. And it's very normal not to.
It probably depends how tiny you mean. If the reason you can't allocate memory is because the only 1024 bytes of static RAM is all stack, then, yeah, Rust won't be very comfortable on that hardware. On the other hand C isn't exactly a barrel of laughs either. In my mind if I can sensibly chart what each byte of RAM is used for on a whiteboard then we should write machine code by hand and skip "high level" languages entirely.
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.
In context, I'd have no reason to deny that this is something you'd want to watch out for.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
This is true, no_std has no Rust runtime so it doesn't provide stack protection. I am aware of efforts to address this for embedded, but they're not available at the moment.
> Steve Klabnik has lied about that in the past, as he is wont to do.
1) I don't know what Steve has to do with anything I asked so it is bizarre to bring up and 2) I find this is to be a ridiculous statement.
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety.
So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug.
On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri).
The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
I might make such comments as long as other continue to make statements about Rust vs Cs. which I think are exaggerated. As long as people make such statements, it is obviously not a strawman.
I felt the same way when I read the bold part that says "But that C codebase is an issue" so I quickly checked out the public databases and couldn't find a single serious vulnerability in the past 7 years.
Admittedly I stopped after going through a bunch of useless stuff related to CVE-2017-8823 (which was initially reported as remotely exploitable with no proof at all).
I went through the tor repository (not vidalia though) and read a bunch of conversations about some of the memory related bugs but none of those were exploitable either (exploitable as in remote execution, not a DoS) and most of the (not so many) bugs were actually logical bugs.
I really don't care what they decide to do with their project and honestly anything that can potentially improve the security of such a system is fine by me but I really think they're doing themselves and the language a disservice by communicating the way they do.
Also, as a side note, even with a C codebase there is SO MUCH you could (and should) do to minimize the impact of a vulnerability that the fact that some choose to present just rewriting code in a different language is not even funny.
And of course, "impossible to refactor" just is very deep in the bullshit territory. "more fun to write new code" would probably be more honest, and the Rust proponents created a marketing narrative that allows them to do this while pretending (and probably also believing themself) to do a good thing.
If a codebase is being maintained and extended, it's not all code with 20 years of testing.
Every change you make could be violating a some assumption made elsewhere, maybe even 20 years ago, and subtly break code at distance. C's type system doesn't carry much information, and is hostile to static analysis, which makes changes in large codebases difficult, laborious, and risky.
Rust is a linter and static analyzer cranked up to maximum. The whole language has been designed around having necessary information for static analysis easily available and reliable. Rust is built around disallowing or containing coding patterns that create dead-ends for static analysis. C never had this focus, so even trivial checks devolve into whole-program analysis and quickly hit undecidability (e.g. in Rust whenever you have &mut reference, you know for sure that it's valid, non-null, initialized, and that no other code anywhere can mutate it at the same time, and no other thread will even look at it. In C when you have a pointer to an object, eh, good luck!)
Kanto is flat, it's the only region in Japan that could sustain feeding such a massive population and could allow building the first mega city on the planet.
Combine that with the massive engineering and rail experience Japanese have, and it's no surprise imho that combined with favorable geography they could build it quickly.
This is interesting analysis. Many good points. Regarding this comment: "first mega city on the planet": As I understand, in the modern era, Beijing was the first city in the world to have one million people.
The video itself might not be generated, but who knows about the script (quite generic Christmas Carol, Shrek, Wolf trope), the character design, the models, the animations, etc?
edit: getting downvoted to hell, but I think my question is valid. What does it mean "no AI"? Are we just limiting ourselves to the render?
It means no AI. If I say you used no AI but had an LLM write or refine the script, I would have lied.
You may be getting downvoted because your comment's tone can read as accusatively presumptive. "Who knows" isn't a useful contribution to almost any discussion. Which is a shame, because you raise an interesting point–I would personally feel fine saying no AI was used to do work even if I used AI to help me with research. (Provided I read all the primary sources.)
I think he's right. We have no idea if AI contributed to the ad in any way, so "no AI" in this context only means "not AI-rendered". The entire script might have been written by an LLM (which is perfectly fine by me).
On the other hand, the McDonald's ad is obviously AI-rendered, but all the concepts and prompts and choices might have been made by humans? Which doesn't make it any better (although it's not that bad, it's just average).
The overwhelming majority of swiss immigrants are either highly skilled individuals that the swiss population cannot produce in numbers or they do jobs locals won't do (cleaning, etc).
Good luck telling Swiss pharma or any other of their specialized industries to live without immigrants, they can close tomorrow. Immigrants are an insane boost to Swiss economy.
Also, I lived and been in Switzerland few times after, there's virtually no problematic immigrants. I've never ever felt the slightest danger, even walking at night with nobody but the kind of immigrants you don't like, you just don't.
Even though foreigners are overrepresented compared to locals (as in any other country in the world with immigrants they are the poorest and thus more inclined) the absolute numbers are very very low.
So no, higher or lower number of immigrants don't have linear correlations. Switzerland has an insane number of expats and immigrants as % of the population, insanely higher than the US or other countries like Poland or Italy, yet their crime numbers are fractional.
Find the market clearing price for unwanted jobs with domestic labor. Any job will be done at the right compensation. This is what UBI would do. I prefer this versus continuing to require an imported underclass. With my apologies to the conservative mental model, “starve the beast” but of cheap labor.
You know that 30%+ of Swiss population is foreign born?
36% of the workforce is foreign born.
In Zurich, Geneve, Lausanne, 44%+ of the residents are foreigners, and more than half the workforce is foreigners. And that's even ignoring how many people work there but reside in neighbouring countries (France border is close to Geneve and Lausanne is close and even has a boat between the two sides mostly carrying workers).
If you think that a Swiss national (which has several advantages from a hiring perspective) is going to be cleaning your toilet, no matter the money, without having higher paying options you're absolutely out of your mind.
Switzerland is a tiny country, it cannot grow endlessly in population.
Albeit it's density is lower than comparable Belgium, Switzerland is crossed by the alps so the real available land is much smaller, virtually all of the residents live in 30% of the space.
In any case, that's the beauty of Switzerland: Swiss citizens can decide for themselves. I've seen many referendums in Switzerland and I've rarely seen Swiss citizens vote against their interest. Proposals have often an initial support, which fades as people discuss it and investigate it more.
Populism has really low grip there, politicians riding emotions have little legislative power.
i'm okay w importing workers if they're treated the same as domestic workers. its the system we have now that incentivizes importing and abusing workers by somehow pretending that employers have no role at all in illegal immigration and only punishing the immigrants that fails miserably at everything immigration policy says it's supposed to do.
Ahh, but the purpose of the system is what it does. Would employers and countries import immigrants if they had to treat them the same as domestic workers?
Switzerland doesn't really have jobs locals wont do like other countries. e.g. cleaning pays enough that it's as respectable a profession as any other.
I've never ever met a single cleaning staff that wasn't foreigner, and I lived both in Lausanne and Zurich.
Low paying jobs are predominantly staffed by foreigners. Swiss youth has a huge array of opportunities even without education, let alone many interesting tricks to not work a lot and still make money.
> "many interesting tricks to not work a lot and still make money."
As someone not very familiar with Switzerland I'm curious what you mean by this, as I assume from your wording you don't simply mean generous benefits available to unemployed and low wage people?
It's markedly more difficult and expensive for even highly skilled individuals to obtain Swiss residency, speaking from personal experience. Unlike the rest of Western Europe where you can claim to be a Dr. Engineer on asylum and become a citizen a few years down the line so that you can threaten Christmas markets and take shits in churches without repercussion in future. Maintaining a low target population helps in the vetting process and ensures companies prioritize skill needs over lowering costs. The drawback here being it becomes more appealing for companies to export jobs abroad, at the citizens' expense.
Another country which has a similar strict immigration regime - Singapore. And for a direct opposite, there's the Gulf countries, which let everyone and their dog in, so that they can be part of the slaving class for the locals.
Even though I:
- had my recovery password
- re-confirmed the email
- re-confirmed my phone
They just kept telling me "we'll contact you in two weeks", and kept not following.
Then after the 4th recovery they sent me my recovery link on email (in any case weeks later).
Worst of all? Their privacy and security they keep repeating like propaganda are beyond bogus. Sure, they de-logged me from all of my accounts, that I appreciate, but I had 0 issues accessing all of the contents on my hard drive if I was a thief with a simple script in recovery mode I could still access everything. Where's the security? Propaganda only non-technical normies believe and then repeat.
I'm never ever buying Apple products ever in my life, I've got MBPs that my clients send me, but that's it.
reply