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

What the Hell Is a Deno?

breadth.substack.com

Post reply on HN
Print view View original

141–150 of 151 posts

Re: What the Hell Is a Deno?

#141

Post by brabel »

osrec wrote: post #133
brabel wrote: post #132

Earlier quoted context omitted.

Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about! The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how…

I'm no expert on compilers/interpreters, but wouldn't the added overhead of type checking cause things to slow down (genuine question)?

No, because it does the type checking already: it just fails to keep the type data into the runtime, which could be highly optimized if it had types. V8 apparently "generates" types on-the-go to make JS run fast, so if it had pre-built types it could already run the faster version of the code from the start.

Re: What the Hell Is a Deno?

#142

Post by osrec »

brabel wrote: post #141
osrec wrote: post #133

Earlier quoted context omitted.

I'm no expert on compilers/interpreters, but wouldn't the added overhead of type checking cause things to slow down (genuine question)?

No, because it does the type checking already: it just fails to keep the type data into the runtime, which could be highly optimized if it had types. V8 apparently "generates" types on-the-go to make JS run fast, so if it had pre-built types it could already run the faster version of the code from the start.

Ah, understood. So, almost like Java compiling a class to bytecode before running in the JVM?

Re: What the Hell Is a Deno?

#143

Post by rad_gruchalski »

rhlsthrm wrote: post #71
knome wrote: post #30

Earlier quoted context omitted.

I dislike javascript for much the reason you love it. Promises just mean having to manually build and manipulate cooperatively multitasking green-threaded call-stacks. It was a dirty necessity following the inability of the earlier callback patterns to manage the level of complexity people were attempting to express in the language.

As someone with most of my coding experience in JS/TS, what would you say is a good alternative to explore?

Erlang.

Re: What the Hell Is a Deno?

#145

Post by colejohnson66 »

galaxyLogic wrote: post #60
fastball wrote: post #35

Earlier quoted context omitted.

Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.

I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".

The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills.

Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.

Re: What the Hell Is a Deno?

#146

Post by brabel »

osrec wrote: post #142
brabel wrote: post #141

Earlier quoted context omitted.

No, because it does the type checking already: it just fails to keep the type data into the runtime, which could be highly optimized if it had types. V8 apparently "generates" types on-the-go to make JS run fast, so if it had pre-built types it could already run the faster version of the code from the start.

Ah, understood. So, almost like Java compiling a class to bytecode before running in the JVM?

Yes, something like that. Interestingly enough, Dart has a mode to compile to the AST, so that when you run it, the interpreter does not need to parse the text again and check the types, it just starts straight off an AST. The TS compiler and V8 could definitely do something similar.

Re: What the Hell Is a Deno?

#147

Post by fastball »

colejohnson66 wrote: post #145
galaxyLogic wrote: post #60

Earlier quoted context omitted.

I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".

The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills. Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.

I think the problem is less that it is interpreted and more that there are many different interpreters for different platforms, all of which are competing.

Python is also interpreted, but there isn't much problem changing the stdlib because CPython runs pretty much everywhere you need it to. Sure, there are other interpreters like PyPy that also need to implement changes to the lang, but it's not a show-stopper like it is with browsers.

Re: What the Hell Is a Deno?

#148

Post by peheje »

hombre_fatal wrote: post #106
thelazydogsback wrote: post #28

Earlier quoted context omitted.

Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node…

I'm not being unfair when I enumerate the most popular languages for comparison. When people crap on Javascript, they presumably prefer another language. And C#/Kotlin aren't exactly the top picks. Kotlin has BYOB coroutines which are hard to work with. People don't use them. Going with the C# approach where async behavior looks sync was a bad move. I predict Kotlin's coroutines will never be a centerpiece abstractio…

Whats wrong with something like this

  import kotlinx.coroutines.*
  import kotlinx.coroutines.channels.Channel

  fun background(): Channel {
      val ch = Channel()
      GlobalScope.launch {
          delay(5000)
          ch.send("OK")
      }
      return ch
  }

  fun getWebsiteData(url: String): Channel {
      val ch = Channel()
      GlobalScope.launch {
          delay(4000)
          ch.send("website data")
      }
      return ch
  }

  fun work(): Channel {
      val ch = Channel()
      GlobalScope.launch {
          delay(1000)
          ch.send("work result")
      }
      return ch
  }

  fun main() = runBlocking {
      println("START")
      val bck = background()
      val urls = listOf("www.web1.com", "www.web2.com", "www.web3.com", "www.web4.com")
      val chs = urls.map { getWebsiteData(it) }
      generateSequence { work() }.take(4).forEach {
          println("sync job done: " + it.receive())
      }
      chs.forEach {
          println("data fetched done: " + it.receive())
      }
      println("background done:" + bck.receive())
      println("END")
  }

Re: What the Hell Is a Deno?

#149

Post by pdimitar »

hombre_fatal wrote: post #111
theshrike79 wrote: post #80

Earlier quoted context omitted.

Go with goroutines and channels is a nice way to handle concurrency. At least it was the one that was easiest for me to wrap my head around and actually improved the performance of my code without weird race conditions or bugs.

Go concurrency is basically threads + the ability to choose between classic mutex synchronization (and all the problems with that like reentrancy bugs) or burn yourself in channel hell with deadlocks and buffer bloat.

Have to you agree with you there. I was pretty hyped for Go some 4-5 years ago but discovered its parallelism/concurrency model was essentially mutexes / condition variables / bounded queues when you get down to it. It's an improvement over doing it manually -- but definitely not a big one.

Re: What the Hell Is a Deno?

#150

Post by randombytes6869 »

SPBS wrote: post #76
randombytes6869 wrote: post #58

Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS is better than Java now that we have X" even though Deno brings JS closer than ever to Java. Despite being cynical, I don't think its a bad thing. Java does a lot of things right. Deno -> Java Runtime security options -> Security Manager. URL based packages with simple HTTP-> Maven works same way. Bigger standard library -> Java's is huge.…

Funny, I thought it was the Go-fication of JavaScript. Look at the 'contributing' section of their stdlib: "deno_std is a loose port of Go's standard library. When in doubt, simply port Go's source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We gene…

For Deno this seems like a very good choice. Pick the good parts from Go and reuse them. I applaud Deno for going its own way with the module system though... That's been a hot topic in Go for a very long time
Post reply on HN