On the retry I still have the confidence from the previous attempt but I can barely get a hit before being completely destroyed. How hard could it be? I was one move away from victory last time. But now the challenge is far more apparent.
This happens repeatedly as I use trial and improvement to learn the fight I so effortlessly put up in the first instance.
It reminds me of just how much is down to chance and what you did in a moment in time. Trying to consciously recreate it, but better, is a Sisyphean task.
One thing I've found with these types of games is getting into a "flow" works so much better than trying to consciously play the game. Unfortunately the only way to develop the muscle memory to be able to enter this flow state is to bash your face against enemies over and over until you're no longer thinking about how to react. I've also found that when I'm struggling with a boss, I'm playing in a much more conscious way which means I'm thinking about my responses instead of just reacting. When I get really close, but don't kill them, I often over focus on the piece which got me killed and which means my attention on the dozens of other things I've used to get to this point slips a bit and I get destroyed. At this point I usually know I'm too much in my own head and go off to areas I'm comfortable with to try to get back into a flow for the boss fight again.
(edited)
This is a tooling/ecosystem issue. E.g. in Elixir where the package manager is a part of the distribution, one-file scripts with dependencies are easy: https://fly.io/phoenix-files/single-file-elixir-scripts/
I'd like to see you argue the other side of this discussion & see if you have the eye to appreciate what is better & nicer.
There's a lot of complexity that's still way way way away in the rear view mirror. It's still super possible & super nice to use deps.ts to tackle a lot of the current situations.
Very side mention on deps.ts, I think there is a bit of missing potential to pass your tree of deps into other packages deps, but this is definitely just working around import-maps's intended use case in userland.
You mean:
- manually import and re-export every dependency you depend on
- cannot change resolution mechanism to a different package repository, for example, in a corporate setting. Especially not for dependencies of dependencies.
You could probably automate it by providing a package.json of sorts, and reading from there...
The goals of Deno and Node are different, the architecture is different.
Adding a compatibility layer helps Deno grow while maintaining its original goals.
I doubt this adds much complexity if done properly...
And here we are.
What's wrong with a compatibility layer with npm if it's implemented properly?
His views on package.json and implementing a compatibility layer to help others transition from node are not mutually exclusive.
The support for node is pretty simple. Using NPM packages is straight forward. Reading a package.json file and using those mappings isn't complex either. Deno does not use node_modules in any of those instances...
This is why Deno has gone so long without a true package manager. The problem here is now they're fighting for adoption so they're going against their original values because they know what they wanted isn't what the broader community wants.
Can you elaborate?
> so they're going against their original values because they know what they wanted isn't what the broader community wants.
No, they are still sticking to everything, but added support for the existing ecosystem. Yes they are adding this to combat the network effect that node has, but it doesn't really go against anything. You simply prefix npm in front of npm imports. Now you could use a package.json file if you already have one, but you don't have to.
The fact that all this interoperates with NPM as well is just an added bonus. But even if NPM died tomorrow, deno would go on having a package system, because they have realized how important it actually is (to fix things like what they call the "duplicate dependency problem").
But the package.json format part is a backwards compatibility feature. The preferred import maps will be the ideal solution (if you do need dependency management).
None of that really goes against direct imports, which work well for single file scripts, workers, etc. Choose what fits.
It states many times it was added for backwards compatibility.
Even at the bottom of TFA they annotate the ideal solution (which will be implemented soon) is to use import maps instead of package.json, the same format the browser uses, which is in line with Deno's main goals.
Fast forward a few years, and they are now adding these two things natively to deno, just as the web ecosystem did. Turns out, Node was right to have modules and an import file all along, and at worst there were some minor implementation quibbles to argue about.
I'm glad I can use direct url imports in simple Deno scripts.
I also see the need for import maps for larger projects.
I do think node_modules is an abomination and glad I don't have to deal with them anymore.
I prefer writing everything that works in Deno and the browser, not Node specific APIs.
I like the tech, I don't really care about the drama, and I doubt the Ryan does either lol.
I disagree with how you summed it up, but I don't really care to continue.
It's getting too dramatic and not really about the tech at this point.
The forum had taken off while I was MIA. In spite of me being MIA. And while I could write a manifesto about how the forum had gone in a direction I didn't necessarily want, I had to admit that my plans for the forum weren't better nor more correct than the plans that emerged organically from the community over the years.
When you create something with a community and ecosystem, it's easy to see the success of the ecosystem and the downstream success of the people within it as your success when in reality you are more like an early collaborator who set the stage for others to join in and take it from there.
A good example of this in my case was the hubris that, because I created that one big forum, I could create more successful forums. I never hit gold again. I realized I wasn't some master forum creator, just someone who started something at the right time and the right place with just enough TLC to attract other builders, and that I didn't have some divine insight into how to start a successful forum. Oof.
His product is currently out there, popular, and already infinitely better than node (imo).
I'm sorry you never "hit gold again", but you seem jaded and projecting that onto others.
Who cares if it never fully overtakes node? It's a great alternative. Competition is good.
I'd consider Deno a success already, it growing in popularity is always nice, but the tech already works.
I'd say the people who gave them $21M[0] care if it's adoption doesn't take off.
Should no other browser be invested in because Chrome has the largest market share?
Should no-one ever invest in a competing product?
I believe it is up to his investors what the expected growth rate and market share is.
The blog post explains in detail why these things are actually required and useful, and introduces the new deno.js file that is functionally equivalent to package.json. So even purely deno packages meant to be used entirely in the deno ecosystem are encouraged to use the new package.json 2.0, for many of the same reasons package.json was introduced in Node all those years ago.
Having typescript built in, having zero complexity, none of these compile-down difficulties is just so liberating, so much bad you don't have to tangle with.