Yarn's Future – v2 and beyond

> Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)?

It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scripts.

> How will paths be translated on Windows?

The current Yarn tries to do this by using the `path` native module. It's quite error-prone since backslashes tend to appear in the worst possible places. For the v2 I plan to work with all paths in a posix style, and convert them into Windows paths right before they reach the filesystem (which is similar to what Cygwin does, as you mentioned). It would be a bit slower on Windows, but massively simpler in the codebase.

I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there.

But something for Python that actually works? Yes, please!

I was addressing the above comments about tests that specifically check types. My position is that declarative types and a type checker are better because each code path is checked automatically without writing additional tests, and because the type checker automatically adapts without changing or writing new tests when the implementation changes. Testing behavior is another thing entirely.

Not exactly what you're asking, but a "third choice" in general to typed ECMAscript has been ActionScript. A quick google found a transpiler project, but it looks to be abandoned: https://github.com/Cleod9/as3js

Still, I once did Flex development (would compile to a SWF file, or with Adobe Air to a native executable). It was a pleasure -- so long as you used the Flex/Flash Builder IDE (which was itself built on top of Eclipse). Trying to develop in vim was harder, though mainly because of the MXML part, but I still liked MXML better than HTML. Later at the same job I did Node and found that pretty enjoyable too, plus I could use vim all the time.

Tooling is always a concern with a language. I think dynamically typed languages are partially successful because they let you get away with so much less tooling. Though not all dynamic languages are equal in the tooling they can trivially support, e.g. Common Lisp with Slime enables all the usual stuff (who calls x, who sets y, who specializes method z...) and you can use Slime from a variety of other tools.

> Writing a good codebase is IMHO a craft and should not depend on the language or a bunch of tooling.

Of course, relative to other code in that language you can write good code in any language and that is a useful and important skill. If you invest enough energy and craft, you can even write code that compares favorably to good code in any language - the Linux code base is a testament to that. Still, it is a fallacy to assume that all languages are created equal. Nowadays, next to nobody would argue that writing code in Assembler is a good idea. And even though it is now possible to write web apps with C (via webassembly) there is no movement by seasoned C programmers to conquer the web.

> If Typescript is way to go, what about Python, Ruby, abandon it, deprecated? Are those inferior languages compared to Typescript? Typescript is just another hype, very smart play by Microsoft btw.

While the truism "use the right tool for the job" is overrated, it applies here. Untyped, quick to write languages are excellent for small projects. When I'm writing Python as glue code, designing nicely typed interfaces is a distraction. Also, Python, Ruby and Javascript have base types with excellent usability. E.g. when you parse time sheet data, it is pleasant to return [(time.parse('9:00'), 'document project X'), (time.parse('10:15'), 'implement feature Y')]. But when projects grow every structure enforced by the language is a guarantee I cherish. You know, there is this special case in your time sheet parser where you return a (time.parse('23:59'), Null) element, instead of using the empty string, which made the code much more elegant. But months later, when you are refactoring the code calling the parser, you have totally forgotten this behavior and introduce a subtle bug. That's the time where I wish I had a robust type system.

TypeScript is great in this regard, as you can ignore all types if you wish and gradually add them later, when the complexity of the code base calls for it. Or you start with complete type coverage from the start if that floats your boat. Or you never introduce types and just consume JavaScript. Because of that, TypeScript is especially valuable for libraries: It gives the consumers of the libraries all choices. And it's also the reason the success of TypeScript is celebrated that much: Each new TypeScript enhanced library increases the effectiveness of the tool (and reduces the amount of `any` crutches).