heh, I knew for sure Deno would be successful from the first moment it appeared on HN and people here were critical of it.
My rule of: The more HN criticizes it, the more likely it succeeded, still rings true.
Deno raises $21M
191–200 of 397 posts
Re: Deno raises $21M
#192Somebody doesn't understand O notation.
I also didn't get it. so I think in their notaion O(10) has greater magnitude than (>) O(1)
You're expected to read it out loud (in English), where one of the conventional readings of O(f) is "order of f". Conveniently "order of 100" is usually taken to mean not asymptotic behavior bounded by a constant multiple of 100, but a range within an order of magnitude or so of 100.
Which is to say, they're saying Deno has a cold start time of ~100 ms, package size ~10M, a physical machine can support ~1k instances.
Re: Deno raises $21M
#193Quoted post unavailable.
My experience with Deno has been:
- I don't need to mess with third-party tooling, half a dozen project configs, etc because everything is built-in and Just Works
- The standard APIs are mostly wonderful- modern, promise-based, practical, etc. Documentation leaves something to be desired and many core APIs are still unstable (in that they get breaking changes (though you can easily pin to a specific version)), though for most of the ones with direct analogs in Node you can honestly just follow the Node docs
- Standardized importing is awesome; we may finally leave behind the nightmare of multiple coexisting module systems
- Standardized testing is awesome
- The lack of an install step is awesome
"Isaac Ryan has so far solved none of the problems that exist in the node ecosystem" is simply wrong, and feels like a cheap and uninformed dig rooted in some personal beef you must have.
Re: Deno raises $21M
#194Quoted post unavailable.
Personally I got the sense that the Go community doesn't really care for web apps or anything too close to React, but maybe I'm just not experienced enough yet with Go. Is there something like CreateRustApp but with Go? https://github.com/Wulf/create-rust-app
I think you are right. Go devs seem content with their mark position/ranking. Use Rust if it is providing more resources that are helpful to you.
Re: Deno raises $21M
#195Interesting raise. I leave the front marketing page of Deno Deploy open in my browser for a few moments and I get the ubiquitous "This webpage is using significant energy. Closing it may improve the responsiveness of your Mac."
Says it all about the state of the JavaScript ecosystem really.
Re: Deno raises $21M
#196The business end here is Deno Deploy - a heroku-like. That's what the "startup" behind the funding is. The tech is in service of that.
Re: Deno raises $21M
#197Does this mean we can finally get a REPL where a file can be loaded, modified, then reloaded, without having to restart the whole thing? Seriously my biggest pet peeve with both deno and node.js. In every other REPL I've used this is basic functionality. When I talk about this to JS people they look at me like I'm from mars.
JS modules can produce side effects on load. Does that present an obstacle to that kind of REPL pattern?
Re: Deno raises $21M
#198This question is going to make me sound like a jerk, but why do you want to write your back-end in JS? Deno looks like a great improvement over node.js, but I don't feel compelled to use it. It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like…
I've written up an at-scale production backend in Node.js and can very much stand by the decision to use Node over Elixir or Go (which I was considering at the time). I think fundamentally, the power of a JS-based backend is its pragmatism--it's not the best at most things, but it comes very close to it in so many categories that it's a safe option for a lot of use cases. > It seems like people jumped to node based o…
And the performance argument isn't even just about CPU time, right? The fact that JS is heavily event-friendly, and all of its IO APIs are non-blocking by default, gives it an automatic advantage over busy-waiting languages like Python, and also languages where concurrency means writing threads manually. If your web server spends most of its time on IO (network, DB, file system), as many do, JS acts as a lightweight task-delegator to a highly parallel and performant native runtime.
I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make
Re: Deno raises $21M
#199The rise of JavaScript-only clouds intended as "defacto" solutions for web development scares the hell out of me. Monocultures are dangerous. At least in the early Node era, it sat alongside all the other flavors of server infra out there with a near-infinite variety of languages, platforms, OSes. Now we're being told that the future of web development is…Deno? That's it? One tool? One language? One platform?
Not the web I intend to build and participate in, I can tell you that right now.
Re: Deno raises $21M
#200Does this mean we can finally get a REPL where a file can be loaded, modified, then reloaded, without having to restart the whole thing? Seriously my biggest pet peeve with both deno and node.js. In every other REPL I've used this is basic functionality. When I talk about this to JS people they look at me like I'm from mars.
JS modules can produce side effects on load. Does that present an obstacle to that kind of REPL pattern?
I don't think so.
Most repls use a special in repl keyword to accomplish this.
For some reason the JS community can't move past "but modules are special". Ocaml has modules too and the repl can reload stuff from a file no problem.