estebank
Joined 14 years ago
Karma
6,196
Submissions
1,901
Member since
Jun 6
[email protected]
View on Hacker NewsRecent submissions
Comment · 5 days ago
Perspective is still at play. At arms length, on my phone, if I make it so the flat surface is completely aligned with my center of vision, the bottom side covers at least 1mm of whatever is on the underside. The closer one gets to the phone, the more pronounced the effect.
The video keeps triggering my sense of seeing CGI, but the hiding effect on display can absolutely be accomplished in camera.
Comment · 6 days ago
If you think this result with those odds is unexpected, you must have never played X-Com :)
Comment · 8 days ago
The big album art?
Comment · 11 days ago
The "hint" you could provide today for polymorphization is to write code like
fn needs_string_like(x: Into<String>) {
fn actual_logic(_: String) {}
actual_logic(x.into())
}
Comment · 11 days ago
The Rust toolchain by default produces a lot of debug information for each crate being compiled and the language relies heavily on monomorphization (instantiating a different function/type for each combination of generics) which translates to generally having duplicated functionality where the only difference in the object code is the different types. These two things combined, along with large dependency trees and that "features" for conditional compilation cause the same crate to be considered different across different workspaces (meaning the rlibs that were created for one can't be reused for another), means that the target directory for Rust projects can quickly grow. That, + clippy not having stabilized an already implemented process to automatically delete files from the target directory when they are unlikely to be needed again (which can't be 100% accurate, it uses heuristics because a developer could always potentially need an exact rlib from 6 months ago, it is just unlikely) means that you can expect that under the default configuration your target directory ends up being huge after a short period of time.
A lot of those things are in different stages of being fixed. I would personally want the default for generated debug information to be changed. cargo gc will help with running out of disk space. Better cross-project reuse of existing rlibs could be accomplished with some better tracking of optional features that can be unified (think having `serde` with feature `derive` enabled in one project, and having it without it in another: features are supposed to be purely additive, so you could reuse the earlier rlib on the later, but in practice people (ab?)use features in non-additive ways so it isn't straighforward to do something like that by default). Tools like hakari lets you create workspace-unified Cargo.toml to emulate this behavior.
Comment · 11 days ago
A partial solution that avoids you spending money is to stick `debuginfo = "line-tables-only"` in your `Cargo.toml`.
Comment · 17 days ago
> Rust is managed by the Rust Foundation
This is not quite true: the Foundation handles things like receiving and distributing some payments, helping conferences, employing people for operations (crates.io), and ownership of the trademark. But Rust the language and toolchain is managed by the people doing the work https://rust-lang.org/governance/
> It’s completely possible that Rust’s compiler contains a backdoor. And nobody would know. Now this last point is highly speculative and conspiratorial,
Yes.
> but I’m not the only one concerned about it.4 The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation.
Or using https://github.com/thepowersgang/mrustc. And it is not released by the Foundation.
> Since there exists only a single fully-functional, usable implementation of the Rust compiler, the Rust Foundation must be trusted.
> Considering its history, owners, and track record of issues with mismanagement,5
The linked to blogpost is about a fuck up that a subset of people in the project, who were responsible for RustConf, caused. The ones with leadership position stepped down from them out of their own volition. The Foundation in particular had absolutely nothing to do with the whole fiasco.
> I find it hard to trust it at all.
> My suggestion is: slow down. First, the community should focus on improving the Rust language itself instead of trying to “improve” other projects by rewriting them. I propose using that energy to help the GCC Front-End for Rust project6—an alternative compiler which would alleviate the concerns for the possible presence of a backdoor. Currently, it’s in an early phase of development.
Who is the OP talking to? Slow what down? Because there are people working on https://github.com/Rust-GCC/gccrs. I don't work on it, because I do what I do on my spare time and I find it more rewarding to improve the user experience of rustc itself, instead of implementing the same logic for the third time in a language I don't particularly enjoy. Others are equally disinclined to work on a C++ frontend implementation. The project certainly spends its time focused on improving the language. It is also hard to tell people in the Rust Project what to do: it is open source, it is a showupocracy. The people working on it are already at their limit on what responsibilities they can take on.
If the target audience of the blogpost is "the community", I also think it misses the mark. The "X rewritten in Rust" announcements I would see before LLMs would be the projects' own maintainers desiring to use Rust, and not external sources imposing it on others. There have been over enthusiastic people (and trolls) bothering projects in issue trackers and mailing lists, but I've never seen a level of volume commensurate to the meme's fame. (Nowadays I see vibe-coded projects done in Rust, but those are also not imposing their codebase on other existing projects beyond sucking up the air out of the room and making it annoying to read news aggregators due to high volume and low quality).
> And the people associated with Rust often don’t seem to have the best intentions in mind, or are just following a trend without thinking for themselves.
That's quite a view you have of people like myself and my colleagues. I have significant disagreements on how some facts and opinions are framed in the blogpost, but closing with stating that I and my colleagues in the project are ill intentioned and/or don't think for ourselves absolutely ensures that I won't be listening to anything else you have to say in the matter.
Back when Twitter was a thing I'd spend time searching for "negative Rust sentiment" because it was an excellent way of finding unpublished feature requests and real issues that needed to be addressed, after sieving through the less than productive way those real problems were presented with. This latter emotional labor was also the reason that it caused a round of burn out, until I realized that if something is A Problem, more than one person will ultimately hit it. Which means that if there are two people raising the same point, you don't need to waste your time engaging with the one being an asshole, and instead spend your time engaging with the one that will be productive.
Comment · 23 days ago
It is literally a requirement for that kind of Visa.
> Employers must attest to the Department of Labor that they will pay wages to the H-1B nonimmigrant workers that are at least equal to the actual wage paid by the employer to other workers with similar experience and qualifications for the job in question, or the prevailing wage for the occupation in the area of intended employment – whichever is greater.
Comment · 1 month ago
Rust doesn't let you write an impl a trait that wasn't declared in your crate for a type that wasn't declared in your crate. At least one of the two needs to be locally declared. This makes splitting projects into multiple crates harder than it could be, but on the other hand it makes the crates ecosystem less brittle than it otherwise would be.
Some people propose relaxing this rule for "workspaces" (local projects with multiple crates that are not published individually). I haven't researched whether that would be technically feasible.
Comment · 1 month ago
> Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
I fully expect that if wild delivers an effective incremental linking architecture, then rustc will be able to produce the patches directly (instead of wild having to produce patches from two versions of the object files), which would mean both that rustc is producing less LLVM bytecode and that wild gets to do what it (will) do best and make linking as fast as mechanically possible.
> This seems absolutely insane to me given how pervasive macros are in Rust
There was some work done on this front, but I haven't kept up to date on the current status of that. There was a PR showing promise https://github.com/rust-lang/rust/pull/129102 (later landed as https://github.com/rust-lang/rust/pull/145354, 10% on a specific serde-heavy crate, reports of 32% improvements in the original PR). The tracking issue doesn't have any updates https://github.com/rust-lang/rust/issues/151364, but you can try out nightly with -Zcache-proc-macros to see what the effect could be on your projects.
Part of the problem I see is that crates will have to opt-in (and we might be able to change the default over an edition boundary) to get the perf benefit, and it might require a granularity lower than "a crate" (which would complicate implementation). I haven't seen additional discussions around these design considerations (needed to stabilize), which will need to happen before people can see progress.
Sadly, Rust is, like many open source projects, a show-up-o-cracy: you need a motivated (group of?) individual(s) to deliver a feature to fruition, and if the person driving a feature is fine with using nightly for their purposes, and only needs a subset of a feature, they will drive the feature to that state (lets say 80% completion), and then the feature will linger (until someone else with enough motivation to see the other 80% through shows up). This is exacerbated because the project is unwilling to have 80% solutions on stable unless the state is very clearly not going to preclude other future work, or the path to completion is 100% visible (but if that were the case, then it would have been completed already). So we end up with situations like the Allocator APIs.
Comment · 1 month ago
For symbol heavy projects, linking is a surprising bottleneck.
Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).
Another thing is that stable rust doesn't treat macros as idempotent (because that wasn't a requirement from the start, there are crates that do dynamic IO to generate types), but if they are then incr comp can be faster by not evaluating them unnecessarily.
I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I'm looking forward to the fruit of their labor.
Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.
Comment · 1 month ago
The solution is to make changes so that the bus doesn't take an hour and a half for a short distance. Like a dedicated bus lane during rush hour on a bridge.
Comment · 1 month ago
I've never been in any public transport that had a bathroom. I've only seen them on long distance buses, trains and planes.
Comment · 1 month ago
It is likely a crapshoot, and while that list is informative it is necessarily a snapshot in time. FWIW, my banking apps have worked with no issues and have worked continuously since I migrated to GrapheneOS. I do have Play Services installed to be able to use Android Auto, and that required some fiddling with permissions before it started working, so your mileage may vary. By far the biggest annoyance for me is group text messages not being delivered while using an alternative user account, but that's a niche setup I guess.
Comment · 1 month ago
> None of these ideas in zig are novel.
Few ideas are new under the Sun. But the inventor and the popularizer are rarely the same. We should be happy that the ideas got more exposure instead of litigating novelty.