The reality is that it's much easier to bring a lawsuit over damage done to shareholders (dropped stock value is measurable and easy to see, security fraud), than it is to bring a lawsuit over damage done to users (harm done to individual users is hard to measure).
HN user
TwentyPosts
Pretty sure this is generally called "Anarcho communism".
All of this could've been prevented if Go just had two ways to compile. Debug and release.
The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.
These new C4A instances are advertised as offering up to 50% better performance and up to 60% better energy efficiency than their current generation x86 instance types.
Hardware (see also, Google's TPUs and their performance vs. energy cost) is one reason why I'm fairly bullish on Google.
Is anyone surprised by this? Chris Lattner in high regard, sure, but I always expected them to have to quietly walk this one back.
It just didn't seem feasible, for a lot of reasons.
Of course, how feasible it sounded will depend on your interpretation of "superset". I wonder what was the straw that broke the camel's back.
Do we really need more syntactic sugar? Frankly, I am still confused why Python is going for a separate syntax for if expressions instead of just making its regular ifs into expressions
Zig is not even close to a 1.0 beta this year. Or even next year.
For example, the async problem still exists and still has absolutely no viable path forward, or even MVP approach.
Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.
And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)
I don't think civilians regularly carry military-grade pagers.
And fwiw, I heard of two tragic cases of children dying, which sounds remarkably low to me so far. If this were truly indiscriminate, this number would be significantly higher and we would've heard of it by now.
Apart from the issue where this ignores how many people got injured (a much larger number), there's a very simple "survival bias" reason (ironically) why this argument doesn't work.
Children (and potentially health workers, as opposed to men of fighting age) are much more likely to die of such an explosion than men of fighting age. In other words, children will be significantly overrepresented here.
Honestly struggling to comprehend how this one isn't neutral.
As far as we know this was a supply-chain attack specifically on military pagers actively used by Hezbollah, and (right now) it looks like most injured are in fact Hezbollah members (which makes sense, since no one else has any reason to carry such a pager). (With some sad and unfortunate exceptions.)
This is semantically not the same as a sum type (as understood in the sense of Rust, which is afaik the academically accepted way)!
Python's `A | B` is a union operation, but in Rust a sum type is always a disjoint union. In Python, if `A = B = None`, then `A | B` has one possible instance.
In Rust, this sum type has two possible instances. This might not sound like a big deal, but the semantics are quite different.
The original rust compiler was written in OCaml. That's not evidence it "had an influence", but it's highly striking considering how many other languages Greydon could've used.
HOTA?
You sound like you'd enjoy giving the Helix editor a try. It replaced neovim completely for me.
So now you're writing two compilers.
What did you actually gain from this, outside of more work?
Have you read the article?
As async is already used as an identifier in C#, the team decided to use async2 as a codename for the experiment. If that thing ever makes it into the runtime, it will be called async - so it will be a replacement for the current async implementation.
How much of a background do your have in abstract algebra? I don't think category theory makes much sense or is very satisfying unless you can already list a bunch of categories you interact with regularly, and have results which can be expressed in terms of categories.
The first time I looked at the syntax, it honestly looked like gibberish to me.
It's probably simple, but the control flow just felt convoluted.
Thank you
I had some issues with this very early when I got mine, but I think this went away completely. I feel like this was a software issue, and is now fixed (well, at least part of it).
I think the much rounder corners, as well as the round camera bulge look terrible. These were significantly better in the previous iterations.
Which Pixel was that? I'm really happy with mine (7a)
This like a bad idea on the first glance? Maybe I don't get the whole pitch here?
It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call. The laziness might be interesting, but I feel like "lazy strings" might be all that's needed here. Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.
One of the most powerful features of eg Helix is the ability to very smoothly and easily filter inside your existing selections, or to split them.
I think the focus here is on "selections", as opposed to just "cursors".
So for example, you can select all occurrences of X (say, usage of some global variable), then say "for each of these selections, select the whole function", and then say "select the name of the function".
And bam, this is a (somewhat artificial and forced example), but you assembled a list of all functions with a specific property in a few button presses without ever leaving your editor. This is very close to stuff I do all the time in Helix. This is a godsend when it comes to manipulating (for example) a huge array of JSON data.
Maybe this is all obvious to you, but this seems like the kind of thing that probably still feels like black magic to a lot of programmers, and which certainly hasn't reached all editors yet (most are not focusing on selection editing as a first-class usecase).
I believe it, I'm just surprised that I never thought of Apple as a big player here, and I'm wondering if this is an image problem on their side (rare, I know) or something else.
Hmmm, these are kind of boring? I've seen colored comments a few times, embedding images is also possible in Dr Racket and on TempleOS I'm pretty sure.
Where's all the fun stuff? Debugger features are neat, but outside of this these features just seem tiny and cute and not too exciting.
Even stronger support for structured Treesitter-based editing? (See eg. Helix), proper multicursor support (Helix), both already seem like black magic to me compared to what came before.
Wait, Apple releases papers? Do they have a name for their internal research division? When I think of companies doing AI research my mind generally jumps to Google DeepMind, I didn't know Apple releases any proper research papers at all.
I feel like a link to a 'pitch' or description of the Rhombus language would've been more insightful for most of us. Even being familiar with Racket, I don't know what Rhombus is.
They have an attack which stuns the player, followed up by a grab attack which looks a lot like them trying to bite(?) your head across a few seconds, doing immense damage.
I think it's probably intended to be that, yes.