5 ms·

Having next to no Go experience, and zero Rust experience, I found this article a really fun read. Coming from a Node.js background, it was neat to see the conc

Having next to no Go experience, and zero Rust experience, I found this article a really fun read. Coming from a Node.js background, it was neat to see the concurrency approaches used in both languages compared -- quite different from a single-event-loop :)

fizzbatter 11y ago
I'm sure it just comes down to personal preference, but as a node developer myself (perhaps former), i found it so freeing to switch to Go. Mainly for two reasons (which i assume are less common reasons): 1. Synchronous by default 2. Interfaces Point 1 to me feels silly to admit. But man, i still do a fair bit of JavaScript/Node for work (our frontend, mainly) and it is just so.. tiresome to me, to constantly feel on the edge of bugs because some functions are expected to be synchronous (return values) and others are intended to callback. I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me. Point 2 is simply because i really like interfaces. Back from my Python days, a few libraries had invented ways to support interfaces and i really really liked them, but not the overhead they required. Being able to expect the behavior of an object with certainty is the main part of duck-typing to me, and seeing that from a more static language (when compared to python/js) is really enjoyable. I know you didn't ask for a writeup, i just had to agree with you and felt the need to share my experience from a similar standpoint. :)
- agmcleod 11y ago
  > I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me. Pretty much why i never got into node development.
- BenjaminCoe 11y ago
  I love the Node/npm community, and have been programming JavaScript for so many years it's hard habit to kick :) I'd love to try my hand at Go though... I think it's awesome to see what practices can be shared between communities. One approach I've been playing with in JavaScript-land is using Promises for all return values, this means that you consistently know how to interact with a return value, whether its concrete-value is available immediately or at a later time -- this doesn't really solve the problem of consuming other people's libraries however!
- kuschku 11y ago
  But that’s the issue, duck typing really leads to many situations with uncertain situations. It’s like the + operator in JS: depending on context, you can have appending, addition, or vector addition.
  - fizzbatter 11y ago
    Are you referring to duck typing in general? Or specifically Go's interfaces (which i referred to as duck typing)? They seem rather harmless to me, so i'm curious on your perspective. I see them as no more dangerous than an explicit type (or any function, for that matter). You're asking for a specific behavior, and you know that what you get will have that specific behavior. A Reader or Writer is a simple example of that. Sure, you don't know what it's writing to, but that's outside your scope and likely the scope of the function - right? Perhaps i misunderstand you, i'd love further explanation/examples _(pertaining to Go's interfaces)_ :)
    - kuschku 11y ago
      Imagine I get an object, I don’t know it’s type – I can’t even check if it implements the VectorAddition, Addition, or Appendable trait, I only see it has a .+ method. How am I supposed to switch between types being able to do either of these, without listing all types that might occur – as this might not be possible (I’m thinking about Haskell’s type classes as a solution to this, btw)
      - vectorjohn 11y ago
        Plus is a bad example because you can't do that in Go, but I understand the question. Basically, you don't do that in Go. Go has interfaces, but they're implemented implicitly. So rather than "I get an object", you say, "I get an object that implements interface X", and you use whatever methods X has. That just means its up to you to name interfaces in a reasonable way. Which is one down side - if you have an "Add" method, it's back to your question about what it means to add, depending on the implementation. Nothing does this as well as Haskell as far as I can tell.
      - 11y ago

fizzbatter 11y ago

I'm sure it just comes down to personal preference, but as a node developer myself (perhaps former), i found it so freeing to switch to Go. Mainly for two reasons (which i assume are less common reasons): 1. Synchronous by default 2. Interfaces Point 1 to me feels silly to admit. But man, i still do a fair bit of JavaScript/Node for work (our frontend, mainly) and it is just so.. tiresome to me, to constantly feel on the edge of bugs because some functions are expected to be synchronous (return values) and others are intended to callback. I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me. Point 2 is simply because i really like interfaces. Back from my Python days, a few libraries had invented ways to support interfaces and i really really liked them, but not the overhead they required. Being able to expect the behavior of an object with certainty is the main part of duck-typing to me, and seeing that from a more static language (when compared to python/js) is really enjoyable. I know you didn't ask for a writeup, i just had to agree with you and felt the need to share my experience from a similar standpoint. :)

agmcleod 11y ago
> I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me. Pretty much why i never got into node development.
BenjaminCoe 11y ago
I love the Node/npm community, and have been programming JavaScript for so many years it's hard habit to kick :) I'd love to try my hand at Go though... I think it's awesome to see what practices can be shared between communities. One approach I've been playing with in JavaScript-land is using Promises for all return values, this means that you consistently know how to interact with a return value, whether its concrete-value is available immediately or at a later time -- this doesn't really solve the problem of consuming other people's libraries however!
kuschku 11y ago
But that’s the issue, duck typing really leads to many situations with uncertain situations. It’s like the + operator in JS: depending on context, you can have appending, addition, or vector addition.
- fizzbatter 11y ago
  Are you referring to duck typing in general? Or specifically Go's interfaces (which i referred to as duck typing)? They seem rather harmless to me, so i'm curious on your perspective. I see them as no more dangerous than an explicit type (or any function, for that matter). You're asking for a specific behavior, and you know that what you get will have that specific behavior. A Reader or Writer is a simple example of that. Sure, you don't know what it's writing to, but that's outside your scope and likely the scope of the function - right? Perhaps i misunderstand you, i'd love further explanation/examples _(pertaining to Go's interfaces)_ :)
  - kuschku 11y ago
    Imagine I get an object, I don’t know it’s type – I can’t even check if it implements the VectorAddition, Addition, or Appendable trait, I only see it has a .+ method. How am I supposed to switch between types being able to do either of these, without listing all types that might occur – as this might not be possible (I’m thinking about Haskell’s type classes as a solution to this, btw)
    - vectorjohn 11y ago
      Plus is a bad example because you can't do that in Go, but I understand the question. Basically, you don't do that in Go. Go has interfaces, but they're implemented implicitly. So rather than "I get an object", you say, "I get an object that implements interface X", and you use whatever methods X has. That just means its up to you to name interfaces in a reasonable way. Which is one down side - if you have an "Add" method, it's back to your question about what it means to add, depending on the implementation. Nothing does this as well as Haskell as far as I can tell.
    - 11y ago