171–180 of 284 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…
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…
Earlier quoted context omitted.
> A lot of languages are doing single static binary deploys now As a developer for more than 30 years, I find that statement quite interesting. When I was a kid I was very happy to find a way to compile Basic to an executable like I was doing in Pascal and C++. For me is the standard way of thinking about applications. Is it a common experience to actually have to ship many files for one application? I thought that i…
Containers changed the game. 99% of Deno/Go/Rust server software will be running on containers in practice. You're no longer deploying to a system running other programs which may share pages. It's a container, not a process. Dynamic linking in a container is just a vestigial useless step.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
Sure, and you can do something similar with C and obtain a ~10kb executable, or even less if you put some effort. Or write that in Java and need a complex setup including the JRE and a bunch of packages to support it. The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.
My point is, what is even the point of using Deno? If its for static typing... well Go has that. So what is the benefit?
Yeah, and the executable is 47 MB. You can do the same thing with Go: package main import "os" func main() { for _, s := range os.Args[1:] { o, _ := os.Open(s) os.Stdout.ReadFrom(o) } } and the executable is 1 MB.
This would be more comparable to packaging a Java program into an executable, which would have to also contain the JIT. I don't think it's fair to compare a JIT'd language to a AOT'd language.
Earlier quoted context omitted.
Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel. I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or…
I did too, but the amount of compiler configurations out there kills me. If you write a library, you need to support several export types for node packages. In your `package.json` you must include a `main` `module` and `exports` object and provide two compiled outputs, one commonjs and one es modules. Then you need to worry about mutating import paths to include the file extension, which can cause trouble when you ke…
This is a hassle, but didn't used to be true for node - you could say the same as all the above for commonjs, wasn't it nice to have a single opinionated standard.
In the short term, deno avoids this by dropping backwards compat, great! But in the long term, I don't see how it doesn't end up in exactly the same place as soon as the next big change to JS modules comes out, or the next new build environment or wasm integration becomes bigger or...
Unless they have a fundamentally different strategy for the future (either 'we will never evolve' or 'we will evolve with ecosystem-wide breaking changes') they're going to end up in the same state as node today, eventually. I haven't seen any discussion of such a strategy at all. It's just a temporary reset - unlike node, they get to break backward compat and support the One True Format because they're new, that's all.
Earlier quoted context omitted.
> A lot of languages are doing single static binary deploys now As a developer for more than 30 years, I find that statement quite interesting. When I was a kid I was very happy to find a way to compile Basic to an executable like I was doing in Pascal and C++. For me is the standard way of thinking about applications. Is it a common experience to actually have to ship many files for one application? I thought that i…
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.
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 sailed a loong time ago) and compilation (we have 10000x as powerful computers now).
Earlier quoted context omitted.
I'm using vercel/pkg as well. I have a Node.js server which generates HTML and opens a browser on Windows which then asks the server for that html at 127.0.0.1. So browser will be my GUI and Node.js packaged with vercel/pkg my back-end. It is more flexible than say Electron because GUI can be anything I want it to be. My concern is only will users accept a local server running on their desktop. I've tried to configur…
I am trying to do this too. But I would like to make it work on MacOS as well. The problem there is Safari does not let you connect to localhost over http. So if Safari is the preferred browser of the user, you need to convince them to change, which is hard. Or is there à better way there?
One problem is however that there is no easy way to get Safari to run in chromeless/app mode (without browser/url bar etc), which you can do in most other browsers using --app=url flag