Live data from Hacker News

Why I’m staying with Node

medium.com

21–30 of 46 posts

Re: Why I’m staying with Node

#21
post #9
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…

I haven't seen this type of hiring since the .com bubble days. Nowadays either one has the right keywords on the CV or good luck.

Yeah, but that might have something to do with perceived shortage of developers.

Re: Why I’m staying with Node

#22
> We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere.

The "alas" in this quote is sad. Sad to be using tools you hate.

Re: Why I’m staying with Node

#23
post #18
post #16

Earlier quoted context omitted.

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.

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 (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C.

I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.

Re: Why I’m staying with Node

#24
Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features.

Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitioned into services, it's easy to write a single service in Go, and go is a nice language for writing services.

That being said, Node is particularly well suited for consuming services. You'll necessarily have lots of client code written to consume and use these services from your webapp. So whenever you write a batch job or notification system or anything else that is primarily server side consumption of services or glue between services, node.js is a natural fit.

The other natural advantage of Node is that your business logic can run on both the server and the client. Your standard client-side web app (angular, backbone, ember etc.) has the bulk of the business logic in the client-side models. On the server side, the corresponding models are mostly just shims to the database, but they will also contain some business logic. If your code is written in Node.js, you just instantiate the client side model to be access the business logic.

The other killer feature for node.js has already been mentioned: combining both server and client side rendering with https://github.com/rendrjs/rendr or https://github.com/wvl/highbrow.

Re: Why I’m staying with Node

#25
post #22

> We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere. The "alas" in this quote is sad. Sad to be using tools you hate.

I feel the same way about JavaScript, to some extent at least. I don't hate JavaScript - but I think that the web would be better if it moved towards making another language standard as well. I don't know which language would be best, Dart looks like a good candidate when it is more mature.

Re: Why I’m staying with Node

#26

Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features. Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitio…

slightly off-topic but I am pretty interested in learning about SOA architecture using Node.js apps. Can you refer any guides/links ?

Re: Why I’m staying with Node

#27
post #16

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

> There are fine nuances about a programming language that you need to learn to be a good programmer.

On the other hand language is an investment. Switching a language in the same paradigm is more like maybe learning a local dialect of dialect of English, new words, new pronunciation. Say you are moving to Australia from US, you might have that issue. But if you think it worthwhile it is an investment.

But that is for when the paradigm is the same. Object oriented, functional, dynamic types vs static types, logic programming, declarative (SQL) those are like different languages French, Spanish, etc.

Re: Why I’m staying with Node

#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 more predictable and easier to understand. Like DRY but with design decisions instead of lines of code.

Also, I don't see how you can be flexible without making API the only point of contact for your back(s). That way you don't lock yourself in and can rewrite any component with another framework or language, once requirements change sufficiently. I imagine it's much harder to do if you have everything in one Node project.

Re: Why I’m staying with Node

#29
post #26

Node is not going anywhere. It may not be cool anymore, but like the old cool kids (Rails, Java, Perl), it has achieved critical mass, and still has some killer features. Node makes SOA (service oriented architecture) a lot easier. SOA is what all the cool kids are moving to, and is one of the reasons why it's so easy for big companies with lots of legacy code to switch to Go. Once your code is appropriately partitio…

slightly off-topic but I am pretty interested in learning about SOA architecture using Node.js apps. Can you refer any guides/links ?

Hmmm, I couldn't find any simple examples. Basically, all it means that you're running Backbone.js on the server as well. If you're just using Backbone.js models & collections it's pretty straightforward.

But if you Google for running Backbone.js on the server, you get links for people running Backbone.js views (as well as models and collections) on the server. That's a little more involved, but the work has been done for you by frameworks such as rendr.

A good starting place might be: https://github.com/rendrjs/rendr-examples

I'm only familiar with Backbone. If your models are written in Ember or Angular or (?) instead of Backbone, I can't help you but would be very interesting in knowing how myself...

Re: Why I’m staying with Node

#30
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.

Yeah, pretty much

You can have them try prototyping stuff on Go on the second week, trying some libraries, examining some existing Go code and that's it

There are good "XX" programmers, but I'd say that they're mostly good programmers and not tied to a specific language. Yeah, there are some niches where someone who's great at that niche may not be so good at other places (front-end, or maybe performance critical programming, or even things like COBOL or Java)

Post reply on HN