royjacobs

That sort of proves my point, though. Spring support for GraalVM is ongoing and will likely be quite useable and mature out of the box.

The people jumping to Quarkus or Micronaut are more eager to chase the new shiny and are willing to spend the time debugging not-yet-mature stacks.

Edit: To be clear, the reply mentions fanboyism but we are talking about the maturity of a stack. Spring has been around for 20 years and is not going anywhere. Quarkus just reached 5.

They are moving there because it's new and shiny, not because it's better.

Spring and Spring Boot are incredibly productive and give you a ton of stuff out of the box, whereas some people actually enjoy writing a lot of plumbing code as a distraction/challenge from boring business code. Those people will migrate to "lean" frameworks because it will give them the opportunity to write more low-level plumbing code.

But what's your point? Would you truly want consumers of JSON Patch data to embed a JS interpreter?

Because that would require consumers to have a Javascript interpreter to use it.

The demoscene needs you back, Saffron!

This looks great. I hope it'll get a Switch port.

And in full resolution, too!

It might be more useful to talk to the people behind the tooling that is used during concerts.

For instance, Notch grew out of the demo scene and could be interesting maybe? See https://www.notch.one/

I only recently discovered Densha De GO! and apparently the most recent game in the series is based around this very line. Very interesting to see these photos, I love the vibe, and it makes me appreciate all the detail that went into the game.

That's a shame, but there's heavy competition from companies like PCBWay, I suppose.

Incidentally, I read it the title like Shapeways provided some files to somehow 3d print bankruptcy. I'm not sure why.

It's great to see Java Web Start finally being used in anger 24 years after its initial release.

"Should all array types be Copy but not Claim? If not, where is the cutoff, and does it depend on the element type?"

I think it was mentioned that something should be considered Claim'able if it can fit in a cache line. So I would guess that a heuristic could be used to determine which array sizes are valid to automatically implement Claim for.

I really like this proposal. It's fairly concrete, makes day-to-day coding much more ergonomic and, more importantly, doesn't introduce a great many esoteric concepts that are just going to clutter the language.

I'm assuming not everyone will agree with this, since it's more 'magic' but I'd argue it's the right amount of magic to help you with common patterns that you'd otherwise have to spend time manually implementing anyway (like the Dioxus Labs 'context' example).

"Yes, it's more complicated than server development in that it is a real-time, multi-point input, multi-output (rendered elements on screen) environment with synchronisation and concurrency needs."

I would argue that most backends typically also deal with more than 1 user at the same time (and in real time).

Are you implying that other new features are not useful? Could you elaborate, because I think a lot of the stuff being added (records, pattern matching) is super useful.

I'm wondering why the lifetimes as described in steps 2 and 3 need to be so explicit. Why shouldn't the borrow checker be able to infer them?

Where would it end, though? Should the developer also provide build instructions for Haiku and AmigaOS?

It's great that there's a free non-commercial option. I'm wondering if I can convert my existing CLion license to RustRover though, I only bought it for the Rust support.

My point exactly :)

It's probably good to know that the focus in the demoscene has shifted away from 64k more towards 4k/1k intros and 'regular' demos. The amount of work required to do a high quality 64k is so huge that, especially now that the demoscene is not as big as it used to be, a lot of people don't think it warrants the time investment anymore.

(Btw, the best way to prove me wrong is to write a 64k intro about it)

If you look at the benchmark code [0] you can see it indicates whether Rayon is used for parallelism.

[0] https://github.com/sarah-ek/faer-rs/blob/main/faer-bench/src...

Right, they got all of them, did they?

If the primary way the user is interacting with the package manager in this user-friendly distro is via the GUI then of course I mean the GUI when talking about the package manager.

Why not trust experts in their field?

As skyyler pointed out, my gripe is not with pacman but the fact that the author of TFA asserts that an OS is user-friendly even though it ships with a broken package management GUI out of the box.

I don't have a horse in the pacman/apt/rpm race since life is too short for those kinds of arguments and I'm sure they all have their pros and cons. Having said that, I'm not sure why having a preference for apt or rpm would be elitist though.

It's user-friendly if you think having a package manager that's broken out of the box is user-friendly.

I get that Linux is about choice, but if you're trying to make something that's user-friendly maybe also don't provide a dozen window manager options if your user can't meaningfully decide between them.

This reads as an article by someone who knows their way around Arch and has wildly different opinions about friendliness than most regular users would have.

Btw, nothing against RebornOS itself, I just don't understand the tone of the article.