Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

191–200 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#191
post #179
post #33

Earlier quoted context omitted.

Same here, the static linking hype feels real strange, given that was the only option we used to have back in the day, and having access to dynamic linking on 16 bit platforms felt like liberating.

PHP, JavaScript, Python, Ruby, even Java and C# didn't (don't?) have a mainstream way to create a single binary with unused code and unused dependencies removed. Dynamic linking was cool because you could use system dependencies which people don't want to use because you can't rely on them, especially for cross platform apps and also for efficiency, RAM (which people stopped caring about) and, disk space (this boat s…

Java has had static linking support since around 2000, for embedded deployments.

C#, yes it has been mostly dynamic.

PHP, JavaScript, Python, Ruby, don't count, they are scripting languages, bundled with an interpreter.

Still, Python and Perl bundlers exist since around 2000 as well.

Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where static linking was the main option.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#192
post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

It’s funny you say that because when PHP / Python / Ruby were all the rage, most people considered needing to compile everything into a single binary gross. What’s old is new is old again!

It's a circular argument and a false dichotomy tbh, they both have their place.

Ex: I maintain an 'old' PHP / JS application while building a new Go / TS one. With the old one, I change a file, it gets automatically ssh'd to my dev server, and my changes work instantly. I'm sure that if the PHP and JS had to be comp/transpiled, it would take a minute or so (it's just under 100K LOC, some files 13K LOC).

For the new application, I get the same fast feedback because Go does incremental compiles and create-react-app with TS also does incremental compiles with live reload (without requiring a full page reload).

For production builds, the old is pulled through tools like ioncube and uglify, the new one churns out an optimized binary and webpack-flavored .js files.

I mean if you zoom out enough there's no noticeable difference.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#193
post #77
post #50

Earlier quoted context omitted.

I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?

No, you're making a good point, but my meaning was that TypeScript is a language that is always (and has always been) written as an improved, benefit-of-hindsight, good-parts-only language. It does of course allow any old JS to be used, but that has always been for the purpose of allowing code already written in JavaScript to be called from code written in TypeScript. No TypeScript project, library, or tutorial is ev…

Unfortunately, that's not a very accurate analogy. TS also inherits all of JS runtime semantics unchanged, and there's just as much if not more wrongness there.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#194
post #191
post #179

Earlier quoted context omitted.

PHP, JavaScript, Python, Ruby, even Java and C# didn't (don't?) have a mainstream way to create a single binary with unused code and unused dependencies removed. Dynamic linking was cool because you could use system dependencies which people don't want to use because you can't rely on them, especially for cross platform apps and also for efficiency, RAM (which people stopped caring about) and, disk space (this boat s…

Java has had static linking support since around 2000, for embedded deployments. C#, yes it has been mostly dynamic. PHP, JavaScript, Python, Ruby, don't count, they are scripting languages, bundled with an interpreter. Still, Python and Perl bundlers exist since around 2000 as well. Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where sta…

> Java has had static linking support since around 2000, for embedded deployments.

Yeah, but for non-embedded deployments i.e. 99% of Java code out there?

> Still, Python and Perl bundlers exist since around 2000 as well.

I don't know the Perl one, but the Python ones definitely aren't mainstream. They're finicky and relatively hard to use and definitely not distributed with the Python distribution, which would make them ubiquitous and well supported.

> Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where static linking was the main option.

Every language in the olden days had static compilation support :-))

That's why we had articles such as these: https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... (which I agree with)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#195

Earlier quoted context omitted.

OK, so what is Deno? How is it different from Node? Why did you make Deno given that Node exists? Looks like Deno can run .ts files without first compiling to .js. What are the other benefits?

Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…

Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files.

Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs.

Loading modules from URL's is a cool concept! ES modules helps here, but you could also have a package-list file that lists all dependencies of dependencies as well as download mirrors, or hashes with peer-to-peer distribution.

A permission system is nice, modules should not have system access by default.

Not everyone wants to use TypeScript. It will probably become obsolete once optional type annotations gets added to JavaScript.

