Hacker News Reader

Comment by egeozcan | Hacker News Reader

> Future of Popular Coding Tool in Doubt After It Splits in Two

Are there convincing number of examples of very popular projects being forked and both ends being discontinued, or is this just a typical example of spreading FUD?

Forking is a natural process in the open-source world.

View on HN

> is this just a typical example of spreading FUD?

Whatever the outcome, this is absolutely eyeball-grabbing FUD. A popular open source project, by definition, has identified "job(s) to be done" and has attracted an audience of supporters (users and developers). That's what keeps any project afloat. In long-term, a big project fork is a sign of a healthy community. That community occasionally has to come to grips with the evolution of their software. For a fork, this is usually a combination of social and technical dynamics. In the short-term, it's hard to see past the difficult (and occasionally acrimonious) social mechanics.

I can think of MySQL. While I wouldn't call it dead by any measure it certainly suffered when the spit happened.

Since i'm a newbie and I couldn't find anything with a simple search, could you elaborate on that particular MySQL situation?

Original creators left and created MariaDB. MariaDB is now used in place of MySQL in most Linux distros by default. They left after Oracle got control over it by buying Sun (who had previously bought MySQL.)

For me it was the closed-source new test cases. That marked a turning point for the direction of MySQL (IMO).

The short version is that MySQL was acquired by Oracle (when Oracle purchased Sun Microsystems). Following concerns about it remaining open source, MySQL was forked by it original creator, and is developed as MariaDB[0].

[0] https://en.wikipedia.org/wiki/MariaDB

Personally, I always though that the community over-reacted big time. After all, the core DB engine most people were using for MySQL for years (InnoDB) had been owned by Oracle for years before that.

MariaDB has done some decent stuff, tho.

Yeah, but how much of that was due to forking and how much of that was folks realising that PostgreSQL is much better than MySQL for most metrics of better?

The other thing to consider is that for me to think that forking makes the future of the project questionable, you'd have to show that it's likely that usage(original project) < usage(upstream) + usage(fork). In other words, I'd be interested to know the combined usage of MariaDB and MySQL and see if you could actually predict with confidence that it would significantly lower than original MySQL usage. Not just that one of the forks didn't have as many people.

Yes, but Postgres had lots of technical advantages of MySQL for years, and still was less popular. For most uses people would decide "MySQL is good enough feature-wise for me. It's so popular it's probably safest ecosystem-wise"

It was the MariaDB fork that shook people up. Now suddenly the decision became "should I bet on one of these forks, or should I skip that drama and use Postgres which seems like a nice stable project" The fork is really what changed the game.

I think most of that was because of Oracle buying Sun. The MariaDB for and Postgres's rising popularity are the outcomes of that.

By any measure? This web-site indicates no significant decline in MySQL usage:

http://db-engines.com/en/ranking_trend

forking didn't hurt MySQL. Going proprietary hurt MySQL.

A better headline would be:

Future of Popular Coding Tool Unclear After It Splits in Two

But it's true that Node is losing traction.

Node is losing traction where? I see it as being very strong, but it isn't the shiny new thing any more -- which means that it is beyond the first few stages of the hype cycle.

It has very strong growth in Google trends:

http://www.google.com/trends/explore#q=node.js

I think Google trends is a very laggy indicator of something like this.

No, but this is:

http://www.indeed.com/jobanalytics/jobtrends?q=ruby+on+rails...

I see this more as a return to reality from Node.js's astronomical levels of hype.

The use cases for a single-threaded web server are specific and limited in the real world. Node.js will continue to solve those use cases (simple web server for static content or I/O bound apps) but the resultant decline will lead some to believe that the framework is dying.

> The use cases for a single-threaded web server are specific and limited in the real world.

We use Node.JS to run https://Clara.io. Clara.io isn't at all a simple website. I think you are underestimating Node.JS's flexibilities and capabilities.

Perhaps you could name some website/app servers that aren't mostly i/o (or event-timing) bound? I wouldn't say the use cases are limited at all.

You can always run multiple process instances, and communication between processes isn't really so different in practice than inter-server communication... Which just means you are scaling horizontally by design earlier in development.

I worked on some web-based project management software which was highly CPU-bound.

A typical scenario would be the application querying a database for financial figures, doing a large amount of calculations on those figures and then generating an HTML report from them. I imagine any application with large amounts of business logic like this will be the same.

Could you describe the sorts of calculations those were? Are these regressions or similar? Do PMs really look at that sort of thing? Maybe they were basing a TSP on the latest financial figures? b^)

It seems possible that was a mostly IO-bound system, and the things which could have been conceivably CPU-bound should just have been batched and cached.

I would suggest that what you are describing is the exception to the rule... Most queries, in such a case could either be done in the database or pushed to the browser... Generally if you're doing something CPU bound that isn't video processing or gaming, you push that out of process through a worker queue anyhow.

I have come to believe that the truth about Node is somewhere in the middle: not severely limited, as you imply, but probably not fit to dominate the server ecosystem, either.

