GolDDranks

I sincerely hope you'll manage to find a job!

What I meant was purely from the capabilities perspective. There's no way a current AI model would outperform an average junior dev in job performance over... let's say, a year to be charitable. Even if they'd outperform junior devs during the first week, no way for a longer period.

However, that doesn't mean that the business people won't try to pre-empt potential savings. Some think that AI is already good enough, and others don't, but they count it to be good enough in the future. Whether that happens remains to be seen, but the effects are already here.

After using Claude 3.7 Sonnet for a few weeks, my verdict is that its coding abilities are unimpressive both for unsupervised coding but also for problem solving/debugging if you are expecting accurate results and correct code.

However, as a debugging companion, it's slightly better than a rubber duck, because at least there's some suspension of disbelief so I tend to explain things to it earnestly and because of that, process them better by myself.

That said, it's remarkable and interesting how quickly these models are getting better. Can't say anything about version 4, not having tested it yet, but in a five years time, the things are not looking good for junior developers for sure, and a few years more, for everybody.

Edit time's already over, sorry for the confusing wording: *not only do I enjoy writing Rust

Happy tenth anniversary for Rust! I have been using Rust from 0.11, circa 2014, and I'm so happy to see it as successful as it is today!

These days I can in all truthfulness say that I don't only enjoy writing Rust –something that was true already 10 years back, despite frequent frustrations – but I am also productive and feel that the language provides what it set out to provide. That's something that certainly _wasn't_ true 10 years back. A decade of iterative improvement is nothing to sneeze at.

I hope stability without stagnation will continue in the coming decades. May Rust 1.174 in year 2035 be a thing of beauty!

I wonder if the author bothered to test their code (or used AI to generate the examples). The lifetime elision one simply doesn't work. Rust doesn't have an elision rule for two non-self input lifetimes.

Note that this is written by Graydon Hoare, the original author of Rust. He hasn't taken part in the project for years (I think he left before 1.0), so it feels quite special to see a write-up by him.

As a resident of Japan, I thought the exact same thing. (I'm also a citizen of an EU country, which would permit me to participate, but most of my colleagues couldn't.)

I've been recently using Zed, and I'm in love. It's the best editor experience I've ever had. Everything's snappy like notepad.exe, but it's also quite featureful, and quickly becoming even better.

The thing is, even it being used just in collections can lead to DOS, if the attacker can control the string contents, and selectively choose strings that your hash table stops being a hash table and turns into a linked list.

> Coding is another tool

Maybe to you. For some of us, it's also a form of self-expression, a hobby or a lifestyle.

In my experience coding for money and coding for fun is a very different experience. I know my worth, but I am also free to do whatever I want out of my working hours.

I haven't used Solid yet, but it is commonly said to have "fine-grained" reactivity, compared to React, and better performance.

I also think that Svelte, having a compiler, seems like that it would have an edge in theory.

At some point, the creator of SolidJS, Ryan Carniato did a stint helping developing Marko.js, a fine-grained reactive / compiled / a bit HTMX-like system, and blogged about that. It's a framework that originated from eBay. I'm now quite interested about the next version of Marko.js, Marko.js 6, and I'm gonna try it for my new project.

I'm interested in fine-graned reactivity so Svelte and SolidJS have been on my radar, but the HTMX-style approach appeals to me.

Here's something to munch on:

https://dev.to/ryansolid/marko-compiling-fine-grained-reacti...

https://dev.to/this-is-learning/marko-for-sites-solid-for-ap...

https://www.youtube.com/watch?v=Z1dd09rxny4

Test verify that the code works on specific inputs. Formal verification checks that it works on every input.

Via an unreliable, linker-based hack.

I think that for a guarantee as central as non-panicking, there ought to be eventually some kind of support in the core language.

(Just throwing ideas here, but there could be `#[never_panic]` for simple cases where the compiler can clearly see that panic is not possible, or error otherwise, and `#[unsafe(never_panic)]` for more involved cases, that could be proven with 3rd party tools or by reasoning by the developer like normal unsafe blocks.)

For more complicated guarantees, it's harder to see if there's enough common ground for these tools to have some kind of common ground.

Nobody really knows for black holes of these sizes, because we don't have a theory of quantum gravity, but I think that answer according to general relativity would that the curvature is steep enough that escaping would require going faster than c, the universal speed limit, so it doesn't happen.

