weberc2

I think you get that with any language. People are very attached to how they’ve learned to solve problems and the set of tradeoffs they tend to value. I like Go and I can’t tell you how often I see even outlandish criticism (for a long time on r/programming, commenting “it is impossible to build a software product in Go because the type system is too weak” was a great way to get upvotes, especially if you followed it with “but I really like <fully dynamic language>”). You just have to try to understand which parts of the criticism are valid and improve your own understanding.

This seems like a straw man; I’ve seen relatively little JS hate in this thread. Unless you’re considering WASM’s progress (or existence) to be an attack on JS? I personally don’t see what is wrong with having other choices for web development.

WASM isn’t very practical yet because it isn’t fully formed. There isn’t support for DOM access or parallelism, never mind the ecosystem. It’s a really ambitious project, and writing it off as “locus of JS hate” because it hasn’t completely changed the game in such a short time frame is really short sighted. It would be a fairer test to give it 5 years.

This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.

I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance).

LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it.

Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!

Can you elaborate? I would think the sandbox nature of wasm would be a better fit than other models, and presumably no worse than JavaScript?

If people can’t figure out how to do that on their own, they aren’t going to be equipped to detect issues in the source anyway.

So the dephell maintainers should go through the Debian team or similar in order to distribute? Good grief...

Root access is orthogonal to the particular incantation you use to invoke the Python file you downloaded from the Internet.

All of those apply to Python as well except the multiple packages concern has nothing to do with a browser and everything to do with the fact that a given Python process can only load one version of a library at a time (and probably for good reason).

The Python Packaging Authority declared it the future of dependency management once upon a time and it nominally checked some important boxes such as managing a lockfile.

It is odd that your comment was “ideological battle” but not the original article. I guess the original was sufficiently jargon-laden.

Someone has to write the package definitions for those dependencies, and the public package repository doesn’t have broad coverage for many popular packages in many languages. This is understandable in that this is a massive effort, but that’s also the point—the effort to manage packages is huge and the extra effort compared to other tools is not a good bargain for many projects, nor is it much of consolation for project maintainers who would otherwise like to use it.

I do think of it as a religion—one that is state sponsored and masquerades as science.

You really misunderstood me. I didn’t claim anything about white people; I gave a hypothetical scenario. And that hypothetical scenario wasn’t about white people facing discrimination for higher meth usage, only that such an inequitable distribution of meth usage seems to satisfy TFA’s definition for structural racism. The fact that it seems implausible to say so suggests the definition is not especially useful.

I’m not challenging the importance of minimizing those errors, especially with respect to healthcare. I’m challenging how meaningful or useful such a broad, vague, overloaded, and inflammatory definition can be, if indeed I’m understanding the definition properly.

The definition for structural racism according to the article:

> Structural racism refers to “the totality of ways in which societies foster [racial] discrimination, via mutually reinforcing [inequitable] systems...(e.g., in housing, education, employment, earnings, benefits, credit, media, health care, criminal justice, etc.) that in turn reinforce discriminatory beliefs, values, and distribution of resources,” reflected in history, culture, and interconnected institutions (Bailey and others, 2017).

I think I might be misunderstanding, but given this includes “culture”, is this so sufficiently broad such that hypothetical scenarios such as this (no idea if this is accurate) would be captured “white people are culturally more likely to use crystal meth than other racial groups, ergo they are victims of (a certain kind of) systemic racism”?

It seems like this is just a catchall for any kind of error associated with a racial group, and the article is merely cautioning against such errors. If so, it begs the questions “why not just say so?” and “why use such a loaded term like systemic racism?”.

I would say the main issue is that Nix is super difficult and requires you to intimately know your entire dependency tree down into Linux particularities. JavaScript makes matters worse, but even packaging a nontrivial Python package pulled directly from Pypi is often difficult.

I want to like Nix, but it is far too pedantic to be practical. And this isn’t even mentioning the usability issues.

There’s a pretty straightforward solution to this problem which is to run your own NPM server even if it’s only a caching proxy. For some orgs, the uptime provided by the third party servers is sufficient.

Space shuttle software is written in C, and lots of critical software is written in C++. Discipline, standards, and experience go a long way. Static verification is also nice.

Its based on experience and a general consensus among the most experienced developers I know. The research isn’t remotely conclusive; it’s not worth anything until they control for much, much more.

To be clear, there are many other statically types languages besides Haskell, most of which are more amenable to a faster pace of development.

Further, while I agree with your “different matrixes of payout”, I think static types are a very low investment and they have a respectable payout in terms of preventing bugs but also in terms of documenting code and facilitating tooling (such as autocomplete or documentation generation) and they also permit easier code changes than comprehensive unit testing (even “good” unit testing). Of course, I’m not advocating that static types completely obviate tests; rather that they obviate some of the tests; however, there is no clear answer as to how many or which tests are obviated; it’s very circumstantial.

C, C++, Rust, Go, etc have no special distinction between reference types and primitive types but rather everything is a value and some values are pointers/references. In a language with operator overloading, I don’t see why you’d ever want to check string identity by default. Interestingly, Go doesn’t have operator overloading but it treats strings as a special case including doing a string comparison for ==. Not saying this is better or worse, although no one makes mistakes with string comparison as far as I’m aware, for whatever that is worth.

The problem with that is the economics for many applications don’t favor elaborate test suites. If you’re building a saas software product where you can detect a bug, fix it, and deploy in a matter of hours, and wherein developer velocity is among your most important metrics, an elaborate test suite is a liability (note that the suite spot is not “no tests” but somewhere in the middle) as it makes changes slower. Dynamic languages work reasonably well for these categories of applications, although some static typing can help improve that iteration time.

I would say experience is the best we have.

For sure static types are no silver bullet; no one in this thread is claiming otherwise and anyone who is making that claim is wrong. And of course various languages like Haskell and Java and C# have a productivity toll (although I’ve heard the latter two have improved considerably since I last used them), but I think almost none of that is due to static types intrinsically. Haskell’s productivity toll is due largely to its insistence on functional purity, bizarre syntax, inaccessible and jargon-laden culture and documentation, and general lack of attention to practical concerns. Java and C# suffer from an abundance of boilerplate, a large feature matrix, a bunch of baggage from an era where inheritance was shoehorned into everything, and similar “enterprise” cultural baggage (“IAbstractBeanFactory”).

A good counterpoint is Go. Despite being far more familiar with Python (it’s my professional/work language), it’s static types actually help me write correct code more quickly than I can with Python. Your mileage may vary, but I think anyone who has given Go an honest shake will find that it’s at least in the same productivity ballpark as Python. Note that this isn’t considering tooling or deployment, or performance where Go specifically excels over Python (and also often due to static types).

Of course, with sufficient investment in testing, you could get the same confidence with Python that you get in static languages, but writing tests is a productivity cost as much as boilerplate or a pedantic compiler. And with static languages, I often find that I can write fewer tests for the same confidence (in fact, I often prototype in Go and backport to Python).

It’s been a while since I used Java, but what on earth does that string comparison do if not comparing the strings? Is it an address-only comparison?

How do you figure? If it’s mission critical, it means failure is unacceptable. Python and other dynamic languages (TS is a middle ground here) excel when failure isn’t so bad and making and deploying changes is fast/easy/cheap. This is exactly the wrong tradeoff for mission critical systems.

What’s the advantage of lightweight threading features? I thought your position (based on comments elsewhere) was that kernel threads are roughly as fast as it gets? What am I misunderstanding?

You misunderstood the GP. He isn’t saying it’s correct, only that it doesn’t deserve to be dismissed out of hand. I.e., it deserves a more robust treatment before dismissal is warranted.