Live data from Hacker News

Deno 1.0

deno.land

381–390 of 598 posts

Re: Deno 1.0

#381

Earlier quoted context omitted.

Why are you _regularly_ clearing lock files? If you're bypassing lock files you're going to have the exact same issue with npm or yarn or any other package manager that downloads from the internet.

Dunno about OP but I pin versions in package.json because it allows me to control the versions and upgrade major versions only when explicit and necessary, and rely only on the lock file to keep it the same between commit time and the production build.

That's fine for one developer pushing to production from their own machine. But I've you have aCI server and you're working with other people you're going to want to know that everyone is working with the same modules.

Re: Deno 1.0

#382
post #361

Earlier quoted context omitted.

Good luck finding which of foo.com/foo or bar.com/foo is the foo module you want though…

Good luck finding which of google.com/search or bing.com/search is the search engine you want though

This is true actually, and that's why being the default search engine is so important Google pays billions each year for that.

Re: Deno 1.0

#383
post #266

Earlier quoted context omitted.

We need to distinguish between npm, the service ( https://www.npmjs.com/ ) and npm, the tool. Deno has the functionality of npm, the tool, built-in. The difference is that like Go, Deno imports the code directly from the source repository. In practice it's going to be github.com (but can be gitlab or any code hosting that you, the author of Deno module, use). NPM is a un-necessary layer that both Go and Deno has remo…

How do you list the dependency libraries if you don't have a package.json? Do you manually install a list of libraries provided by the author's readme?

The simplest approach is to either import anything anywhere, or have a local module that import external dependencies and then have your code import them via that local module.

Re: Deno 1.0

#384

Earlier quoted context omitted.

I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway. You can even depend to your non-npm repo (github, urls...) from a npm-based package. If you want to "feel" as safe, you have import maps in deno, which works like package.json. Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simp…

> I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway npm installs aren't the same as installing from a random URL, because: * NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL. * NPM (the tool) stores a hash of the package in your package-lock.json, and insta…

My assumption would be that new men in the middle will arise, but this time, you can pick which one to use.

Re: Deno 1.0

#385
post #290

Earlier quoted context omitted.

True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).

> True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod. Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in

I have only used Go once at work, and I actually dislike most of it (and dependency management was one of the annoying things with Go), nonetheless it is has never been a show stopper and there have been thousands of developers using it when vendoring was the only option.

Re: Deno 1.0

#386
post #151
post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

> For that you'd have to open up network and file access pretty much right off the bat.

I think that overall you're right, but it's worth noting that deno can restrict file system access to specific folders and can restrict read and write separately. It's plausible to me that you could have a web server that can only access specific folders.

Re: Deno 1.0

#387
"Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow"

TypeScript is way too slow for what it does and that's ridiculous for a language that rejects useful features because it doesn't want to "stray too far" from ECMAScript.

In my view, typechecking doesn't belong in the "compiler" part of TypeScript. It should stay in the IDE. The compiler should just strip type annotations and do other trivial transformations.

Re: Deno 1.0

#388

> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependen…

When describing the input stream back-pressure problem: > To mitigate this problem, a pause() method was added. This could solve the problem, but it required extra code; and since the flooding issue only presents itself when the process is very busy, many Node programs can be flooded with data. The result is a system with bad tail latency. Are they saying that even with correct use of pause() there are still issues?

They're saying since the issue doesn't present itself until it's too late most code does not use pause().

Re: Deno 1.0

#389
post #154

Earlier quoted context omitted.

Can't you just pass it a .js file and it will skip the TypeScript compiling completely?

That's not gonna help if you're using any part of the standard library though (or presumably most 3rd-party modules), since it's written in TS, right?

I assume their TS parts will be pre-compiled, at they should be.

Re: Deno 1.0

#390

If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)

right on top of it Peter! nice
Post reply on HN