141–150 of 284 posts
I wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem. I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM
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.
The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.
I wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem. I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM
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.
If the 47 MB executable has no dependencies other than the kernel, then in many scenarios it'd be a lot easier to deploy than if you had to separately install a language runtime. Of course, Node.js can also do this with pkg, and also I don't know whether executables produced this way really are dependency-free (although depending only on widely-available shared libraries would be almost as good).
It's not. Most advanced deployments nowadays use container orchestration where deploying is as easy. For simple deployments (eg SSGs) there're enough products on the market.
Integrating the build step hides it at the same time (good for beginners) but creates many other problems in the long run if we just talk about repackaging the run-time.
I've been using vercel/pkg with great success, in order to achieve a similar target and package a whole application into a standalone executable: https://github.com/vercel/pkg This can be useful for people wanting to do this with Node. It's nice to have a single file that can be started right away without any external dependency. And also, it prevents from having to distribute the full sources. Kudos to the Deno devs…
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 but encourage the community to compete and complement. Integrating build systems is good for beginners who struggle with them but for the rest? IDK.
Or in other words, Deno wants to be more than just an opinionated node-Typescript-distribution nobody cares about but then they need to create this ecosystem and focus on the core (what's their core and value add other than repackaging node and TS would be the next discussion).
With integrating the build step they do the exact opposite, they shut-down an ecosystem before it can even start. There's a night and day difference between good and bad build systems and only competition and a rich ecosystem can bring up the best solutions.
FWIW, there're tons of ways to compile TS, every with different trade-offs and it's good that we have these options.
Earlier quoted context omitted.
I would probably just vendor them into my own directory structure and import them as a local module. You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.
Vendoring is a last resort, that sounds like going back to the stone ages of package management. Why would I want that?
Earlier quoted context omitted.
I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.
I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have…
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 team desperately tries to climb back on stage and get our attention with minor improvements. Maybe I am ignorant but Deno feels just like an opinionated node/Typescript distribution with too little improvements but not like the successor we hoped for.
Besides, I wonder if the Deno team solved all the performance issues which popped up the last time I've read about Deno. There were some debates with the ws community but can't remember details anymore.
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.
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.
So what is the benefit?
Earlier quoted context omitted.
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.
WebAssembly supports threads and shared memory, which should make it possible to implement software-based locks in the meantime. I definitely see the issue that you're bringing up, especially wrt external interoperability.