weberc2

> No amount of async/await or goroutines can solve this problem

Presumably he’s not serving the model but running it, which is cpu bound, in which case Goroutines would solve the problem.

No, data science is typically cpu expensive. Python is fundamentally single threaded and slow at that, so you have to be very clever to work around the issue (e.g., running a separately scalable service for your data crunching work). Contrast that with Go where the runtime can use other cores.

I would also expect that it’s easier to address the co2 output of a single coal plant than a million cars due to economies of scale. The solution space for internal combustion engines is constrained by size, weight, and serviceability which is less an issue for power plants. Note that this is not to say that we shouldn’t prefer green energy, only that it shouldn’t deter us from investing in electric cars.

In your eg, what is the problem exactly? This a rhetorical question, I’m just not following.

> I guess it's turtles all the way down, because (from my pov at least) deciding on what "structures a type must implement" is pretty similar to saying "a table is a table only if it's got 4 legs".

The idea is that callers/clients define the structure they’re going to use. If the caller needs something that can hold food, then only things that hold food can be passed in. If the caller depends on having four legs, then only things with four legs can be passed in. If the caller depends on four legs and can hold food, only objects that satisfy both properties can be passed in. The type doesn’t choose which structures it implements (that’s nominal typing) the type just is and it either implements a contract / has the right structure for a given client or it doesn’t. Check out Go’s interfaces for a more concrete example.

> Again, from my pov, a dynamic-like language is a lot more tolerant with the unknown unknowns of which the open world is full of, it doesn't depend on any "structure implementation" being defined or on anyone else counting the legs of said table.

This is inherently untrue because structural typing is simply the formalization of the same logic you use when composing programs in a dynamic language. The same logic that lets Python document an argument as “file-like” is formally expressed in a static language as “anything with methods read(), write(), seek(), close(), etc”. This still gives you the openness you need (you can pass in other types even if they don’t know about your file-like interface) but it guards against runtime TypeErrors and AttributeErrors.

Give static typing an earnest try. And be discerning about the source of friction you encounter: is it because static typing is making it harder for you to write big-prone code? Is it because the language makes heavy use of inheritance (and nothing to do with static typing at all)? Is it because the language is very verbose (and nothing to do with static typing at all)? Or maybe the language has a bizarre syntax and jargon-laden, conflicting documentation, in which case these also aren’t properties of type systems but rather functional languages ;).

> In the real world we can still use any piece of wood or stone as a table as long as food doesn’t fall off it, because said piece of wood/stone quacks and walks like a table, while Plato or Aristotle or most of the static type proponents would argue that we shouldn’t do that as that piece of stone or wood doesn’t have 4 legs and as such is not really a table/doesn’t correspond to the idea/type of a real table.

You’re advocating for structural typing, which is a property of (many) static type systems. The view you project onto Aristotle/Plato/static-type-advocates is nominal typing, which is just a different kind of static typing. Many languages support both kinds (for example, Go, Rust, and Python’s static type system, Mypy).

Note that languages with structural typing will correctly accept your stone table and reject objects unsuitable for holding food (where “holding food” is the structure a type must implement) while a dynamic type system will happily allow anything to be passed in as the table, including a waterfall or communism and you’ll be none the wiser until your bread is wet or your country is starving.

It’s fine to compare static and dynamic, but it’s important to understand the things you are comparing so you don’t make silly (and very common) false dichotomies like the one you point out. The problem isn’t the comparison, but laziness.

That’s not the issue at all, and we know this because the project was advertised as secure and the critics were arguing that it wasn’t advertised as such. This is characteristically different than your basketball analogy because it is neither explicit nor implicit that the project was unsuitable for production. Drew is arguing that the criticism is invalid because maintainers are within their rights to even lie about their projects because all responsibility lies downstream. Note that security DOES indeed lie downstream, but Drew is mistaken for arguing that this downstream responsibility immunizes maintainers from such criticism. This is a non sequitur.

I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.

I reject the axiom. No one is above criticism provided the criticism is rooted in fact (i.e., defamation is not criticism).

FWIW, I don't have a dog in this fight. On the one hand, there is the maintainer who is within his rights to accept or reject patches as he wishes (although it's not great that he's allegedly falsely advertising his project as secure) and you have critics who are within their right to criticize (although it's not great that much criticism is vitriolic, etc). As TFA says, it's a sad affair all around.

> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.

Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.

> Everything else is just trying to force people to do stuff for you, and that's rude.

Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.

You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.

It's also the choice of anyone else to criticize him for not accepting security patches.

> I think you are getting downvoted because the argument is exasperating. It's argument by ignorance: "I don't know therefore it isn't true."

That would be unfortunate, because I'm very clearly not saying any such thing. Specifically, asking about the magnitude of discrimination is not asserting that it doesn't exist at all. For what it's worth (hopefully very little), I'm a True Believer in discrimination--it exists, I've experienced it. I'm skeptical about specific truth claims about discrimination (notably claims that it explains a significant part of any gap in the US). I'm also skeptical about social science's ability to accurately study discrimination due to its political homogeneity and track record (more on this below).

> It is very easy to find ample evidence of discrimination documented in published peer-reviewed studies.

Undoubtedly. It's easy to find peer-reviewed studies that support almost any popular conclusion; however, I'm not looking to confirm my own biases (nor anyone else's) but rather to understand what's really going on. Notably, neither the IAT study and Goldin's orchestra study should have passed peer review and yet they did and were held up as exemplary for decades. Between issues like these and the social science replication crisis, I don't put much stock in individual studies.

> The other exasperating thing is at presenting evidence almost never work. The step after someone has presented evidence of discrimination is for the person who doesn't "believe in discrimination" to challenge the result. Either the result doesn't actually prove discrimination or the study is flawed in some way so you can't draw any conclusions.

Discrimination is indeed difficult to prove; the reasonable response isn't to be frustrated that others remain skeptical after being shown problematic evidence, but rather to question why you are compelled by said problematic evidence. Skepticism is the reasonable position here. Note again that skepticism about various discrimination claims isn't the same thing as asserting the opposite of those claims. Note also that skepticism about various discrimination claims doesn't mean that we need to stop investigating discrimination; it merely means we don't have conclusive evidence (and consequently, we probably shouldn't be drafting policy that could hurt people or otherwise propagating myths about the conclusiveness of said evidence).

Is it unpalatable to ask questions about how much discrimination exists and against whom it is directed? The only “evidence” I’m aware of are implicit association tests and Goldin’s study of blind auditions, neither of which demonstrate discrimination. And asking this question often just gets me downvoted. If we are so certain that there is discrimination and tons of it, why is the real evidence treated as a closely guarded secret while we proudly circulate the debunked evidence? Please note that this is the opposite of “we should not talk about it”.

Not only does it do nothing, but the purported problem—implicit association tests (IATs) “demonstrating” a high degree of racism in an organization or individual—is artificial: the IATs are themselves fraudulent; there is no evidence whatsoever that they measure racism at all. https://www.thecut.com/2017/01/psychologys-racism-measuring-...

EDIT: Downvoters, what's wrong with this comment? Are downvotes disagreement? If so, do you have anything to substantiate your position? If it's not disagreement, what could I do to improve the quality of my post to make it acceptable?

That wouldn't explain the perceived increase in QA layoffs; you would need something else, such as worse economic conditions.

I wonder if it's improvements in automation or if QA responsibilities are increasingly rolling up into standard developer roles or because the line between QA and dev is blurring (e.g., software testing now requires stronger dev/automation skills so the QA job looks more like standard software engineering)?

You're confusing "no FFI whatsoever" with "a sane FFI". Python's legacy interface is insane--it exposes virtually all details of the CPython interpreter to C extensions such that any deviation from CPython's implementation is effectively a breaking change.

Perhaps Python doesn't need to be all things to all people, but it does need to be performant because people really shouldn't start projects with Python unless they are sure their project will never have performance requirements that Python can't deliver on, and they understand the limits of the "just rewrite it in C!" or "just use multiprocessing!" advice. Since it's generally unpredictable whether a project's performance requirements will exceed Python's ability or whether the eventual bottlenecks will be amenable to the aforementioned advice, using Python is generally a bad idea; however, many people don't understand the significant caveats to C/multiprocessing and therefore continue to happily start projects in Python (and paint themselves into corners that are expensive to back out of).

FWIW, I upvote things like this on occasion because I often learn more from comments/debate on articles I disagree with than from those that I solidly agree with already. Sadly HN's ability to have productive debate seems to be in decline, but that's another topic.

It’s literally Python, and if you’re writing sane/correct Python, you should hardly notice (things will work a little better, documentation will be more complete and actually accurate, etc). You can even do many of the same bizarre things that shitty Python programmers do without static typing, such as return differently types data based on the value of an input parameter. Someone passes in the string “asdf” so we’ll return an int, but if they pass “xyzfoo” we return a datetime. Next thing you know you’ve built matplotlib.

Fair enough. The system is statistical; I’m not claiming every harmful tradition is eliminated and tradition is optimal; only that the most harmful traditions are eliminated or minimized (e.g., human sacrifice is only practiced among very primitive civilizations).

Most of the irrelevant and harmful stuff was stripped away long ago when it stopped being useful. Most tradition is useful, although the industrial revolution has been cause for reevaluating many, many traditions; even millennia old traditions like (some of the more egregious) gender roles.

Headers that slide in and hide the content whenever you scroll to read the content in the first place.

Oof, that’s quite a take. Static type checkers by definition don’t change the language’s functionality; they merely check the types.

Work is important because we value a high quality of life. Things like comfort and shelter and medicine and protection from violence and all of the other trappings of civilization never mind luxuries like cars, Internet, cell phones, etc. These things have never existed apart from work. I keep hearing about how awful capitalism is and how absurd and morally wrong it is for humans to need to work, but no one has offered a better solution (certainly nothing that bears up to a layman’s understanding of economics). Substantiate your claims about how “absurd” things are—articulate a system that can appropriately channel resources “where they really should go” (e.g., caregivers) better than capitalism (specifically what imbues your system with more moral authority than a market? If your system depends on a majority of voters feeling the same way as you, what happens when you can’t guarantee that invariant? What happens when you realize that voters and their representatives are even less efficient at allocating resources efficiently than a market? And how does your system guard against corruption better than capitalism?).

Python has had static types for years. https://www.python.org/dev/peps/pep-0484/

Evolutionary biology can only tell us the bare minimum about what we need to survive as a species. If you want anything more than that (say for example, a cushy third-world quality of life), evolutionary biology is the wrong field (or rather, not the complete set of fields) to look at.

I'm actually (pleasantly) surprised that someone like Google (or a league of someones like Google) who have deep pockets and so much Python 2 that it's cheaper to maintain Python 2 than it is to port to Python 3. Perhaps they (correctly) were concerned about the ecosystem moving on toward Python 3, leaving them behind?

Right, they could have paid a nontrivial cost (asking devs to use b-strings, print_function, etc) but didn't by fiat, choosing instead to pay a greater cost during the migration in addition to the nontrivial cost. My comment expresses skepticism about that decision.

> One of the biggest early hurdles in our porting effort was how to overcome the string literals type mismatch between Python 2 and 3. In Python 2, a '' string literal is a sequence of bytes. In Python 3, a '' string literal is a sequence of Unicode code points. These are fundamentally different types. And in Mercurial's code base, most of our string types are binary by design: use of a Unicode based str for representing data is flat out wrong for our use case. We knew that Mercurial would need to eventually switch many string literals from '' to b'' to preserve type compatibility. But doing so would be problematic.

> In the early days of Mercurial's Python 3 port in 2015, Mercurial's project maintainer (Matt Mackall) set a ground rule that the Python 3 port shouldn't overly disrupt others: he wanted the Python 3 port to more or less happen in the background and not require every developer to be aware of Python 3's low-level behavior in order to get work done on the existing Python 2 code base. This may seem like a questionable decision (and I probably disagreed with him to some extent at the time because I was doing Python 3 porting work and the decision constrained this work). But it was the correct decision. Matt knew that it would be years before the Python 3 port was either necessary or resulted in a meaningful return on investment (the value proposition of Python 3 has always been weak to Mercurial because Python 3 doesn't demonstrate a compelling advantage over Python 2 for our use case).

As a general rule, this seems like good practice, but surely b-strings, print_function, etc are a trivial upfront cost, and one that would have to be paid sooner or later anyway?