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

Deno 1.6 supports compiling TypeScript to a single executable

github.com

Post reply on HN
Print view View original

101–110 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#101

Post by mark_and_sweep »

nikisweeting wrote: post #98
mark_and_sweep wrote: post #92

Earlier quoted context omitted.

> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager , but an argument for a central package r…

I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.

> I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path.

Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_map...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#102

Post by loosescrews »

kibwen wrote: post #49
loosescrews wrote: post #14

Earlier quoted context omitted.

Do they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.

I think the belief that Go does no dynamic linking whatsoever is outdated; I seem to recall that they recanted this approach on Mac and Windows since these platforms only offer a stable system interface via dynamically-linked libraries, and trying to re-implement all of it ended up being a lot of work only to end up with broken code after system updates. On Linux I think Go still tries to link mostly statically, but…

Go supports dynamic linking and most Go binaries will be dynamically linked. On Linux, this is mostly due to optional features which can be easily disabled. The optional features are all related to supporting rare and unusual system configurations and do not affect normal operation. Note that cross compilation with Linux as the target does not support dynamic linking, so all Go Linux binaries compiled on a non-Linux OS will be statically linked.

Regardless of how we scope it, Go is still the only mainstream language capable of producing statically linked Linux binaries without libc while still allowing full use of the standard library.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#103

Post by zubairq »

miohtama wrote: post #83
cocktailpeanuts wrote: post #51

Earlier quoted context omitted.

I'm not very familiar with Deno but I wonder how deno compile compares to pkg when it comes to native modules. One of my gripes with PKG (and all other node.js packaging tools) has been that it's a pain in the ass to package when your dependency includes a native module, for example SQLite. Since Deno has a different architecture and works in different ways, thought I would ask just in case there's a solution for thi…

WebAssembly fixes this.

Not really as the WASM version of Sqlite is memory only and cannot write to disk. Please feel free to correct me if this has changed though

Re: Deno 1.6 supports compiling TypeScript to a single executable

#104

Post by tracker1 »

miohtama wrote: post #83
cocktailpeanuts wrote: post #51

Earlier quoted context omitted.

I'm not very familiar with Deno but I wonder how deno compile compares to pkg when it comes to native modules. One of my gripes with PKG (and all other node.js packaging tools) has been that it's a pain in the ass to package when your dependency includes a native module, for example SQLite. Since Deno has a different architecture and works in different ways, thought I would ask just in case there's a solution for thi…

WebAssembly fixes this.

webassembly doesn't support file locking for sqlite databases that would allow for other processes to interact with the same database your application uses. It's actually one of my biggest gripes. You can use it in-memory and save the output or use a different database approach, and lose the features of sqlite.

Of course, a different kind of database, similar to say leveldb could work in single-process mode.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#105

Post by tracker1 »

zubairq wrote: post #103
miohtama wrote: post #83

Earlier quoted context omitted.

WebAssembly fixes this.

Not really as the WASM version of Sqlite is memory only and cannot write to disk. Please feel free to correct me if this has changed though

Nope... the wasm fs adapters don't allow the flexibility needed to really operate correctly.

It might be best to try alternatives like wrappers around leveldb as a baseline, which of course isn't sql and has its' own drawbacks.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#106

Post by loosescrews »

hetman wrote: post #96
loosescrews wrote: post #14

Earlier quoted context omitted.

Do they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.

Rust has supported statically linking to MSVC and musl for a while now but also added static glibc support on Linux very recently: https://github.com/rust-lang/rust/pull/77386

Is it possible to compile with statically linked musl with the pre-built Rust toolchain on a standard glibc based distribution?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#107

Post by loosescrews »

pjmlp wrote: post #26
loosescrews wrote: post #14

Earlier quoted context omitted.

Do they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.

Ada, FreePascal, C and C++ do perfectly fine. Not everyone is using Linux with glibc linking issues.

Using C and C++ without libc excludes the use of nearly all common libraries.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#108

Post by josephg »

wmf wrote: post #48
SiVal wrote: post #36

Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict what will work out and what won't in the future, and this was one of those frustrating cases like carving in stone, where every mistake you make is permanent. But a combination of various factors made the web an enormously impactful medium. It's too important to…

I'm pretty sure multicore was a thing in 2009, though.

It was, and since 2009 the recommendation has been to run an instance of nodejs per CPU core. The justification is that if you're already scaling your app between servers, you shouldn't need a separate mechanism to scale across multiple cores in a single server.

I'm not sure when the cluster API was added, but its been in nodejs's core for a long time. (Not that you need to use it, but still.)

https://nodejs.org/api/cluster.html

Re: Deno 1.6 supports compiling TypeScript to a single executable

#109

Post by nikisweeting »

mark_and_sweep wrote: post #101
nikisweeting wrote: post #98

Earlier quoted context omitted.

I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.

> I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_map...

Ah cool, that helps a ton. The existence of this feature as the linchpin for compatibility with npm is not clear from the rest of the Deno docs though. Perhaps it could be linked to from this page: https://deno.land/manual@v1.6.0/examples/import_export.

Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no?

    "imports": {
        "moment": "/node_modules/moment/src/moment.js",
        "lodash": "/node_modules/lodash-es/lodash.js"
    }
Considering it's the default in all other JS environments, wouldn't that save the hassle of the dev having to define this for their entire tree of JS dependencies? Then Deno would be a drop-in replacement and we could move our whole codebase over to it overnight (once the Node APIs are up to par).

Re: Deno 1.6 supports compiling TypeScript to a single executable

#110

Post by momokoko »

echelon wrote: post #9
mrkurt wrote: post #2

This is such a good feature. Go has been great for shipping single purpose binaries (like the CLI for https://fly.io ), but I really enjoy writing TypeScript more than Go.

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!

Post reply on HN