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

We switched to Node.js: the good and the not so good

blog.superfeedr.com

Post reply on HN
Print view View original

101–106 of 106 posts

Re: We switched to Node.js: the good and the not so good

#101

Post by nkohari »

codygman wrote: post #90
nkohari wrote: post #60

Earlier quoted context omitted.

Technology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future. Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.

I don't think he undermined the second, but would like to know your opinion. Here is mine: "- Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard." Go code is almost always very simple and readable. What makes you think him choosing Go undermines the simplicity and readability arguments?

Simplicity and readability are subjective criteria. In my opinion, Go has many merits, but readability is not one of them.

Re: We switched to Node.js: the good and the not so good

#102

Post by gbog »

nkohari wrote: post #100
gbog wrote: post #95

Earlier quoted context omitted.

> Technology and business requirements move too fast to worry about writing software that will be around 10 years from now This is a common belief but I do not think it applies very well in most cases. If you write the last pic sharing thing, maybe you can dismiss worries, but if you build the next Google, entreprise or scientific software, or even something like Github, you should hope your baby to be well and alive…

Google in 2002 was nothing like Google in 2012. The only thing the same is the name. The entire software industry has changed at least twice in the last decade or so. If more than 10% of the original code that powered Google is still in production, I would be absolutely shocked. Remember how Twitter was originally written in Rails, and then it collapsed under its own weight when they tried to scale it? Their business…

> Software services are evolutionary

Sure, but changing the tech stack is much harder than rewriting some parts of it. And some setups are easier to adapt than others. Thus choosing the best available option when starting a new project is important, and the likeliness of the technology to be alive and well in ten years should be taken into consideration, among other parameters (your own experience, the current availability of good developers).

Moreover, the "trendiness" of a technology should be counted as a negative factor, because it would tend to be overestimated and cast shadows on potentially better (but less sexy) alternatives.

Re: We switched to Node.js: the good and the not so good

#103

Post by jahewson »

diroussel wrote: post #50
jahewson wrote: post #47

Earlier quoted context omitted.

If the initial version was IO-bound wouldn't they get a 0% gain from re-writing?

If my program reads a file one byte at a time, and it's IO-bound, can I improve performance by re-writing?

Then it's not really IO-bound is it? It's stupidity-bound. Once you re-write it properly then it'll be IO-bound.

Re: We switched to Node.js: the good and the not so good

#104

Post by codygman »

rdtsc wrote: post #99
codygman wrote: post #91

Earlier quoted context omitted.

The problem is the threading solutions for python fill bolted on, and kind of break the whole "pythonic" feel of everything. Of course this is purely subjective, but for me it feels like I'm "going against the grain" and falling out of the domain space of problems the language was meant for. That, and Go seems to be close enough to python with those advantages built in that it becomes an easy choice for me. Combine t…

> The problem is the threading solutions for python fill bolted on, and kind of break the whole "pythonic" feel of everything. See I find a lot Twisted, and yield based concurrency frameworks not being Pythonic enough. Threads are just functions that run concurrently. In the case of green threads it is really just as simple as spawn(func) to start a new green thread running function func(). Take a look at these event…

This is a fair solution, and I believe that gevent was the best solution IMO for python although I only gave it a cursory glance.

However, type checking is what ultimatley won out here along with Go's very C+Python love child feeling.

Re: We switched to Node.js: the good and the not so good

#105

Post by codygman »

nkohari wrote: post #101
codygman wrote: post #90

Earlier quoted context omitted.

I don't think he undermined the second, but would like to know your opinion. Here is mine: "- Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard." Go code is almost always very simple and readable. What makes you think him choosing Go undermines the simplicity and readability arguments?

Simplicity and readability are subjective criteria. In my opinion, Go has many merits, but readability is not one of them.

Just out of curiousity, what are your top 5 most readable programming languages that you've used?

Re: We switched to Node.js: the good and the not so good

#106

Post by nkohari »

codygman wrote: post #105
nkohari wrote: post #101

Earlier quoted context omitted.

Simplicity and readability are subjective criteria. In my opinion, Go has many merits, but readability is not one of them.

Just out of curiousity, what are your top 5 most readable programming languages that you've used?

Of the languages that I possess more than just a passing understanding, I'd have to say: CoffeeScript, Ruby, Python, JavaScript, and C#.
Post reply on HN