An opinionated toolchain is nice, but should be optional IMHO.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#196
post #194
post #191

Earlier quoted context omitted.

Java has had static linking support since around 2000, for embedded deployments. C#, yes it has been mostly dynamic. PHP, JavaScript, Python, Ruby, don't count, they are scripting languages, bundled with an interpreter. Still, Python and Perl bundlers exist since around 2000 as well. Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where sta…

> Java has had static linking support since around 2000, for embedded deployments. Yeah, but for non-embedded deployments i.e. 99% of Java code out there? > Still, Python and Perl bundlers exist since around 2000 as well. I don't know the Perl one, but the Python ones definitely aren't mainstream. They're finicky and relatively hard to use and definitely not distributed with the Python distribution, which would make…

> Yeah, but for non-embedded deployments i.e. 99% of Java code out there?

100% of commercial JDKs have support for AOT compilation, what you are getting nowadays on OpenJDK is the free beer version of it.

> I don't know the Perl one, but the Python ones definitely aren't mainstream.

They surely were mainstream on Windows back in .com days, specially via py2exe and ActiveState tooling.

> Every language in the olden days had static compilation support :-))

Many of which are still mainstream languages.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#197
post #196
post #194

Earlier quoted context omitted.

> Java has had static linking support since around 2000, for embedded deployments. Yeah, but for non-embedded deployments i.e. 99% of Java code out there? > Still, Python and Perl bundlers exist since around 2000 as well. I don't know the Perl one, but the Python ones definitely aren't mainstream. They're finicky and relatively hard to use and definitely not distributed with the Python distribution, which would make…

> Yeah, but for non-embedded deployments i.e. 99% of Java code out there? 100% of commercial JDKs have support for AOT compilation, what you are getting nowadays on OpenJDK is the free beer version of it. > I don't know the Perl one, but the Python ones definitely aren't mainstream. They surely were mainstream on Windows back in .com days, specially via py2exe and ActiveState tooling. > Every language in the olden da…

I know you're aware of this, but 70% of the languages in your list are niche languages and especially for web development they weren't that popular.

It was (is?): PHP, Javascript, Java, Python, Ruby, C# or nothing.

Especially the dynamic languages are extremely popular, primarily with smaller companies and startups.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#198
post #148

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 t…

> Even worse, it creates the notion that the Deno team desperately tries to climb back on stage and get our attention with minor improvements.

That seems an uncharitable interpretation. Ultimately they're creating tools for our benefit. They may or may not be useful to you personally, but the creation of value should still be applauded, not dismissed as attention seeking.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#199
post #151

Earlier quoted context omitted.

Why anyone would look at the litany of mistakes that is npm and Node, then look at Deno and all of the same developers learning nothing except how to implement its "hurr durr URL loading code is cool" approach to security and think "this a good idea" is beyond me. I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any…

Hiring people based on their ability to predict your own idiosyncratic hatreds of specific technologies is just a horrible idea. It also ensures your ideas never get challenged and you never improve.

Well, at least its mutually beneficial because they sound like a pain to work with.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#200
post #197
post #196

Earlier quoted context omitted.

> Yeah, but for non-embedded deployments i.e. 99% of Java code out there? 100% of commercial JDKs have support for AOT compilation, what you are getting nowadays on OpenJDK is the free beer version of it. > I don't know the Perl one, but the Python ones definitely aren't mainstream. They surely were mainstream on Windows back in .com days, specially via py2exe and ActiveState tooling. > Every language in the olden da…

I know you're aware of this, but 70% of the languages in your list are niche languages and especially for web development they weren't that popular. It was (is?): PHP, Javascript, Java, Python, Ruby, C# or nothing. Especially the dynamic languages are extremely popular, primarily with smaller companies and startups.

The whole point of my discussion doesn't have anything to do in which field the languages are popular.

Zope and AOL Server teached me that those dynamic languages are really only good for OS scripting tasks anyway, but that isn't the subject of this thread.

Post reply on HN