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

Deno 1.0

deno.land

Post reply on HN
Print view View original

571–580 of 598 posts

Re: Deno 1.0

#571

Post by ajnin »

The fundamental problem of dependency management, as anyone who ever kept bookmarks knows, is that the external sources might go away at any time. It's not a problem unique to Deno or Go. Take Java for example, its standard dependency management tool is Maven, which relies on external repositories of artefacts to function. From time to time, a repository might go down, or it might be moved to another address, or a library might be migrated to another repository. Whenever this happens, your build might break. The solution is to proxy all requests at the organizational level through your own server which keeps a mirror of any package that has been referenced once. That way, if it become unavailable externally, then you can still use it internally. You can also override packages with patched versions if they misbehave.

I think that Deno should define a standard dependency fetching protocol, and allow proxying transparently at a native level. If it does, that kind of dependency management will be fine.

Re: Deno 1.0

#572

Post by z3t4 »

regularfry wrote: post #538
tuukkah wrote: post #413

Earlier quoted context omitted.

Typically, chmod and iptables are not used to restrict applications. Applications are restricted by virtual machines, containers, sandboxes, AppArmor profiles, SELinux policies…

There's a fairly long history of giving applications their own uid to run under which puts chmod and chown in control of filesystem operations the app is allowed to perform. "Typically" maybe not, but it's hardly unusual. iptables + namespaces gives you the rest.

+ you can make a network namespace and have separate iptables just for that namespace/app, you can for example give the namespace/app a VPN connection without affecting the rest of the system. And other apps can join the namespace and communicate as if they had their own isolated network.

NodeJS is also working on policies (1) which allows you to change permission to single modules or files.

1) https://nodejs.org/api/policy.html

Re: Deno 1.0

#573

Post by z3t4 »

grandinj wrote: post #546
nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

v8 has the ability to snapshot a program just after it loads, but before it executes. If you snapshot after doing some kind of warmup, to trigger the right optimisations, you get something that should fire up ready to go, which is probably the main problem - the compiler being repeatedly invoked and parsed from javascript and compiled on the fly.

One problem with taking the v8 snapshot and using it as a binary executable is that it will probably be much slower then running v8 live. Although the startup time will be 10x faster. The runtime will be 10x slower.

Re: Deno 1.0

#574

Post by sequoia »

I am a long-time Node.js user. My question about Deno is "is there any indication that this project will have a different trajectory from the node.js project (also started by some of the same people as Deno), or should I expect Deno to also follow a 10 year arc?"

I think evolution & starting over can both be appropriate steps forward, I don't question the Deno project, but to have the exact same people who created Node.js say "OK here's the new new JS hotness," I think "how can we expect this time to be different" is a reasonable question. Or perhaps these ecosystems are not meant to last/be supported more than 10ish years?

Re: Deno 1.0

#575

Post by z3t4 »

xevrem wrote: post #564
mekster wrote: post #548

Earlier quoted context omitted.

> what happens when popular-library.io goes down or gets hacked? What is anyone going to do about it? Anything has a chance of getting hacked or goes down just when you need it, be it GitHub, npmjs.org... Blaming the tool for not having a protection against DNS poisoning is a bit far fetched.

ultimately i guess it is about how/if deno caches its imports. with node.js/npm you have the exact same problems, just the source & sink occur at different places (package installation)

With Node.js you install the packages in a dev environment, and test extensively, then push all the code, including node_packages folder to production. Running npm on the prod server is forbidden. At least in theory =)

Re: Deno 1.0

#576

Post by WorldMaker »

grandinj wrote: post #546
nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

v8 has the ability to snapshot a program just after it loads, but before it executes. If you snapshot after doing some kind of warmup, to trigger the right optimisations, you get something that should fire up ready to go, which is probably the main problem - the compiler being repeatedly invoked and parsed from javascript and compiled on the fly.

The notes here mention that V8 snapshots also didn't provide the speed-up/optimization Deno was hoping for.

Re: Deno 1.0

#577

Post by z3t4 »

qudat wrote: post #290
littlestymaar wrote: post #186

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

Checking in dependencies to version control is the sane option. Then you can more easily see what's updated and track regressions. Some people like to refactor their code any time there is a syntax sugar added to the language - often adding a few bugs while doing it, which is a PITA, but version control is still better then no version control.

You will ask, what about adding the OS to your SCM too, yeh why not have the full software stack. But you can generally draw a line between strong abstraction layers: Hardware | Kernel | OS | runtime | your app. Some modules do have strong abstraction layers, but others are just pure functions which you could just as well copy into your own repo.

Re: Deno 1.0

#578

Post by WorldMaker »

nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

This does seem like a dangerous side-path unrelated to the Deno project's needs.

From the description, it doesn't sound like Deno needs the type information for V8 optimizations (I thought they had explored that, but I don't recall, and the description here is unclear), so maybe switching to more of a two pass system of a simple as possible "type stripper" (like Babel's perhaps?) and leave tsc compilation for type checking as a separate background process. Maybe behind some sort of "production mode" flag so that type errors stop debug runs but in production assume you can strip types without waiting for a full compile?

Maybe even writing a type stripper in Rust isn't a bad idea, but definitely trying to capture all of tsc's functionality in Rust seems like a fool's errand.

Re: Deno 1.0

#579

Post by lenkite »

gpm wrote: post #569
lenkite wrote: post #568

Earlier quoted context omitted.

Weird, it still says that "Cisco Umbrella Root CA" is not trusted. Maybe its only from certain countries.

I'm Canadian and in Canada for what it's worth. Clicking on the lock tells me that it was verified by lets encrypt. The root is "Digital Signature Trust Co." Common Name "DST Root CA X3". Cisco sounds like a router might by running a MITM on you? Edit: This looks to be confirmation that that root (or one by a very similar name) is used by a MITM tool: https://docs.umbrella.com/deployment-umbrella/docs/rebrand-c...

Thanks for the diagnosis. Accessed from a different network and with no issues. And got the right certificate this time.

Re: Deno 1.0

#580

Post by z3t4 »

dgellow wrote: post #372
bgdam wrote: post #192

Earlier quoted context omitted.

Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.

You had 5 minutes startup time?!

More then one second and people will test their code less often. Five minutes and people start relying on the type-checker. Like with the chicken and egg problem, what came first, the type-checker or the need to have a type checker?
Post reply on HN