7 ms·

Interesting that he's unsure about Go. Would be nice to hear about why. One huge strength about Node (&Deno) is having the same language and tools on the front

• faitswulff 8y ago
  The repo itself says it's "Segfaulty," which is far less likely in safe Rust, for example. Perhaps that's why he mentioned it as a candidate. Regardless, it sounds like he was doing a lot of work in Go, so perhaps it was just the too that was closest to hand for him when he decided to build the prototype.
• curun1r 8y ago
  It might have to do with the overhead of calling into C/C++. Since a project like deno will have to do a lot of interfacing with V8, a language like Rust wouldn't have the overhead of cgo when dealing with the embedded VM. Also, while go routines are one of the strengths of go, they don't necessarily play well with concurrency constructs in other languages. Since a project like deno will probably be keeping Node's single-threaded, evented model of concurrency and using libuv (also a C interface), that basically means avoiding go routines. To your point, though, you'd still use basically the same language on the server and client, since deno runs typescript and typescript can compile to run in a browser. The Go side would take the place of Node's native modules, which currently have a C++ interface.
• zemo 8y ago
  the point of Go is to have one language that's the best of both dynamic and static languages. the point of Rust is to be safe and fast. if you're building an infrastructure where you're externalizing the dynamic language runtime, such that there's always a host and a guest language, Go isn't necessarily optimized to act as a host language in that context. Rust is, at the expense of being arguably more tedious to program.
  • pknopf 8y ago
    He isn't (wouldn't be) using Rust for a dynamic runtime. It would be strictly for bootstrapping V8 and a ffi. With the ffi, you interop with whatever net stack you want.
• TheOtherHobbes 8y ago
  I've never understood why this is a benefit when the one language is - let's say - suboptimal in many ways. The interfaces between server- and client-side code should be well-defined and language-independent. You don't want the same people writing both, because it's harder to check that your API is working to spec if it doesn't get fully independent testing. There's also a lot of useful server-side optimisation and security management that Node - or a high-level replacement - can't handle. V8 may improve things, but it's going to have to improve performance a lot to be competitive. https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go https://www.toptal.com/back-end/server-side-io-performance-n...
  • rb808 8y ago
    > The interfaces between server- and client-side code should be well-defined and language-independent. They dont have to be and that is the point. If you write JS/TS front and back you can make everything much simpler with the associated benefits.
    • LargeWu 8y ago
      But in what specific way way does it make it simpler? What are the tangible benefits? I've been working in a Node/React environment for the last 2 years and there is virtually no overlap between the code we use on front- vs backend projects.
      • SaltyBackendGuy 8y ago
        So much this. Although in theory I can see why this would be appealing, however in practice, our Node backend and Ember frontend have very little code they can share. Maybe there's an argument for devs being able to jump back and forth. But again, in practice, the paradigms are very different so I am not sure there's a huge benefit.
      • overcast 8y ago
        Because not everyone is using React type frameworks on the frontend? There is old fashioned javascript still, and because I know it on the front end, I know it on the backend.
• garyclarke27 8y ago
  At the end of his talk, he mentions possibly using Rust or C++ instead of Go, I would gues for maximum possible performance.