I'm primarily a mobile dev, so the biggest impediment to me adopting Go over Node is the fact that converting and manipulating my data models to send as JSON documents is considerably harder on Go - there's no Go equivalent to Gson yet, nor will there likely ever be due to the nature of the language.
From Node.js to Go
91–100 of 192 posts
Re: From Node.js to Go
#92Earlier quoted context omitted.
That's a very naive argument. There are so many other variables in choosing a cross platform language which you've overlooked: ]] Performance (AOT compiled languages will typically out perform JIT compiled language ]] user interface (is this going to be a command line app? Does it need a GUI? And if so, what frameworks are supported and do they need any OS specific boiler plate code?) ]] required runtime environment…
>Performance I didn't argue anything about performance. Go might have better performance than Node.js, but that doesn't make Go better for cross-platform distribution! They are separate factors. If performance is your top priority and Go has better performance than Node.js then choose Go while acknowledging that it's possible that Node.js has better cross-platform code distribution support. >user interface I didn't m…
"This is my core argument that Node.js does cross-platform development better."
Your argument is theoretical. In practice, people are finding Go apps easier to deploy. Reality trumps theory.
Why is reality trumping theory? With Go you one artifact, the executable, which runs on its own and you're done. With Node, you don't and you're not done, and even with the incredibly minimal bit of Node stuff I've touched (keybase.io, one of the minifiers), I still had to fight with Node to get it to run. Sorry, this one is easy to objectively call: Go produces artifacts that are easier to deploy. It doesn't matter how you try to talk around that fact, it simply is not the case that you ship one file with Node and are done; that is at best the best case when all the stars align and the wind is at your back.
Re: From Node.js to Go
#93I wish a language with advanced types like Haskell or OCaml would have the same tooling and ease of distribution around it that Go does. I haven't built anything in Haskell/ML in a while, so if anyone has any updates on this please chime in.
Yea, I really like GADT too much to give it up. With Swift/Haxe/Rust/Haskell/F# all having them. You may find this interesting, someone implemented a parsec-like library in Go [1]. I haven't wrapped my head around it completely, but it looks like it's all dynamic [2]. [1] https://godoc.org/github.com/prataprc/goparsec [2] https://github.com/prataprc/goparsec/blob/master/json/json.g...
Are you sure GADTs are possible in Swift and F#? I haven't seen what syntax supports that in those languages. Do you just mean Discriminated Unions (i.e. ADTs). There is a difference between GADT and ADT.
Re: From Node.js to Go
#94Earlier quoted context omitted.
> I never, ever want to write any OS-specific code With Go, you never, ever have to write any OS-specific code. From a single source , you can build executables compiled for different operating systems. In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation. > You need to compile to code for every single platform, making…
>With Go, you never, ever have to write any OS-specific code. Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system." >Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the…
Obviously you need to write OS specific code, even with node, if you are doing platform specific tasks. Normally you don't need to care.
Re: From Node.js to Go
#95Go does lack quite a bit of the web pizzazz you'd find in rails, but I learned a lot more by writing web things in go than I did in rails because so much less of the magic is hidden away from you.
Go is a language and Rails is a framework though it's not even an apt comparison. Ruby and Go is a better comparison though still not the best.
Re: From Node.js to Go
#96It is frustrating to see how many Go vs Node posts are happening here. I have been implementing a bluetooth LE module in Go, and due to lack of some robust libraries, had to go back to Node. This is primarily a question of maturity, but I also realised that my use-case didn't really need the thing which Go is most useful for - namely really really good concurrency primitives.
I am quite sceptical about Node's future because of that forking fiasco, but at this point in time, both Node and Go provide enough distinct functionality that both will be used for a long time.
Re: From Node.js to Go
#97Earlier quoted context omitted.
Minor nit pick, but theses days "interpreted" languages are also compiled. What we are really taking about is AOT vs JIT (though even here, there are AOT compiled languages that still require a supporting run time environment installed, such as Java)
Java's a bit of a special/odd case, since it's AOT-compiled into a bytecode that is then JIT-compiled into native instructions.
Not that unusual these days. CPython supports a similar intermediate binary (.pyo) and .NET does the same too, albeit the bytecode is shipped inside a PE.
Re: From Node.js to Go
#98Earlier quoted context omitted.
Most languages have an equivalent of go fmt. They are just third party tools that aren't integrated into the language. Which for me is perfectly acceptable. There are sometimes legitimate reasons for formatting code different to what the language creators believe.
I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks. I'm now inclined to believe that a basically free way to avo…
Again. Third party tools will have exactly the same benefits.
People have been using standard code formatters in Eclipse/IntellIj for what decades now ?
Re: From Node.js to Go
#99Earlier quoted context omitted.
NPM is only awesome until you need to do something with it on Windows.
What kind of problems are you having with it? I'm using npm on Windows and it's working out great! I'm actually using it as my build/task runner rather than using bloated grunt or gulp. It's easy to configure and read. I run my linter, unit test, jscs, and bundler all configured in package.json. I also install git bash and conemu to have bash on Windows which makes things much better. I don't use windows console.
I had a global environment variable conflict because something else was named "node.exe"... =/
Re: From Node.js to Go
#100Earlier quoted context omitted.
I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks. I'm now inclined to believe that a basically free way to avo…
Again. Third party tools will have exactly the same benefits. People have been using standard code formatters in Eclipse/IntellIj for what decades now ?
> a single standard format