Why I’m staying with Node • Hacker News Board

Re: Why I’m staying with Node

#41

Post by nawitus » Sat, Jul 05, 2014, 4:21 PM UTC

crdoconnor wrote: post #23

nawitus wrote: post #18

Earlier quoted context omitted.

I agree with your point, but Go in particular doesn't seem very different from, say, C/C++. I think the average programmer who knows C/C++ can pick it up rather quickly, even though going from Java to JavaScript takes significantly longer.

Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things. You also need to develop a full understanding of the package/library/framework ecosystem, which can take years . This isn't transferable knowledge, either, but it's absolutely vital to understanding a language. Knowing that requests is a great python library, for instance, and knowing when (an…

It seems that the 'Effective Go' article was written to avoid the pitfalls. I agree with your point, but I don't think it's a very strong one.

http://golang.org/doc/effective_go.html

Re: Why I’m staying with Node

#42

Post by dang » Sat, Jul 05, 2014, 6:43 PM UTC

Artemis2 wrote: post #3

Is there really any practical examples of sharing code between back-end and front-end? I only see really specific use-cases, such as sharing the logic of a game between the client and the server, since most of the time the back-end serves the content and the front-end displays it.

> Is there really any practical example of sharing code between back-end and front-end?

Operational transform algorithms for collaborative editing are a good fit for this. They are complex and have to run in both places.

Re: Why I’m staying with Node

#43

Post by MetaCosm » Sat, Jul 05, 2014, 9:18 PM UTC

Mithaldu wrote: post #5

> Hiring for Go — I wouldn’t even know where to start. Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job. You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to l…

Change 6 months to 6 days -- and agreed. Go has a 50 page SPEC -- the language fits in your head.

Re: Why I’m staying with Node

#44

Post by [deleted] » Sat, Jul 05, 2014, 9:18 PM UTC

Mithaldu wrote: post #5

> Hiring for Go — I wouldn’t even know where to start. Ridiculously simple: Set out to hire a good programmer (as opposed to "a Go programmer"), and make it clear in the job description that they're expected to spend the first 6 months learning Go on the job. You end up demonstrating to employees that you're willing to give them something useful, gain loyalty; AND end up with someone you can be confident is able to l…

[deleted]

Re: Why I’m staying with Node

#45

Post by ericclemmons » Sat, Jul 05, 2014, 11:14 PM UTC

eknkc wrote: post #4

So? I don't think TJ wrote his post just for the sake of complaining or comparing Node with Go. He had a decision, and had to tell the community he was leaving because, you know, a lot of people uses his modules. I rely on a couple of his modules and I liked that he took some time to explain why he'll not be working on them anymore. This post is no more interesting than blogging "I'll keep drinking my morning coffee.…

Posts like this are warranted because some took TJ's move to Go as "jumping ship" on Node, especially when he expressed concern over Node's future.

The author correctly frames it as a personal decision in which tool to use for which job.

Re: Why I’m staying with Node

#46

Post by goblin89 » Mon, Jul 07, 2014, 5:34 AM UTC

couchand wrote: post #37

goblin89 wrote: post #28

> With Node you can literally share your code between the front and back of a system. I think sharing code is dangerous as it tightens component coupling and makes architecture less flexible and more complex. An average web project nowadays seems to be a back with many fronts: end-user website, admin interface, iOS app, Android app, Windows app… Making all fronts equal in their separation IMO keeps the architecture m…

I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project. First, why. To your point about DRY but with design decisions instead of lines of code , that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you…

> Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again.

If only that were true, but that's where my doubts are. You write:

> If you're sharing code, you just write a function to check the rules and call it in both places.

But you can only use that function if you can use Node on your front end. Most fronts today (native iOS apps, etc.) won't be able to reuse that function, and you'll have to reimplement it anyway.

I would only go with Node if I absolutely knew that incompatible front end won't be required for the project in foreseeable future—but I'd need to be a CTO to decide on that. Besides, what about when browsers get an additional runtime, with better tools than JavaScript? (Okay though, this one may not count as ‘foreseeable future’.)

I'd rather reimplement the function every time if I know I may need to reimplement it an unknown number of times. Perhaps in that case I'd try coming up with some language-agnostic specs instead so that validation function can be reimplemented on other platforms without breaking UX consistency.