Live data from Hacker News

Deno 1.0

deno.land

291–300 of 598 posts

Re: Deno 1.0

#291
post #200
post #174

Earlier quoted context omitted.

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Security is literally the main selling point of this thing. Otherwise just use node.

It’s one of the selling points. One of the main points I took away was

” We feel that the landscape of JavaScript and the surrounding software infrastructure has changed enough that it was worthwhile to simplify. We seek a fun and productive scripting environment that can be used for a wide range of tasks.”

Sounds intriguing to me. As a fan of starting projects of as simply as possible, I will certainly be tinkering with Deno.

Re: Deno 1.0

#292

Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.

More than likely programming as a whole will get better because of this...

Do you trust this thing? Better off developing it yourself, or working with something you trust then.

Re: Deno 1.0

#293
post #200
post #174

Earlier quoted context omitted.

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Security is literally the main selling point of this thing. Otherwise just use node.

Promise-based APIs sold me.

Re: Deno 1.0

#294

I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own ve…

> Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports?

This is my biggest beef. When building large scale applications there are many more files with imports than a typical large scale golang project that uses the url import scheme. It's just going to be a really annoying thing to deal with. ATM I see deno being great as a replacement for nodejs scripts and smaller scale projects. But for massive projects I don't see the gain.

Re: Deno 1.0

#295
post #200

Earlier quoted context omitted.

Security is literally the main selling point of this thing. Otherwise just use node.

There are a lot selling points. To me, the main one is typescript with no build.

Clearly they have never dealt with JavaScript build tools and npm. A complete nightmare.

Re: Deno 1.0

#296

I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own ve…

> I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript.

It's constructive to make claims like people using Typescript are "pretending" to do something and should stop.

People use Typescript because they've decided that Javascript with static typing is useful.

Re: Deno 1.0

#297
post #154

Earlier quoted context omitted.

> Deno runs JavaScript faster than node Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.

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?

Re: Deno 1.0

#298

I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own ve…

How much time have spent with TypeScript? I'm sincerely asking, because the answer is either "not much" or you didn't do a lot of research. You've misunderstood (or chosen not to investigate) some very fundamental things about TypeScript.

> function add(x: number, y: number): number {...}

You don't have to do this in TypeScript. In fact, you can use TypeScript without transpiling your code and without creating any types yourself.

Why would you do that? Because a lot of open-source libraries now come with types included, so you get type-checking for those APIs essentially for free.

> I'd just use Java

Java has a nominal type system. If you want a new type, you have to create it.

TypeScript has structural typing with type inference. That means you "just code" and the compiler will pick up your types if you go. If you write inconsistent code, it'll warn you. If you want to refactor a type, you now have enough metadata for your code to do that confidently.

> When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it?

Microsoft has had its own V8 competitor since around the time TypeScript was released[1]. They literally can't leave JavaScript out of TypeScript because every JavaScript program is a valid TypeScript program. TypeScript is a superset of Javascript. Other than the type system, it does not introduce any new features that are not on the EcmaScript roadmap.

> harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy

Uh, no, it doesn't, because they have (A) open-sourced all of it, and (B) they haven't extinguished anything. Even if they did, there are massive numbers of people, including Google, who use TypeScript in production and would keep it going. There is no practical way to extinguish anymore.

In fact, all of their behavior (e.g. with the .NET ecosystem) suggests that Microsoft doesn't do those things anymore.

1. https://en.wikipedia.org/wiki/Chakra_(JavaScript_engine)

Re: Deno 1.0

#299
Just a random though but if they want speed they could consider making a typescript JIT instead of typescript -> javascript. Typed languages can run much faster than untyped. Maybe that's impossible with current typescript given anything can be changed, eg (30 minutes into running something does Math.floor = ... etc, but maybe some kind of escape analysis could help or maybe push for some new keyword to mark code as safe to optimize.

Re: Deno 1.0

#300
post #127

Earlier quoted context omitted.

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

You could use a separate git repository for the dependencies. That way you keep your core project repo tight and small and clean, but you still have your dependencies under version control. If that separate repo grows to a few GBs or more it doesn't really hurt anything.
Post reply on HN