I develop on .NET all day, every day, building enterprise CRUD apps with fairly cutting-edge capabilities, for small-to-medium-sized companies. I suspect that Node would fit the server role quite handily if we bothered to port our hand-rolled client-side framework to it. But, as the lady said: "Ain't nobody got time for that."

By what, hacker news discussions? It seems here only "new" things are discussed, but not as much about platforms growing and stabilizing. Its almost like Rust and Golang have taken over the world if you measure by this community.

My prediction is that Go will disappear in same way as it happen to Ruby, Perl and others. It currently rides on the fame that it comes from Google "so it hast to be good". It doesn't really provide anything revolutionary, it just is more friendly toward writing specific type of applications. Just by seeing that majority of people who are using Go are the ones who always explore new languages, and you see majority of people coming from dynamically typed languages such as Python, Ruby, PHP and others makes me convinced of this position.

Rust on the other hand also has a bit of hype, but that hype actually has a base. It is due to a features that are quite significant, not because it comes from Mozilla. The ability to do memory safety checks at compile time is quite a big deal (maybe Rust is not first here to offer that, but it is first that it build the entire language around it).

I believe that Rust actually really has a huge chance to replace C and C++ (languages that were developed in 70s and 80s respectively) and influence future languages.

  > My prediction is that Go will disappear in same way as it 
  > happen to Ruby, Perl and others.

Languages don't really ever disappear, they just become less trendy and therefore invisible to places like HN that revolve around hipness and novelty. Hell, when was the last time you heard about Perl? And yet there is an enormous amount of Perl out there powering systems the world over, and learning Perl will make you quite employable for maintaining and extending these systems. Replace Perl with Visual Basic, or COBOL, or RPG-LE, and this statement remains true.

  > Rust on the other hand also has a bit of hype, but that 
  > hype actually has a base. It is due to a features that 
  > are quite significant, not because it comes from Mozilla.

Longtime Rustacean here, and I slightly disagree. Rust does get a lot of boost from being backed by Mozilla. People are incredibly wary of investing effort in an unestablished language without full-time corporate backing. But yes, the awesome language semantics are enticing in their own right. :)

  > I believe that Rust actually really has a huge chance 
  > to replace C and C++ (languages that were developed in 
  > 70s and 80s respectively) and influence future languages.

I definitely don't expect the world to chuck out C++ and rewrite it all in Rust, though I do expect that Rust will provide an enticing proposition for new systems programming projects that value memory safety while demanding zero-cost abstractions. My hope is that with Rust we can gradually move towards a world that is safer by default.

Finally, I agree that Rust will be an influence on future languages. Just yesterday D proposed something akin to Rust's borrowed references (http://wiki.dlang.org/DIP69), and I'm curious to see if something similar emerges in future editions of C++. There's also Microsoft's secretive M# language, which I suspect will use a similar mechanism.

I don't think it's losing traction so much as it's losing some mindshare to faster-moving projects like Go. JavaScript is moving forward (both in the spec and in the browser) and Node hasn't kept up at all. There's no 1.0 release in sight. ES6 is effectively absent from Node. V8 is around version 3.30, while the version in the build of Node that's in Homebrew is 3.14, which "is so old it doesn't even receive security fixes anymore".

It's frustrating to get invested in a product if you know that it's got stagnant parts that nobody seriously plans to fix in the near-term at all.

I can only speak from the perspective of my company. We had quite a few pro-node people. They wrote services in node.

All of those node services have since been rewritten in Go by the formerly-pro-node people. Go has been much more manageable and powerful.

What kind of services are they?

Hello World, a todo list and a blog application. After that we put "proficient experience with node.js" on all of our developers their CVs. Our company website now lists that we have "enterprise grade expertise with Node.JS" and I haven't even talked about the nodejs-rebranding of our social media dootprint (exclusively liking, following and interacting with nodejs content). We are basically swimming in nodejs client work now. So much, that we are considering splitting the company and having an exclusive branche for the nodejs playfield.

#dootprint

Just wait 5 years they'll be re-written in Swift, Dart, Rust (other shiny new thing). The important thing is, it will probably be the same people doing it ;-)

Really? Dart?

Is that not cool anymore. What's the next "cool" thing?

ITs not that its not cool, its the likelihood of Dart to be implemented in most browsers is low.

Browsers don't implement CoffeeScript, TypeScript, etc either, but that hasn't hindered those projects.

Okay now I see your point, but Dart is far from replacing Node or IO as the next cool thing.

As I said on reddit as well, I'd really like to hear from someone with a year of serious Node experience and then a year of serious Go experience who ended up wanting to go back to Node, for anything other than perhaps a library than only Node had. While the Internet is large and any crazy criterion will match somebody, somewhere, my strong suspicion is that this is not a large set of people. I suspect it's more-or-less a one-way door.

Keep in mind that opinions on HN often do not reflect the situation in the general programming community. I think what we are seeing is a particular developer demographic performing their periodic migration. I'm referring to the group of developers that simply follow the heat possibly caused by some sort of anxiety or fear of being left behind. They did some Java, jumped to Ruby then Node and now Go.

Reply on news.ycombinator.com