Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m staying with Node

medium.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Why I’m staying with Node

#11

Post by drsintoma »

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…

> they're expected to spend the first 6 months learning Go on the job.

Of course like in everything you have different levels of expertise. But I can tell you first hand that most developers can be productive in Go within 2 weeks if not less.

Re: Why I’m staying with Node

#12

Post by human_error »

> Hiring for Go — I wouldn’t even know where to start

Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn programming from scratch. So, when you want to hire someone to code in Go, you just hire a developer and tell them they're going to code in Go. After getting used with Go, they would be all set.

Re: Why I’m staying with Node

#13

Post by _random_ »

"With Node you can literally share your code between the front and back of a system."

Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?

Re: Why I’m staying with Node

#15

Post by chdir »

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.…

Agreed, on the other hand it is OK to disagree with the shortcoming in node (from previous post) & point them out. It's important for the community to not lose faith because one star dropped out.

Re: Why I’m staying with Node

#16

Post by chdir »

human_error wrote: post #12

> Hiring for Go — I wouldn’t even know where to start Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn p…

In principle, I agree that picking up programming languages for a good programmer shouldn't be a challenge but this analogy doesn't go too far. There are fine nuances about a programming language that you need to learn to be a good programmer. Whereas a car is mostly a commute tool for many. You can switch a browser like a car, but switching a language is a bit more involved.

Re: Why I’m staying with Node

#17

Post by eyko »

talloaktrees wrote: post #10
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…

How to train a new employee on Go: Day 1: complete the tour - http://tour.golang.org/ and read "How to Write Go Code" http://golang.org/doc/code.html Day 2-3: read Effective Go - http://golang.org/doc/effective_go.html Take a whole week, if you feel it is necessary.

This was exactly how I did it. The Effective Go part took me longer, since I actually jumped into porting a couple of small ruby libraries I picked (not mine, just ones I was familiar with) so that had me jumping to and from the book to the terminal/editor, so it probably took me like 5 days to port both libraries into Go code that I was happy with.

After that I had also read enough online to be familiar with the tools and the environment. Go is a really small language, but the ecosystem is rich.

Re: Why I’m staying with Node

#18

Post by nawitus »

chdir wrote: post #16
human_error wrote: post #12

> Hiring for Go — I wouldn’t even know where to start Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn p…

In principle, I agree that picking up programming languages for a good programmer shouldn't be a challenge but this analogy doesn't go too far. There are fine nuances about a programming language that you need to learn to be a good programmer. Whereas a car is mostly a commute tool for many. You can switch a browser like a car, but switching a language is a bit more involved.

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.

Re: Why I’m staying with Node

#19

Post by bryanlarsen »

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.

Shared code can be a huge win in certain scenarios.

1. the server can run the client code to render and serve HTML, so you get all the benefits of server side rendering as well as client side rendering. [1][2]

2. imagine you have an architecture that allows multiple clients to simultaneously modify a single document, like google docs, or like all your standard cookie-cutter enterprise form & report interface to records in a database database. Now imagine that you need to do some sort of batch operation to these documents. If your code is written in Node, you just run your client code on the server. Instead of directly manipulating the database from your batch workers, you use the standard REST & WebSocket API that your clients do. This is called a service-oriented code structure, and there are huge advantages to this; so big that everybody is switching to it. Node makes it almost free.

1: https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow

Re: Why I’m staying with Node

#20

Post by crdoconnor »

_random_ wrote: post #13

"With Node you can literally share your code between the front and back of a system." Having to deal with a poorly-designed legacy weakly-typed scripting language not just on client (where you have no choice) but on server as well? Why be masochistic?

It makes sense if your app flat out requires a lot of javascript on the client side.

I find that javascript is most often an overused crutch on the client side, though. It's used more for premature optimization and making your website look shinier than it is anything really very useful.

Nonetheless, some webapps really do require a lot of it.

Post reply on HN