You have to touch two config files. One is easy but the other one needs a bit of googling, nothing major but yeah why at all this? Auto-updating security updates should be the default if you run servers in the wild.
When node came out it was a perfect storm: Ryan did a brilliant job, right timing, right product, laser-sharp focus and x times better than the past (I liked node right from the beginning) and he was fast. All things I miss from Deno.
But I don't blame Ryan, he is a great guy, created the biggest server-side dev ecosystem and it's hard to top such an achievement but at least he tries and this is why I like him.
> Not everyone's using cutting-edge deployment tech; lots of folks are just SSHing or RDPing into a physical or virtual server, copying stuff there, and running it
Maybe a decade ago, tbf IDK anyone who deploys like this in 2020, people user either Docker and/or k8s or a stupid-simple netlify/surge/vercel push. Then, there's also server-less stuff but yeah, you get the idea.
I don't think, Ryan wanted Deno to be just another build system for TypeScript but something a bit bigger. And even if it's meant as a build system there're much better options out just for this purpose.
It's right in their wiki, "non-goal" number 4 in their TS Design Goals which is also referenced again in some issues:
[a non-goal] Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.
If GP looks for a general purpose computer for their kids, M1s are a clear yes but for DL? No way, as long as PyTorch is not running on M1s and an Nvidia GPU in some cheap PC shell has the same price tag.
OT: After reading and discussing this feature in this thread, I realize, it's not about the feature or if it's good or bad.
This Deno update and the whole thing shows once again that we want a node successor but Deno as great as it sounds doesn't offer enough benefits or is 10x better than just using node + Typescript in order to leave latter and their huge ecosystem.
Even worse, it creates the notion that the Deno team desperately tries to climb back on stage and get our attention with minor improvements. Maybe I am ignorant but Deno feels just like an opinionated node/Typescript distribution with too little improvements but not like the successor we hoped for.
Besides, I wonder if the Deno team solved all the performance issues which popped up the last time I've read about Deno. There were some debates with the ws community but can't remember details anymore.
What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg.
Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience but encourage the community to compete and complement. Integrating build systems is good for beginners who struggle with them but for the rest? IDK.
Or in other words, Deno wants to be more than just an opinionated node-Typescript-distribution nobody cares about but then they need to create this ecosystem and focus on the core (what's their core and value add other than repackaging node and TS would be the next discussion).
With integrating the build step they do the exact opposite, they shut-down an ecosystem before it can even start. There's a night and day difference between good and bad build systems and only competition and a rich ecosystem can bring up the best solutions.
FWIW, there're tons of ways to compile TS, every with different trade-offs and it's good that we have these options.
> then in many scenarios it'd be a lot easier to deploy
It's not. Most advanced deployments nowadays use container orchestration where deploying is as easy. For simple deployments (eg SSGs) there're enough products on the market.
Integrating the build step hides it at the same time (good for beginners) but creates many other problems in the long run if we just talk about repackaging the run-time.
Yes and no, these are amenities but they are really small and IDK if they justify hiding/abstracting way an import build step.
> Even server side, not everyone uses Docker.
IDK, tried to find alternatives the last years but for a bit more sophisticated app you can't ignore images and container orchestrators like k8s. And latter is still easier than anything I've seen and has by far the biggest ecosystem. If I want to host some minimal app, I just push an SSG to netlify/surge/vercel, it's not an integrated build step which makes my life easier.
> just pop the executable in there
Otherwise you would just need one more line in your build file (npm install).
> Then obviously for CLI tools, this is SUPER nice
Also, yes no, Deno "binaries" have huge file sizes compared to an npm install -g and rarely used CLI tools can be fired off with npx, so which problem is exactly solved? That I can offer CLI tools to folks who won't have node installed? Then I rather write my CLI tool in Go and offer an appropriate package size.
I welcome competition and hence Deno but think this feature doesn't fulfill any (relevant) use case. Only beginners who struggle with the build step (which can indeed get hairy) profit from this design decision but a bit more advanced users will miss the control they had before.
Ok, the Docker client stuff is not always exciting but once you want to deploy something small, say, an app server, a DB and something like nginx or Traefik you need some orchestrator, eg k8s and then you need again images. If you prefer containerd over Docker also good.
What I am saying is which orchestration and deployment system does favor single executables atm and has a huge ecosystem? You still need to create images and do double the work. I like real binaries like Go creates but repackaging the run-time doesn't sound like a sophisticated idea but rather making the black box even bigger.
As a sibling said, for client side/3rd party apps, yeah this might be a nice-to-have but this space has rather other challenges.
Another apples to oranges comparison. OP should have compared each systems' TPU not GPU. He should redo the benchmark with a proper setup as requested in the comments here and on Medium, otherwise his post is quite misleading.
To facilitate Nvidia's tensor cores OP had to use Nvidia's own TF distr./image and configure it explicitly. Something PyTorch does out of the box. Nobody knows why Google doesn't do this, maybe they want to push their own Cloud TPUs.
> Adding PyTorch support would be high on my list.
Won't happen. PyTorch needs Apple's help bc of the lack of docs, they've asked already and Apple hasn't commented or promised any kind of support, nothing. That they've chose TF instead of the current market leader doesn't give me too much hope and might come from backroom deals we don't know of.
Wondering why OP didn't invest the money into a 2nd 2080 Ti.
Please help me to understand: If I deploy my apps as Docker images anyway why would I need this? Deno 1.6 just packages the runtime creating a huge file, still smaller than a Docker image but with latter I have a better deployment experience meaning there's a huge ecosystem and tooling around. No rant, just trying to get what I miss.
OT: Just a second ago, I was setting up unattended-upgrades for security updates
for a new Ubuntu box and I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature. Long story short, I welcome any new contender in the OS space.
Tried habit-forming measurements, they've never worked and feel like a scam from the self-help industry.
> forcing yourself to go to the gym every day
This also never worked for me. While going to the gym is super effective, I found it the most boring and brain-deadening activity ever—I degenerate there even more than browsing Reddit for two hours. In contrast, I don't have a problem to motivate myself to go and play Tennis, without any habit-forming voodoo.
> I’m not sure if I understand what you are looking for.
I like OP's post but would love to get some empirical data.
> If I’m “hyper-productive” and “focused” on my “worst day”, it obviously wasn’t my worst day?
Good q, I could also have asked: What's your system to overcome set-backs which usually distract you and turn an ok day into a bad day. Or just, how to turn a lazy or bad started day into a good day.
Good point, I should have explained it. To get into vim takes time and to get muscle memories at least 9-12 months. Something a lot of coders even don't do, so why should a data scientist do this. The result is that you are so much faster because most of the time you don't write code but stare at your code, navigate around and do small changes. So, I think if you deal with code 80% of your day, vim binds are a must and this was my biggest gripe with these notebooks. Google Colab is the only notebook offering painless vim binds. No other notebooks has proper vim support because data scientist are not coders and rather care about math.
Hijacking this thread for a simple price comparison: Since people recommend to buy a domain and connect this to some service. The problem is that this service will run for decades as a private plan, so let's do together a price and feature comparison since the lock-in is huge.
GSuite:
- pros: vast ecosystem of GMail extensions, eg mail merge
- con: just 30gb total storage
MS:
- pros: 50GB email, 1TB cloud, Office apps included (not that I like them but sometimes you still need them), dirt cheap family plan for $30+ you get 6tb
Yandex:
- free, but yeah all my serious stuff like bank accounts there, IDK
iCloud:
- super expensive
Dropbox:
- no email and ios camera upload broken/lags years behind for ages and super expensive
What do you think? Are there any better options out? Which would you take?