Being self-centered, dishonest, not taking responsibility, blaming others, etc.
Each person had to be very reliable, and that included admitting challenges, and asking for help, as long as it wasn't asking all the time.
Selfishness, where they would not compromise for the team, was a dealbreaker.
I gave each of my engineers a great deal of agency, and expected them to deliver, as opposed to having to ride them. They were grown-ups, and I needed them to act as if they were.
Personal Integrity and Honesty was a big deal for me, as was a sense of accountability.
Most managers "cop out," and only hire people that "fit the culture."
The problem is that homogeneity breeds mediocrity. If you want good, innovative stuff, you need to hire and manage people that don't "fit the mold." That's a challenge.
Everyone seems to get caught up on technical merit, but a good tech can generally be trained to do anything. During my tenure (almost 27 years, 25, as a manager), we went through many iterations of technology, programming languages, etc.
When we want a good, heterogeneous team, we need to hire for team cohesiveness, as well as technical merit. Almost no one we hired was able to just do the job, out of the starting gate. The tech was too specialized. We needed people that could be trained, and that would stay around (When they rolled up my team, the person with the least tenure had a decade).
You can't be as aggressive at removing functions in Java than in Rust though since it's dynamic dispatch (e.g., if you use toString once in your code, you need to keep all implementations of toString which are reachable even if users don't use reflection).
I used to use a FreeBSD desktop at work back in like 2002.
And that is a reasonable thing for those projects to try to achieve.
Still we've been downloading binaries for decades and the world hasn't ended, this issue never warranted people treating it like nuclear war was imminent and hurling abuse into Dtolnay's github issues like he was a child pornographer. There's a way to have a discussion about this being the wrong direction without doing that.
And I'd encourage everyone to take an honest audit of how many precompiled binaries are in their lives, even if they've switched to NixOS and how much stuff they trust downloading from the internet. Very few people achieve an RMS-level of purity in their technological lives.
The world hasn't ended, but I'd argue that the number of malicious actors within the space is rising, as are the consequences of being compromised. We're simply seeing more and more malware make its way into open source ecosystems, and I don't imagine the trend will be reversing. For this reason alone we should be striving to achieve full build reproducibility, though I agree with you that demonizing (or threatening) Dtolnay is wildly inappropriate.
Yeah, people have woken up to "supply chain" problems, particularly with javascript and npm which is an entire tirefire.
But we've gone from 0% to 100% overnight and as usual people have adopted it as their new religion and they want to burn all the heretics and there can be no compromise.
I seriously doubt that this one specific issue was all that important in the larger problem of securing the supply chain, and there was a very good reason why it was done (which has now been entirely thrown away, which will certainly harm adoption of rust). I don't think it was remotely comparable to the way all of npm is a security hole.
This is all true, but even if you don't care about reproducible builds that doesn't mean that nobody cares about reproducible builds. And the people that do care about such things care about them very much. To the point that if you don't offer it to them that they'll go somewhere else.
I didn't say not to try to get to reproducible builds, though, but not to treat Dtolnay like he's a criminal.
There is a very real problem that he was trying to solve, but the right way to do it will require core language support. And his heart is certainly in the right place, since "slow build times" is probably the #1 complaint about Rust.
If you actually polled most Rust users they probably care about their build times more than they care about this issue, particularly if you designed the survey impartially and just asked them to stack rank priorities. They probably all would prefer "both" being the right answer though.
Where the criticism really needs to be leveled is on the core language design (although I appreciate that their job is also extremely tough).
[And the one good thing to come out of this shitshow will probably be getting people focused on solving this issue the right way]
It's funny how opposed the 'Go' and 'Rust' eco systems are, the 'Go' people optimized for compile speed from day 1 but have trouble making things safe, the 'Rust' people optimized for safety from day 1 but have trouble making things fast.
Maybe they could learn a trick or two from each other?
I don’t program in Go, but this is the first I’ve heard of it being unsafe. I thought Go was a GC language implemented via the Go runtime and properly handles memory safety (memory corruption and OOB access). Are you using a different definition of safety here or is there something else that I’m not aware of?
This is completely tangential to language “safety” as it’s commonly referred to when discussing languages like Rust and C or C++. Typically, I’ve only heard safety used to mean memory corruption, out of bounds memory access, and undefined behavior are not allowed, or throw runtime exceptions when they happen.
Java’s standard HashMap isn’t thread safe, it has ConcurrentHashMap[0] for this reason. And I’ve never heard somebody refer to Java as an unsafe language. Lemire wrote a blog article arguing Java is unsafe for similar reasons that it seems you’re using here, and I think the comments section has some great discussion about whether this conflation of language safety makes sense or not[1].
And one final point: a lot of the world lives on software segregated across several different machines, operating asynchronously on the same task, usually trying to retrieve some data in some central data store on yet another machine. Rust is great for locking down a single monolithic system, but even Rust can’t catch data races, deadlocks, and corruption that occurs when you’re dealing with a massively distributed system. See this article that talks about how Rust doesn’t prevent all data races, and why it’s probably infeasible to do that[2]. And I doubt anyone here is about to call Rust unsafe :)
This conflation of language often confuses me and I hope as an industry we can disambiguate things like this. Memory safety is distinct from thread safety for a reason, and by all reasonable standards Go is as safe as a modern language is expected to be. (Obviously better thread safety is a goal to be lauded, but as an industry, it seems like we’re still trying stuff out and seeing what sticks in regards to that).
To be fair, mixing higher order functions with effects (exceptions) is really hard without changing the type system completely. At that point you're moving into novel encoding territory.
The Scala community is incredibly committed to stability; every open source maintainer I know of in that space checks for binary compatibility when releasing as well as cross-compiling for multiple targets (Node, Web, Native) and versions.
The problem with scala is that the core devs seem to be working against what the community wants. At it's core it's still a research platform for many and it shows in the priorities for what gets included in Scala 3. Also while individual open source libraries are generally very stable and high quality the overall ecosystem is very fragmented and there is lots of churn (cats vs zio holy wars etc.).
Also, Mavens metadata model is recursive. You want need a dependency? You're going to have to pull in the parent, which is probably an Uber pom. Take a look at your M2 cache, it's probably got a kubernetes pom even if you've never touched it before because your logging library uses an Uber pom...
Yes, though hopefully it's been packaged up by the distro otherwise you'll end up having dependency problems if you compiled against a wrong libc or something else.
Monads have nothing to do with laziness and we're talking about the Result type anyway.
OP is correct. If it has a bind, pure and map (which it does!) then for all intents it forms a monad.
Now the fact is you can't _manipulate_ monads in Rust easily (see kinds and discussions wrt GAT), but nonetheless monads are present in all languages with ADTs in the same way that rings are present in all languages with addition.
