Falell

Sounds complicated, but the goal of a fuzzable/sanitizable/etc libc sounds nice.

Lack of ABI stability sounds terrifying as an application developer. My other immediate thought was "how will this interact with systems where the OS-provided libc is the only stable way to e.g. make syscalls", and "Layering Over Another libc" addresses this. I guess the idea is you'd link an application against llvm-libc and the system libc, and ship llvm-libc with your application?

I've always liked "left and metric left".

It's correct in my experience. My mac refuses to recognize 2 independent monitors in the following setup: laptop -> USB-C -> dock -> 2x 1440p@144hz Displayport monitors. Supposedly this is because Apple doesn't implement the entire Displayport spec, I don't really know the details. My windows laptop handles this particular setup just fine, but forgets one of my displays at work every so often. It's a mess.

I've used it to edit a binary's rpath as part of relocating binaries that really want to be installed at a certain path.

You can do this yourself with e.g. hexedit if your new path is shorter but if it's longer you need something smarter, like patchelf.

I'm also not a fan of lichess's puzzles, especially on mobile.

Over the years I've been bitten for weeks at a time by a bug that fetches a batch of puzzles at a time on mobile, and then loops through those 50 puzzles repeatedly instead of fetching more.

Even when not bugged, this behavior of 'fetch N puzzles at once' heavily encourages rating ping pong, you get a batch of easy puzzles, get them all right so your rating jumps more than it should, then a batch of hard puzzles and get crushed. I found I only ever progressed on lichess after grinding meaningful improvement slowly on chess.com, then coming back to lichess to 'catch up my rating'.

I also quite like Chess.com's Puzzle Rush.

This is the core of "enterprise" things.

Many times clients, (especially paying business clients) care more that "things that worked yesterday should continue to work today" than about the enhancements, or even "breaking fixes", that you want to deliver for your product.

Grandparent, 2 posts up the tree.

What's the expected delay between reference card release and OEM card release?

Justify "largely", please.

I don't think Apple has demonstrated more commitment to "building secure devices" than to "building a tightly walled garden to maximize leverage over developers and users".

Edit: grammar

I feel like you're being intentionally obtuse. Civil disobedience is protest against a government, and is usually assumed to be non-violent. Look at Wikipedia, pick any result out of Google. Blocking a highway is classic civil disobedience, in line with making a human chain and blocking access to government buildings.

Equating these acts with "siege" screams bad faith to me, I feel like every example you've given is intentionally misleading or missing the point.

This definition of is ridiculous to me, implying that only the privileged few (policemen, those with specific knowledge) may be civilly disobedient.

The entire intent is for the masses, with no qualifications whatsoever, to make themselves heard in a way that cannot be ignored.

The victims are not the only people to whom this comment is addressed.

This isn't really directly related to your question, but I recall hearing that in Servo and Firefox, the usage of Rust is limited as it gets close to the DOM specifically because of interactions with the JS engine and its separate garbage collector, which Rust does not understand.

Without any more specific knowledge, I bet the way a generational garbage collector moves data around really messes with Rust's view of the world...

There are idioms that you can use to help. Bounds checking solves the classic indexing past arrays problem and you can use tools to prove that you never use e.g. the basic operator[]s on types for which it is not safe.

Some of these idioms are not zero-cost though. My understanding is that to prevent use-after-free you basically can't use bare pointers or references, at all, ever. You need shared ownership everywhere (std::shared_ptr, not 0 cost), a garbage collector (In c++ that's probably another smart pointer type, not 0 cost), or additional metadata like the lifetimes fed into Rust's borrow checker.

Based on my reading here on HN, I think Chrome has a reputation of using modern C++ features extensively to try to improve its memory safety, but it's really hard to do in C++.

Edit: I realized this answer sounds like "yes idiom will fix it". To directly answer the question of "can you use idioms to fix this", no you can't. Evidence shows we screw it up. It's broken and you can't bolt on fixes to make it work.

I use uwsgi at work, we've found a lot of bugs in the more interesting features of the uwsgi module, and had to fix some signal and memory leak issues (I think we're still trying to get them upstreamed). That said, it's reasonably fast and the WSGI interface in general is pretty pleasant to work with.

