Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.10 Release Notes

deno.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Deno 1.10 Release Notes

#131

Post by cdaringe »

andrew_ wrote: post #93
intellix wrote: post #43

How is the built in testing? I'm a bit wary because Jest is so good and wonder if it can compete on every front it's baking in. It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.

I know a fella working on a Deno port of Ava ( https://github.com/avajs/ava ). When that and Koa are ported or compatible, I'll be giving Deno a legitimate go.

Deno test has been fine. oak exists for koa like middleware oriented servers

Re: Deno 1.10 Release Notes

#132

Post by HelloNurse »

irrational wrote: post #124
1_player wrote: post #69

Earlier quoted context omitted.

I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time. Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quick…

There is nothing stopping you from looking at their code and, after vetting it, copying the code and pasting it into your own local JS files. Now you don’t have to worry about anyone tampering with it after you have vetted it.

In practice, you rely on libraries that are popular and/or written by someone trustworthy. "Vetting" libraries amounts to thorough tests of the complete application.

Re: Deno 1.10 Release Notes

#133

Post by HelloNurse »

doteka wrote: post #119
mmbleh wrote: post #103

Earlier quoted context omitted.

> It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.

Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web? I’m trying hard to think of any, Java and Python come closest but both fall short.

There are vibrant and active communities around good projects, but npm is the greatest known repository of abandoned, obsolete, not very good and potentially malicious libraries. The bad scales up along with the good; great tools on npm don't make the Leftpad fiasco more forgivable or technical shortcomings less bad.

Re: Deno 1.10 Release Notes

#134

Post by [deleted] »

BatteryMountain wrote: post #113
echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package. It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trus…

[deleted]

Re: Deno 1.10 Release Notes

#137

Post by pythonaut_16 »

FractalHQ wrote: post #105
nesarkvechnep wrote: post #27

Earlier quoted context omitted.

Try Elixir and thank me later.

How’s the lack of static types treating you? Honest question as someone looking at Gleam.

I've generally had less typing issues in Elixir than I had when working in Python (which generally wasn't a ton but varied a lot depending on the library).

I've found that Elixir's functional programming model generally alleviates type issues. You're always thinking about what you are passing into a function or what function you are calling and with what data structures.

A lot of type issues in JS, Ruby, Python, etc. seem to come from the mutability and object oriented parts.

Re: Deno 1.10 Release Notes

#138

Post by 1_player »

irrational wrote: post #124
1_player wrote: post #69

Earlier quoted context omitted.

I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time. Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quick…

There is nothing stopping you from looking at their code and, after vetting it, copying the code and pasting it into your own local JS files. Now you don’t have to worry about anyone tampering with it after you have vetted it.

Sure, I'll do that next time I'm at work, I'll tell the frontend dev running `npm install next` to spend the next 6 months doing a code review of the 258 dependencies in the tree. Boss will have to wait.

https://npm.anvaka.com/#/view/2d/next

There's dependencies like webpack, and "dependencies" like lodash-sortby, is-number, isarray, diffie-hellman, encoding, is-negative-zero or assert. Who in good faith can argue that those are better served as standalone dependencies maintained by who-knows-who instead of being in a standard library?

I so wish someone had the balls (and good enough OpSec) to inject malware into one of those 5 lines long dependencies, causing hundreds of billions of dollars in damages, and then we'll perhaps do something about it.

Re: Deno 1.10 Release Notes

#139

Post by doteka »

HelloNurse wrote: post #133
doteka wrote: post #119

Earlier quoted context omitted.

Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web? I’m trying hard to think of any, Java and Python come closest but both fall short.

There are vibrant and active communities around good projects , but npm is the greatest known repository of abandoned, obsolete, not very good and potentially malicious libraries. The bad scales up along with the good; great tools on npm don't make the Leftpad fiasco more forgivable or technical shortcomings less bad.

Fair enough, but I have no idea how that can be avoided if we take Sturgeon’s Law as a given: 90% of everything is garbage.

I’d argue an essential quality in a modern software engineer is ‘good taste in dependencies’, if you will. Adding a dependency for padding a string with whitespace would have gotten you a friendly but stern lecture from a senior dev, in every good team I’ve been a part of so far.

Re: Deno 1.10 Release Notes

#140

Post by breatheoften »

littlestymaar wrote: post #64
oblio wrote: post #23

Earlier quoted context omitted.

If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.

Look at the python ecosystem and you'll see that it's not the case. Because of its compatibility commitment, a standard library cannot evolve much and its features end up being replaced with external libs. “The standard library is where modules go to die”

Isn't that one of the big justifications for not bundling the standard library?

It seems to me like not shipping the std library with the runtime is potentially one of the biggest language innovations we've seen in awhile because it should allow the std library to evolve over time in a much more graceful way ... -- you'll actually be able to make breaking changes to the std library as folks who are unwilling to update their code can just use the older version (until the ossified code becomes irrelevant which eventually code that is never changed eventually will)

Post reply on HN