They aren't the "coders" of the Rust project.

[This is what can happen when you forget to delete your dumb HN comment before the configured delay time. Sometimes it gets cemented with replies and then embarrassingly upvoted.]

If they aren't coders and are "toxic" on top of that, get rid of them? Looks like a no-brainer to me.

People upvoted my clueless comment because the assumption is that any people called "core" of a FOSS project must be the coders, or else something is wrong.

There's an easy fix. Don't comment on stuff when you don't know what you're talking about. It's pretty simple.

If you want a hint on what's wrong, here's one for you: discourse on the Internet sucks in part because of people such as yourself making "clueless" comments.

Thanks for the feedback. Because of the way HN works, it supports a "nonlinear comment development process". You jot some random ideas into a comment, which can often turn into a good comment after several edits (in which those ideas no longer appear at all). Or not: it gets deleted before it is seen: there is a configurable delay before your comment goes public. I was sure that one wasn't going to be (in any shape), but I had to respond to some urgent things. That's it.

> If they aren't coders and are "toxic" on top of that, get rid of them? Looks like a no-brainer to me.

The issue is that, there is no process to do that within the Rust-lang organisation. The core team is only accountable to themselves at this point.

There is no process to get rid of them.

The people who actually make Rust could simply disavow that Core Team.

I suspect there are reasons why it doesn't simply go down like that. Perhaps it's simply a lack of motivaton; or else hands being tied in various ways (invariably connected to money somehow).

Probably the best thing you can do as a FOSS developer is never grab any dollar waved in front of you and put it in your pocket, if you see so much as a tiny, barely discernible cotton fiber connecting that dollar to some people or conditions.

Defenestration doesn't seem appropriate here.

This is an important discussion to be had.

"Wenn man nicht mehr weiter weiß, gründet man einen Arbeitskreis." - Ancient German proverb. (Translation: "If you don't know what to do next, you set up a working group")

Well Rust is always about dozens of teams, myriad committees, sub-committees , groups, sub groups, work groups, governance boards, foundations and so on. Although I don’t know they have such huge budget to run fortune 500 or government style bureaucracy. Or is that same people appear at ten different places.

Budget doesn't really have anything to do with it. The vast majority of people on a team or working group aren't paid to work on Rust; they're volunteers.

> Records (...) are borrowed from Scala.

I think records already existed in FORTRAN and other languages like ALGOL-60. C has structs, too.

Yes you are right, records have been around for a long time.

COBOL was a popular, very early language supporting hierarchical data of different types. This dates back to approximately 1960.

FORTRAN didn’t have records other than I/O “records” (at least for the first 20 years). ALGOL-60 didn’t have records. Algol-68 did have records, however Algol-68 wasn’t in very widespread use. I never had an opportunity to use it; compiler technology at that time wasn’t really ready for such a challenging language. Algol-68 may not have had widespread use, but a number of it’s features made their way into influential languages like C, Pascal, and Simula. These languages did have records.

As I recall, IBM’s PL/1 did have records, I seem to recall using them in the 70’s in a PL/1 program. PL/1 was kind of an amalgamation of FORTRAN and COBOL’s features.

In the end... Pascal was/is hugely influential, and, yeah, it called these kinds of things "Records." But the funny thing is it's been so long since I wrote Pascal or Modula-2 that when I first heard the term "Record" in the context of Java I never made the connection.

I think it's fair, though, to say that it's likely that the implementation and/or semantics may be more based on other JVM languages, who have to work on Java's terms.

In particular, I'm talking about the fact that Java doesn't really have "copy types" or "pass by copy" or whatever. So, sure, C has struct, Swift has struct, etc, but Java can't really model its version off of the way those work.

I'm a big fan too.

Oh, pleasure to meet you, Transultimate Apostle!

> Other packages managers use the opposite of minimal version selection. Many of them even have a don't make me thing command to update the whole dependency tree (e.g., `npm update`).

