3 ms·

> having relatively curious, meticulous, detail-oriented people on hand who were interested in solving hard problems.... Had we built those projects with JavaSc

• KPGv2 11mo ago
  > I genuinely can't understand why you suppose that has to do with the implementation language at all. Languages that attract novice programmers (JS is an obvious one; PHP was one 20 years ago) have a higher noise to signal ratio than one that attracts intermediate and above programmers. If you grabbed an average Assembly programmer today, and an average JavaScript programmer today, who do you think is more careful about programming? The one who needs to learn arcane shit to do basic things and then has to compile it in order to test it out, or the one who can open up Chrome's console and console.log("i love boobies") How many embedded systems programmers suck vs full stack devs? I'm not saying full stack devs are inferior. I'm saying that more inferior coders are attracted to the latter because the barriers to entry are SO much easier to bypass.
  • zahlman 11mo ago
    Sure, but that kind of incompetence is already filtered out (in the https://www.lesswrong.com/w/screening-off-evidence https://www.lesswrong.com/w/screening-off-evidence sense) by the task of creating a package installer.
    • IgorPartola 11mo ago
      You would think so, yet here I am sitting with a node_modules full of crud placed there by npm, waiting for the next supply chain attack.
      • zahlman 11mo ago
        That argument is FUD. The people who created the NPM package manager are not the people who wrote your dependencies. Further, supply chain attacks occur for reasons that are entirely outside NPM's control. Fundamentally they're a matter of trust in the ecosystem — in the very idea of installing the packages in the first place.
        • firesteelrain 11mo ago
          Lack of stronger trust controls are part of the larger issue with npm. Pip, Maven and Go are not immune either but they do things structurally better to shift the problem. Go: Enforces global, append-only integrity via a checksum database and version immutability; once a module version exists, its contents cannot be silently altered without detection, shifting attacks away from artifact substitution toward “publish a malicious new version” or bypass the proxy/sumdb. Maven: Requires structured namespace ownership and signed artifacts, making identity more explicit at publish time; this raises the bar for casual impersonation but still fundamentally trusts that the key holder and build pipeline were not compromised.
          • Mawr 11mo ago
            For Go, there are more impactful features: minimal version selection and the culture of fewer, but larger dependencies. Your average Go project likely has 10x fewer deps than a JS project. Those deps will not get auto-updated to their latest versions either. Much lower attack surface area.
            • firesteelrain 10mo ago
              Agreed that fewer deps helps, but that’s largely downstream of Go’s mechanics. Minimal version selection annd immutability make churn abnormal, so graphs stay small. In JS ecosystems, churn is the default, so fan-out explodes.
      • nl 11mo ago
        I don't see how that follows. uv doesn't exactly stop python package supply chain attacks...
    • KPGv2 11mo ago
      [flagged]
      • zahlman 11mo ago
        > because it mistakenly treats a cause as having only one effect. If A causes other things besides B, then knowing about those other caused things tells us nothing about whether C happened, because we already know it did. "no further information" is elided to things that are relevant to the statement being made. Please apply basic charity in interpreting ideas expressed in prose; LWers who want to express something precisely in logical or mathematical notation are certainly not afraid to do so. > Less wrong is a bunch of people who think they understand Bayes better than they do. The objection you point out is not relevant to demonstrating an understanding of Bayes' Law. It's just a semantic quibble.
• tikhonj 11mo ago
  Different programming languages come with different schools of thought about programming and different communities of practice around programming. If you take a group of people who are squarely in the enterprise Java school of thought and have them write Rust, the language won't make much of a difference. They will eventually be influenced by the broader Rust community and the Rust philosophy towards programming, but, unless they're already interested in changed approaches, this will be a small, gradual difference. So you'll end up with Enterprise Java™ code, just in Rust. But if you hire from the Rust community, you will get people who have a fundamentally different set of practices and expectations around programming. They will not only have a stronger grasp of Rust and Rust idioms but will also have explicit knowledge based on Rust (eg Rust-flavored design patterns and programming techniques) and, crucially, tacit knowledge based on Rust (Rust-flavored ways of programming that don't break down into easy-to-explain rules). And, roughly speaking, the same is going to be true for whatever other language you substitute for "Rust". (I say roughly because there doesn't have to be a 1:1 relationship between programming languages, schools of thought and communities of practice. A single language can have totally different communities—just compare web Python vs data scientist Python—and some communities/schools can span multiple languages. But, as an over-simplified model, seeing a language as a community is not the worst starting point.)
  • LtWorf 11mo ago
    Since currently 0% of developers started with rust, it would be interesting to know from which language these developers are actually migrating.