41–50 of 598 posts
> We believe JavaScript is the natural choice for dynamic language tooling; whether in a browser environment or as standalone processes. I disagree with this assessment. Lua is still far superior as an embed-able scripting language/runtime. I suspect the preference for JavaScript is mostly due to the Deno developers' familiarity and preference.
I disagree with this assessment.
So Lua, but Javascript? Could be neat
Are imports async by default in Deno? That seems to be how it works given that you can import from a URL. This is interesting since async imports are currently a part of JavaScript(or at least a proposal?) by using the `import()` function.
there are no "async" or "sync" imports in js. there are static and dynamic imports. An implementation is free to spend as much time as it likes between parsing a file to get the static imports and actually running the file doing whatever it likes, including fetching urls, reading the file system, etc. dynamic imports return a promise but the implementation is free to resolve that promise immediately (e.g. `return Pro…
I'm sure I'm missing something obvious in that example, but that capability terrifies me.
Earlier quoted context omitted.
And now, he'll make a whole different set of good and bad choices to potentially regret later.
such is the curse of having the audacity to develop software :)
EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
Earlier quoted context omitted.
A note on Deno and the safety of its V8 bindings: > All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself. We'll also have to wait on who will be the first to have a…
For this sort of problem Rust's safety guarantees don't buy you all that much. If you're generating machine code and implementing a GC that's not the sort of thing that Rust's typesystem can prove correct. That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.
Earlier quoted context omitted.
Who somehow still hasn't realized that backends written in Javascript don't scale very well. Automatic asynchronicity only buys you so much. I'm writing as a former Node.js user.
"Automatic asynchronicity[sic]"?! Node and all async io is cooperative multi-tasking , the opposite of automatic. The node event loop is a thin wrapper around the epoll() system-call (or one of its equivalents), and leaves the details of multi-tasking to the app developer. It's no wonder you weren't able to scale under node if you thought something was happening automatically for you!
Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts-node, which I primarily used previously.) I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support.…
Seconded, a Deno TS REPL would be amazing, but they probably have a few bigger fish to fry yet :)
> fish
I see what you did there, and I approve.
if you require modules by URL, how does it make sure that the URL always contains the same library? I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?
This is something that we'll further work out in future versions. For now you can use a lockfile: https://deno.land/manual/linking_to_external_code/integrity_...
HALLELUJAH that there is a clear, simple separation of when (a) you expect a lock file to be checked to guarantee integrity and (b) when you want it to be generated. The complete insanity that was npm shrinkwrap and lockfiles for years, summed up in this stackoverflow post https://stackoverflow.com/questions/45022048/why-does-npm-in... , always baffled me in that it seemed like it could have just been so easily avoided about being explicit when you're writing a lockfile vs. when you're using it.
That said, why not be even MORE explicit about it, i.e. "--use-lock=lock.json" vs. "--write-lock=lock.json"?
> We believe JavaScript is the natural choice for dynamic language tooling; whether in a browser environment or as standalone processes. I disagree with this assessment. Lua is still far superior as an embed-able scripting language/runtime. I suspect the preference for JavaScript is mostly due to the Deno developers' familiarity and preference.
> Lua is far superior I disagree with this assessment.
[0] https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...