vgo does have that too: vgo get -u

That will work for direct dependencies but not dependencies of dependencies. See https://github.com/golang/go/issues/24500

Correct, it will get the newest version that is actually tested against your dependencies, which is by design.

Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with? You can of course force this in vgo, but having the default use the versions specified by the authors makes a whole lot more sense than just using the newest.

> Why would you want to pull a version that is newer than the author of the library you depend on has actually tested with?

1. To install a security update or bug fix update you need in a transitive dependency that the author of the dependency you're using hasn't updated to.

2. To use the same workflows across all my dependency management tools (npm, cargo, composer, bundler, and the rest of the lot follow the same patters and vgo goes against the patterns used by the others)

There are two reasons.

You can do 1), you just have make that an explicit dependency of your own. It just won't grab newest by default for sub-dependencies. So yes, you can pull the latest.

2) seems like a bit of a silly reason, if we all wanted to make everything work the same all the time we wouldn't make much progress or try anything new. Whether vgo's approach is correct or not we don't know yet, but saying that it isn't familiar isn't a good enough reason to not try it out.

To me, vgo matches what we already do in our python projects with a lot of dependencies. Pin everything in a freeze and upgrade on a schedule when we need to. We have seen far too many failures doing it any other way. (IE, using the "latest" of everything, which often either breaks semantic versioning and actually breaks or has subtle bugs that didn't exist before)

Using something like pip-compile, or literally `pip freeze > requirements.txt`?

The latter yes.

3. To apply bugfixes that affect you, but weren't exposed by your direct dependency's tests.

I believe that vgo get -u works for both direct and indirect dependencies.

See the vgo tour : https://research.swtch.com/vgo-tour

The indirect dependency (rsc.io/sampler - which is a dependency of rsc.io/quote), is also upgraded to the latest version v1.99.99 when vgo get -u is done.

I feel like this is the package management equivalent to the shift from geocentrism to heliocentrism. Yes, you can approximately predict the movements of the planets with the geocentric model and lots of epicycles (Bundler/npm model), but it suddenly makes so much more sense and it's so much simpler if you assume the sun as the center of the solar system.

Since the term is not defined anything can be considered a systems programming language.

The Go developers provided their definition, which is something people conveniently ignore whenever they try to be clever about Go not being a systems programming language.

To be fair, if I repurpose a term that is widely used in one way to mean something else, the confusion that ensues is kind of my fault.

So many places I worked had systems engineering department and none of them had anything to do with operating systems/ device drivers. I wonder whether it has to do with OS hackers hanging on internet together and deciding what systems would mean.

There was no repurposing, as the context was exactly explained. Only later, the detractors decontextualized the Go team's original statements.

Wow, makes me want to develop a AAA game in Go.

What makes a game AAA is the resources (human and financial) that were used making and marketing it, not the language used to write it.

And the culture.

AAA game developers only moved from Assembly to C, Pascal when forced to do it.

A few years after they moved from C to C++ when the SDKs started to be C++ only.

Similarly they will only move from C++ when forced to do so, and they only major complaint is related to build times.

I bet most are willing to wait until C++20 for modules than switching to another language, even if some studios manage to have some hits developed in safer languages.

Very good point here The outlook of gamedevs to new tooling tends to be pessimistic because so little is actually geared towards what they work on, or want to work on.

On the other hand, Web and mobile games have lived with the consequences of a managed runtime for many years now. There are limits in how much processing power is available there, but it ultimately just diverts developer attention towards other things like a more robust backend, faster turnarounds, and other general workflow improvements independent of scene fidelity.

I get why you're saying this, but go-to-c bindings are not fun and that's how you'd have to talk to the hardware.

Only for the one implementing it.

Also on some platforms it could even be Go-to-hardware.

You really want a higher-level API in most cases, and these are almost exclusively written in C/C++. Also in Go, there's a certain overhead when calling C functions.