I run some events and hear opinions from both sides often. My take on this is there are basically two types of conferences. A more remote location helps people have more fun hanging out with each other, but a big city venue enable more people to attend. Both have value and there are middlegrounds, the choice depends entirely on what you’re looking for.
> As I understand it, even for a jit compiler, the type annotations are typically less useful than runtime behaviour.
What I’ve heard from people who work on performance is, the type hints can provide benefits potentially, but just not relatively as useful as other runtime improvements. The development effort is simply better placed elsewhere.
Reds are also still paying Ken Griffey Jr. Orioles are paying Chris Davis. Nationals are on hook for both Scherzer and Strasburg. I can keep going for quite a while. But everyone will only talk about Bobby Bonilla because New York media made a fuss about it and that’s all people know. Talk about the media misleading masses…
I rooted so much for Vala when it first came out. Such good idea to bring the same good ideas to GLib. Alas it was not to be, the (irrational IMO) negativity around this approach killed it before it had a chance.
OT, I just realised now we are in year 2023 a “century” house interpreted literally can apply to something built post-WWI. I wonder how the term would work going forward.
Poetry itself said Composer and Cargo were the main inspirations[1]. Both of them work differently from NPM; Poetry has mostly the same differences that its claim checks out. You would be in quite some surprises down the road if the sperficial similarities persuade you to apply one tool’s paradigm to another.
Furthermore, having a package manager indicates there are some kind of specifications behind so each package and repository has an expected format (not necessarily _a_ standard package manager; in many ecosystems multiple managers share one standard). This helps vendoring a lot since the standard specification makes the vendoring process very easy to automate and validate. Dependency managers in their essence is really just automated vendoring (or vendoring is just less automated dependency management); it helps because you can pick it apart and choose to automate only the parts you want, even if you don’t like the fully automated solution.
I think parent knows. A more accurate description would be everyone of the intended audience was writing assembly. Yes there are other languages of higher levels, but C was not invented to help their users. And since they are also not really what Rust targets either, IMO it’s reasonable to shorten it to drop the qualifier in this context.
The geometry is called mini velo and popular in some parts of the world because of the smaller wheels (tighter turns) and overall volume. Most of them are foldable these days but the two don’t technically equate (there are full-size foldable bikes).
I mean, there’s been outcries how the US is overly car-dependent and driving should be a choice not a requirement etc. The parent is onto something if you go with this analogy.
Template language being translated to code is nothing new and certainly not unique to JSX even only when you consider frontend JavaScript frameworks. Vue has been doing that ever since single-file component was a thing. You need to look up things, please.
JavaScript is a better, but JSX is not JavaScript. It reuses many features from JavaScript, but you still need some sort of translation (compilation) step to make it useful. In this sense it is not really fundamentally different from any of those what you call template languages.
You can argue the fact JSX better integrates syntaxes from a proper programming language makes it better than other templating languages (and I’m not going to try persuading you otherwise), but the “JSX is better than template language because it is not one” stance you’re implying won’t help you win any arguments.
> so a separate, "standard" choice in typechecking was made called mypy
This distorts reality a bit. Mypy is one of the flowers; Jukka developed the annotation syntax. It got popular enough to become the de facto standard. I would say the strategy worked.
Maybe no reasonable developer would (depending on how you define reasonable), but any software project with a non-trivial user base would have unreasonable users. That’s why xkcd 1172 is popular and Hyrum coined it as a Law.
Itano Circus is about the entire choreography of the entire fighting sequence, more than the missiles but combined with unrealistically agile robot actions and dynamic camera placing/movement.
Most of those workflow tools support at least two execution contexts, one for development and one for deployment (`cargo run` vs executing the compiled binary directly, `npm run` vs `node foo.js`, etc.). There are various reasons for the separation including hidden build steps or to set up the runtime environment, generally you want certain things automated during development but not when the program is deployed. A more accurate way to say this `python foo.py` can’t replace `cargo run` while still doing what it currently does; obviously it could be changed to run the program in the development context. The problem is it’s currently used in multiple contexts, and nobody really wants their workflow to break.
A lot of people said they want Cargo for Python but immediately backed out when you require them to `cargo run` their program. They want `python myscript.py` to still magically work, but that’s exactly where a lot of the magic comes from. Running `python` directly is like manually invoking `rustc` (or maybe slightly more automated like a make script); it works, but is on an entirely different layer of abstraction and doesn’t fit well with the Cargo one.
I’m not trying to imply you’re one of those people, but this may provide some insight why “Cargo for Python” is not a more widely adopted workflow.
One of the problems with Python packaging is Python Core Devs view “Python packaging” and “packaging Python” as two different things, but most people don’t bother with (or can’t tell) the difference :)
WSGI (same for ASGI) is a level above FastCGI (or CGI or whatever) in the stack; it exists so each Python web framework does not need implement ways to talk to CGI, FastCGI or whatever. Instead the framework implements a Python function, and the user can choose a WSGI server to wrap this Python function into whatever is needed to talk to any kind of language-agnostic gateways, including CGI, FastCGI, or even mod_python.
Correct, but the challenges are to compile the dynamic library correctly so it runs on another machine, and on a given target machine choose to load a correct compiled artifact. Python has extremely good support for those compared to other similar ecosystems. The fact that most Python packages decide to do bundling on a comparably broard set of platforms, while packages on some other language are not, is a window to understand how the operation is made much easier by the ecosystem.