Yes. The common blurb is: In safe rust the borrow checker encourages 'fearless concurrency' by statically preventing all data races.

It works well over remote desktop... unless you have a screen tinter like f.lux. I didn't expect changing the light color to break the flash detection, but it does.

The ? operator is tied to std::ops::Try, and std::convert::From. https://doc.rust-lang.org/std/ops/trait.Try.html https://doc.rust-lang.org/std/convert/trait.From.html

More than that, as part of LINQ they built a whole "expression" engine into the language to make LINQ to SQL more powerful than simple method chains could be. What looks like function calls is actually converted into expression tree at the language level before conversion to SQL statements when communicating with a DB backend.

The method-chains-vs-expression-tree semantics don't matter much when doing typical in-memory map/filter/reduce on lists but make LINQ to SQL and other more complex use cases much more powerful.

The ParsedJson type is immutable and accessed mutating iterators (up and down the tree, forward and backward through members and indices).

My immediate thought is to compare it to rapidjson, which I've used before. The paradigm of mutating iterators seems awkward at first but should be just as powerful as rapidjson's Value. For example, both approaches end up doing a linear scan to find an object member by name.

The fact that rapidjson supports mutation of Values and simdjson does not has huge implications (as mentioned in the simdjson README scope section), I suspect this tradeoff explains most of the performance differences as I know rapidjson also uses simd internally.

It's not next, it's already being targeted. The recent Right To Be Forgotten case touches on a theme I think we'll see again - "we don't like what society does with easy access to certain information, and companies that facilitate access to that information are going to face increased scrutiny".

100 lines of code is not a meaningful amount of experience with anything, and surely cannot provide any meaningful advantage over the lifetime of a serious project compared to another developer who starts fresh.

Having "dozens of technologies" at this level of experience is often a bad sign. Very frequently candidates who mention lots of technologies like this on their resume or github can't answer the simplest questions about them, even "why should I use this, what problem does it solve". Source: Years of interviewing people with a laundry list of technologies on their resumes.

Should people be expected to remember everything about all tools they've ever used? No! Is trivial experience with something useful? Probably not.

How would this work? As I understand it pensions are almost never fully funded when they begin because the costs would be prohibitive. Can a smart contract guarantee that funds that are not available now will be made available at a later date?

Note: I like to read about Rust but don't work with it seriously, and don't follow Swift at all. Corrections welcome. That said, these seemed like the key passages:

"Swift has always considered read/write and write/write races on the same variable to be undefined behavior. It is the programmer's responsibility to avoid such races in their code by using appropriate thread-safe programming techniques."

"The assumptions we want to make about value types depend on having unique access to the variable holding the value; there's no way to make a similar assumption about reference types without knowing that we have a unique reference to the object, which would radically change the programming model of classes and make them unacceptable for the concurrent patterns described above."

Sounds like a system in the vein of rust but more limited, with more runtime checks and no lifetime parameters, falling back to "programmer's responsibility" when things get hard. The last paragraph makes it sound like one of the motivations is in enabling specific categories of optimizations, as opposed to eliminating races at the language level.

One of my biggest questions as a reader is how a language like C handles these cases that Swift can't handle without these guarantees. Is this a move to get faster-than-C performance? Does C do these optimizations unsafely? Is there some other characteristic of Swift that makes this harder than C? Closures get a lot of focus in the article...

If you want to migrate from system A to system B you don't start writing all data to B immediately. You don't know if B can handle the load, if your code is right, if double writing will cause an unacceptable slowdown etc. Instead you mirror a % of all writes from A to B and increase it over time.

Now you have a problem because B only has a % of the data. To fix this you need a separate task that periodically identifies records in A missing from B and syncs them. This is the "backfill" - it isn't part of your running application and is only needed for the duration of the migration.

Once you think you have sufficient data in B you can start checking your work, run a % of your reads from both A AND B and make sure the results match.

Once that matches for a while you can start making a % of reads from B without ever contacting A. When this reaches 100% you stop writing to A.

Each % here is a separate feature flag.

I think these statistics are claiming '50-90% of observed positives are false', not '50-90% of all tests return false positives'. Suppose 0.1% of the population has a condition and the test for the condition has a 0.5% false positive rate. If administered blindly, most positive tests will be false positives.