But hey, that’s pragmatism for you, sometimes you just have to let go of ideals even if it hurts a bit.
I’m certainly looking forward to what happens next, even if more from the sidelines.
But on the other hand, that's how we end up with a programming language landscape where every language is mostly the same, except for community conventions and very slightly different syntax.
I'd love it if more languages where strongly controlled like Clojure and alike, where there is a unified vision that is well kept across time. Not that Clojure is perfect, but probably the best example of a language where the community is welcome to suggest things but unless the person in control approves it, it won't make it into the core language and instead will/could be implemented as a library. In contrast to Rust which seems to base language additions/changes based on popularity in the community.
I don't want a different language, I want multitude of different languages. And not a multitude of different Fortrans/C-like language.
I'm not familiar with Deno, but have skimmed a few posts about it here and on Reddit. In any case, my point of view here is general enough that it doesn't matter if it's literally about the Deno project or some other new language/runtime project.
When you say,
> And this is a great move, help people to switch from "node" to "deno" while they keep using existing tools/libraries they use. And slowly, people can then switch to deno standard/3rdParty modules.
my main thought is that compromising whatever benefits Deno envisioned to "attract" Node developers actually gives Node developers LESS reason to switch.
I'm no psychologist, but I can't help but believe that part of the reason Rust got such a cult-like following (myself included) is because a bunch of us spent years writing C++ and then tried Rust and it wasn't smooth. Perhaps that's paradoxical, but for me, it really showed me how much safer and more robust my code could be with this new tool. I don't think that Rust would be as popular today if it had some kind of unsafely-call-C++-mode enabled by default.
It's a balance, obviously. If you want your language/runtime to be the best quality, you don't compromise much; if you want it to be popular, you make it easy to get in to. Often those two have some tension.
Just my two cents as someone who's a bit more on the idealist/academic side of things and is super disappointed by the compromises in languages like Kotlin and TypeScript.
Because as much as there are loud voices on the internet decrying packages, most people are not so ideologically focused. They just want to get their code written. Packages help and so they use packages. Plus most of the loud voices neglect to offer any solution other than "packages are bad!!!"
Search this transcript for "any mistakes so far": https://changelog.com/podcast/443
Meanwhile configuration and npm support was something that initially (pre and at 1.0 times) was something considered a bad thing. Now, not so much.
I would lie if I said that such a hard stance on these things wasn’t what initially drew me to the project.
If you'll permit me to be a cynic: this is VC funding for you. Deno took on a ton of funding and they need results. The barrier of NPM incompatibility simply can't be allowed to get in the way of them getting marketshare.
The dreaded npm ecosystem is still full of value.
I tried Deno a few months ago, because I wanted to avoid the hassle with setting up a package.json, yarn lockfile, adding dependencies, etc.. just to run a TS script that generates k8s manifest YAMLs via https://github.com/cdk8s-team/cdk8s-plus
But very quickly I realized it's not there yet.
Deno is better than nodejs but nodejs is “good enough”.
Competing against “good enough” is extremely hard.
If Deno becomes a better choice than node through npm compatibility them that’s a huge win for Deno.
It doesn't matter how fast a type checker is at that point at runtime.
The only reason to bring back type checking at runtime would be if V8 et al ever also started using type hints as JIT hints and you want to triple check you are sending the right type hints and not accidentally stomping on your own runtime performance. (Which is intentionally not in that Stage 1 proposal mind you: no one is expecting runtime type hints in the near future.)
I prefer Deno packages.
If I have to get an entire application’s types perfect before even running the code that’s a huge DX slowdown.
Types should pass, strictly, before merging.
Personally speaking, isn't that exactly the value of having a type system in the first place? If it still type checks after the refactor it ideally* is still working. Unless of course some system boundaries changed or there is some dynamic component.
I suppose we both come from different philosophies here. I write out the types for a program first, then the behavior follows through. If I cannot properly determine the types I escape with dynamism.
You seem to dynamically write the system up and then determine the types, do I interpret that right?
The current setup might be a better experience then, but I think the default matters here.
In my little bubble I've encountered more libraries with broken typing since type checking has been reduced, so I perceive it as a net-negative. You end up having to explain that you need to take manual precautions to actually get type checking.
Of course this could just be due to the growing user-base and the higher probability of hitting a "wrongly typed" library, so it will remain to be seen how much impact it has.
I'm used to the --check flag by now :)
* How ideal depends on how expressive the type system is.