5 ms·

Go and Javascript/Node.js are quite different languages in their feature lists and main implementations. To mention a big one, Go is mostly statically and stro

by vesak 10y ago

Go and Javascript/Node.js are quite different languages in their feature lists and main implementations. To mention a big one, Go is mostly statically and strongly typed, in stark contrast to Javascript. Also it has significantly fewer misdesigns (such as the equality operator being weird). Are you claiming that such features don't matter for the effectivity of the platform?

watson 10y ago
The syntax of your language doesn't change its performance when running. I can appreciate that not everyone likes JavaScript - it's all a matter of personal preference I guess - but saying that Go is a better language because of the syntax is like saying bananas taste better because of their color. They are two very different languages with each their strengths and weaknesses. Does JavaScript have a few design flaws? Absolutely! More so than many other languages? Quite possibly! Does it make me write worse software if I'm aware of those quirks? Most certainly not.
- vesak 10y ago
  > The syntax of your language doesn't change its performance when running. No need to bring up syntax. It's a superficial feature and has nothing to do with the actually important features I listed. > Does it make me write worse software if I'm aware of those quirks? Most certainly not. Is there some limit where good language features stop mattering? I guess we would obviously agree that creating web software with x86 assembler wouldn't be a good idea -- even if we could imagine a comparable library/framework situation.
- aikah 10y ago
  > The syntax of your language doesn't change its performance when running. No but the difference between static typing and dynamic typing actually does. Go compiler performs a lot of optimizations that no Javascript engine can.
gotofritz 10y ago
Those you mention no. There are tools for typechecking (flow) and to be honest in years of JS programming only rarely have I had bugs caused by a variable of the wrong type being passed into a function. As for the "weird" equality operator, again, not an issue, any linter will force you to use === and then you are good to go. If you are talking about the callback queue getting too full and causing delays you may have a point, but the objections that you have raised are quite petty.
- vesak 10y ago
  >Those you mention no. There are tools for typechecking (flow) and to be honest in years of JS programming only rarely have I had bugs caused by a variable of the wrong type being passed into a function. Are you certain that that is true, or do you think it might just be that you're so used to the dynamic woes that you nearly ignore them?
  - gotofritz 10y ago
    I don't experience any "dynamic woes". I am used to checking for whatever input is coming into my functions.
    - Someone 10y ago
      Writing code that type-checks whatever input is coming into your functions may only take time, but what really are woes that you will have fewer of the stronger the type system, is that you have to design the code that runs when those checks fail. That designing requires thinking, and thinking takes your attention away from whatever your goals are, whether you are used to it or not. Strong type systems come with their own things that require extra thinking, but I think it is less than what is required to write robust dynamically typed code. Many projects don't need truly robust code. Then, the dynamic language may still win.
      - gotofritz 10y ago
        > Strong type systems come with their own things that require extra thinking, but I think it is less than ... Well, that's your bias. As I said in practice I don't see a problem. And also, as I said, there are static analysers, and you really HAVE to have strong type you can always use typescript.

by vesak 10y ago

watson 10y ago

The syntax of your language doesn't change its performance when running. I can appreciate that not everyone likes JavaScript - it's all a matter of personal preference I guess - but saying that Go is a better language because of the syntax is like saying bananas taste better because of their color. They are two very different languages with each their strengths and weaknesses. Does JavaScript have a few design flaws? Absolutely! More so than many other languages? Quite possibly! Does it make me write worse software if I'm aware of those quirks? Most certainly not.

vesak 10y ago
> The syntax of your language doesn't change its performance when running. No need to bring up syntax. It's a superficial feature and has nothing to do with the actually important features I listed. > Does it make me write worse software if I'm aware of those quirks? Most certainly not. Is there some limit where good language features stop mattering? I guess we would obviously agree that creating web software with x86 assembler wouldn't be a good idea -- even if we could imagine a comparable library/framework situation.
aikah 10y ago
> The syntax of your language doesn't change its performance when running. No but the difference between static typing and dynamic typing actually does. Go compiler performs a lot of optimizations that no Javascript engine can.

gotofritz 10y ago

Those you mention no. There are tools for typechecking (flow) and to be honest in years of JS programming only rarely have I had bugs caused by a variable of the wrong type being passed into a function. As for the "weird" equality operator, again, not an issue, any linter will force you to use === and then you are good to go. If you are talking about the callback queue getting too full and causing delays you may have a point, but the objections that you have raised are quite petty.

vesak 10y ago
>Those you mention no. There are tools for typechecking (flow) and to be honest in years of JS programming only rarely have I had bugs caused by a variable of the wrong type being passed into a function. Are you certain that that is true, or do you think it might just be that you're so used to the dynamic woes that you nearly ignore them?
- gotofritz 10y ago
  I don't experience any "dynamic woes". I am used to checking for whatever input is coming into my functions.
  - Someone 10y ago
    Writing code that type-checks whatever input is coming into your functions may only take time, but what really are woes that you will have fewer of the stronger the type system, is that you have to design the code that runs when those checks fail. That designing requires thinking, and thinking takes your attention away from whatever your goals are, whether you are used to it or not. Strong type systems come with their own things that require extra thinking, but I think it is less than what is required to write robust dynamically typed code. Many projects don't need truly robust code. Then, the dynamic language may still win.
    - gotofritz 10y ago
      > Strong type systems come with their own things that require extra thinking, but I think it is less than ... Well, that's your bias. As I said in practice I don't see a problem. And also, as I said, there are static analysers, and you really HAVE to have strong type you can always use typescript.