My understanding is that they can't be _ultramicroscopic_, but they can be quite small. According to the Wikipedia:

> A primordial black hole with an initial mass of around 10^12 kg would be completing its evaporation today

And according to this:

https://www.omnicalculator.com/physics/schwarzschild-radius

Mass: 10e12 kg → Schwarzschild radius of 1.5e-14 m which is smaller than a hydrogen atom (5.3e−11 m).

I wonder what would be the mass that'd keep a black hole in thermal equilibrium with the current background radiation...

(Edit. whoops, minus sign in a wrong place made the calculations haywire, fixed now.)

Tried Knockout.js, Mithril.js, Marko.js, Rocket (Rust), none to be found.

Also, the site seems to have abysmal performance.

That's chilling. I always thought HN as a kinda level-headed corner of the internet.

> Typically, stuff like this gets flagged off the front page within minutes.

Why would that be, because it's too "political" for tech news? Or are there actual DOGE sympathies within the HN population?

I think it matches really well for the Zig ethos of "artisanal, minimal code". More than often, a type is strongly tied to how it is being used in the code base. In that sense, having it be tightly coupled to a data structure isn't much of a problem. The opposite isn't true, and the data structure is independent of the embedding parent data. The implementation of that data structure itself can still be presented as a library, and the "generic" parts carefully tested.

If you write a function that takes a _generic_ linked list as a parameter, you'd have a function that refers to just the linked list subrecord, and does only linked list operations to that and the linked nodes.

If you want to write a function that takes a linked list of a specific type as a parameter, you just take in a value of that type. The linked list is baked in, so you can get to the other nodes, and because the type is known, you can get back to the parent type from the linked nodes with fieldParentPtr. How to do that _safely_? I don't think that Zig embraces any Rust-like safe/unsafe dichotomy, so you don't.

If the transpilation itself is bug-free, why not? For static guarantees, provided we transpile Rust code that already compiles on a normal Rust compiler, the guarantees are already checked and there, and the dynamic ones such as bounds checking can be implemented runtime in C with no problems.

Okay, so the same idea that I spitballed in a sibling thread:

> Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right.

How does that work with animated meshes?

Interesting - low-poly (and 2D) are exactly where my interests are.

Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right.

I know about the advantages and uniqueness properties of triangles. However, if the article is correct about that artists prefer using quads when editing (I know absolutely nothing about 3D editing, and didn't know that, I thought triangles are universal these days), something is clearly missing from the pipeline if a neatly mapping textures to quads, then converted to triangles ends up messing the interpolation.

Maybe we can continue to describe the geometry in triangles, but could use an additional "virtual fourth handle point" data (maybe expressed in barycentric coords of the other three, so everything is automatically planar) for stretching the interpolation in the expected way.

Anyway, I'm just getting started with Metal, and this provided for a nice theme for experimentation.

I am definitely not an expert in 3D graphics... but this looks such an astonishingly simple and effective method, it makes me to question why this wasn't already thought of and picked up?

I get that with fixed-pipeline GPUs you do what the hardware and driver make you do, but with the advent of programmable pipelines, you'd though improving stuff like this would be the first things people do?

Anyway, gotta run and implement this in my toy Metal renderer.

I am especially fond of the `get_disjoint_mut` APIs. They're such a neat demonstration that Rust's fundamental borrowing rules are not that bad; it's just that compilers aren't smart enough to realise when things are OK. Sometimes language/compiler improvements make things better (cf. the Polonius project in Rust), but sometimes just neat API design can save the day. (Still, this API wouldn't be possible in the early 1.x days of Rust; the language improvements elsewhere (i.e. const generics) made it possible.)

Edit: almost forgot to mention why this API is dear to me: 8 years back I was one of the first to suggest something like this: https://github.com/golddranks/multi_mut At the moment, it was not feasible for upstreaming to stdlib, though (in my mind, mainly because checking an arbitrary amount of disjoint borrows would've required heap allocations back then). Later language developments made it shine.

I'm not an American centrist, but a Finnish centrist, which would make me... American moderate left maybe, but I'm very glad that more and more people are seeing what seemed obvious to me for years...

Thank you, you really are a sweetheart. And correct. But it's not easy to combat the anxiety.