mirashii

This comment from a dupe thread is worth considering: https://news.ycombinator.com/item?id=46137352

I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived.

My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on.

> What are the chances of that, though?

The whole premise of the article is that they’re substantially lower, because some time for the ecosystem of dependency scanners and users to detect and report is better than none.

The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.

It feels like perhaps you’ve conflated the issue in this thread, which is about using Rust in apt, which is much, much later in the distribution bringup than this bootstrapping, and using Rust in something like the Linux kernel, which is more relevant to those types of bootstrapping discussions you posted.

apt is so late in the process that these bootstrapping discussions aren’t quite so relevant. My point was that at the same layer of the OS, there are many, many components that don't meet the same criteria posted, including perl.

> I think this is the wrong way to promote rust

This is entirely the wrong lens. This is someone who wants to use Rust for a particular purpose, not some sort of publicity stunt.

> I know nobody that programms or even thinks about rust. I’m from the embedded world a there c is still king.

Now’s a good time to look outside of your bubble instead of pretending that your bubble is the world.

> as long as the real money is made in c it is not ready

Arguably, the real money is made in JavaScript and Python for the last decade. Embedded roles generally have fewer postings with lower pay than webdev. Until C catches back up, is it also not ready?

> Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized,

This is the status quo and always has been. gcc has plenty of extensions that are not part of a language standard that are used in core tools. Perl has never had a standard and is used all over the place.

No, it’s a valid question, and one that I’m sure will get some answers in the coming days and weeks as the discussion on adding this requirement continues, but in some sense, it’s beside the point.

The cost of supporting this old hardware for businesses or hobbyists isn’t free. The parties that feel strongly that new software continue to be released supporting a particular platform have options here, ranging from getting support for those architectures in LLVM and Rust, pushing GCC frontends for rust forward, maintaining their own fork of apt, etc.

This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better.

Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.

uv finds a dependency resolution that works for all platforms by default, and can do things like fork the resolution and choose different versions based on platform or python version requirements.

The problem is that this isn't Canonical's own stance. From https://ubuntu.com/about/release-cycle

> Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 25.10 being the latest example. These are production-quality releases and are supported for 9 months, with sufficient time provided for users to update, but these releases do not receive the long-term commitment of LTS releases.

I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline.

In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.

> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact.

Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.

cargo-dist will get you the npm one for free. They've got pypi support planned as well but don't have it yet, though they can also generate standard curl | sh installers and all too.

If you don’t already know the answer to that question (e.g. monitoring network calls in your browser), why would you trust an answer from the same service providing the tools?

> How does this get repeated over and over, when it's simply not true?

Well, for one, the behavior is somewhat insane.

`npm install` with no additional arguments does update the lockfile if your package.json and your lockfile are out of sync with one another for any reason, and so to get a guarantee that it doesn't change your lockfile, you must do additional configuration or guarantee by some external mechanism that you don't ever have an out of date package.json and lock. For this reason alone, the advice of "just don't use npm install, use npm ci instead" is still extremely valid, you'd really like this to fail fast if you get out of sync.

`npm install additional-package` also updates your lock file. Other package managers distinguish these two operations, with the one to add a new dependency being called "add" instead of "install".

The docs add to the confusion. https://docs.npmjs.com/cli/v11/commands/npm-install#save suggests that writing to package-lock.json is the default and you need to change configuration to disable it. The notion that it won't change your lock file if you're already in sync between package.json and package-lock.json is not actually spelled out clearly anywhere on the page.

> At least not anymore.

You've partially answered your own question here.

> For the average user, the increased encoding times did not justify that.

The average user is a consumer of media, not doing encoding themselves. A one time cost for higher encoding to save bandwidth / storage space many times over is almost always going to make some amount of sense.

The real issue here is just a standard chicken-and-egg problem. To use a new codec, you need it to be supported in end user devices. To get it to be supported, you need to show demand... for a thing that nobody can use yet.

I'm not sure I understand what you're saying. You can pass a list of files to sd, `sd before after **/*.py` to replace in all the python files in your project. That's about as native of a replace across multiple files you could possibly want.

Your comment is copy pasted from the same comment you’ve posted at least 2 other times in the last 24 hours. Thats very much cookie cutter. It’s also not all that relevant to the parent comment, it’s just trying to turn things into a flame war. The comment only expressed that golang’s simplicity has prevented some of the issues they perceive in V, and you’re trying to turn it into some Go vs V and dredging up a bunch of unrelated criticisms of go.

Not every thread needs to be this us vs them mentality with other languages that you bring to the thread.

I read that not as a claim that this is an attestation mechanism, but that this is another step towards that. Given that Google has previously discussed implementing the Web Integrity API, it's not so large a leap as to be dismissed as disconnected from reality.

I just wanted to clarify that I point this out to say that there was a real opportunity in this thread to try to push back on the language wars perception. To me, good community management would be taking the opportunity to say:

  * Sorry you feel that way, we try not to foster an inclusive environment that avoids language flamewars and negativity towards other languages
  * Some specific examples of policies that are enacted in community spaces towards that end (e.g. some large programming language discord servers have specific rules against low effort language bashing content and memes)
  * Take the opportunity to link back to positive things that the Zig team has said about Rust and places where folks have recommended it.

Instead, we got a shallow dismissal and redirection, which unfortunately starts to look like a pattern, especially when coming from a person who's in a leadership position in the community being discussed.

> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it

Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about topics you aren't involved in and don't have a solid grasp of.

https://kristoff.it/blog/raii-rust-linux/ https://lobste.rs/s/hxerht/raii_rust_linux_drama#c_gbn1q8

Or similarly, comments like this one in this thread: https://news.ycombinator.com/context?id=44994749

That's a harder argument to make given the "or later" clause was the default in the GPLv2, and also optional.

This is currently limited to X11 (though their docs say they could theoretically support other platforms)

That’s X11 only.

I strongly disagree about this being a recent thing, this has been happening for decades at this point.

2015 article that starts "For nearly a decade, PayPal, JPMorgan Chase, Visa/MasterCard, and now Square, have systematically denied or closed accounts of small businesses, artists and independent contractors whose business happens to be about sex."

https://www.engadget.com/2015-12-02-paypal-square-and-big-ba...

An intentional exit by a runtime is a safe crash. A segfault is not, and is here a clear sign that memory safety has been violated.

> Are there common exceptions to this out there, where you can call something that says it takes or returns one type but get back or send something entirely different?

I would personally consider null in Java to be an exception to this.

id is not an implementation detail, it's a core built-in function of the language. The value that it returns is an implementation detail, but the properties of the value it returns are not and perfectly valid to rely on.