[wilmoore]

>> the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast.

As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in the same day), I wonder about this statement (err, fact).

You mentioned that the Ruby language is superior and that this is a "fact". What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)?

In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler.

I'm not looking to "win" here; I'm just very curious now given your assertion.

[tinco]

> What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)?

It's a bit stupid, it's hard for me to even consider the idea of Javascript being in the same category as Ruby. Of course, with Node.JS existing it's totally fair to bunch them in the same category, they're both server side scripting languages.

Ruby was designed from scratch to be a perfect generic scripting language, merging the OO concepts of Smalltalk with the power and unix-friendliness of Perl. No constraints, just an implementation of a programmers dream.

Javascript on the other hand was designed to be a language ran in the browser, with a tightly controlled I/O system a very domain specific standard library and a very short schedule. It's got warts and plain mistakes, it took decades for people to see past them and value Javascript for its redeeming qualities. The redeeming qualities being first class functions and the unexpectedly useful asynchronous I/O model.

You state that you like Node.JS over Rails. I would hesitantly agree. Rails isn't of this time anymore, they made the mistake of not embracing JSON APIs as the future of web development, and are foolishly continuing work on serving HTML. That both Rails-API and ActionCable were not in Rails 4 demonstrates they are simply behind the times. At the time that it became clear JSON APIs and Push protocols would become important people looked around and saw the Ruby ecosystem simply had nothing to offer. Rails wasn't serving them, and all other Ruby projects were either small, not production ready and in either case had no community following. It was a perfect moment for Node.JS which put the modern web right up front. At least, that's how I view that history.

Of course, 90% of web applications being developed today are not 100% single page apps with JSON and websocket backends, so Rails isn't quite dead yet. But perhaps if you're to looking to build such a modern app the Ruby ecosystem isn't the ideal place to look for it anymore. That doesn't mean it's not viable anymore. I wrote celluloid-websocket in a few dozen lines, it basically connects Faye's websocket protocol implementation with Arcieri's Celluloid and Rack.

I really want to write half a book more about why I think Ruby is so much better than Javascript, but it's getting late so you'll have to excuse me.

[wilmoore]

>> ...it's hard for me to even consider the idea of Javascript being in the same category as Ruby.

Indeed. I think anyone would agree...they were not built for the same purpose; however, let's set some expectations here. As it relates to backend JSON APIs, what is better about Ruby/Bundler?

>> Ruby was designed from scratch to be a perfect...dream

OK, that's fine. Though, I've never heard of a proven perfect language/platform, regardless of intention.

>> I really want to write half a book more about why I think Ruby is so much better than Javascript...

Please, no book, but I would be happy to read one concrete example of why Ruby/Bundler is substantially better hands down. Of course, you are free to argue that you just don't like JS. I'd be fine with reading that, but I'm still curious to see a real example. I'm willing to accept that I may be wrong, but without proof, we can't get there.

Yes, Ruby is a nice looking language; still, I have not come across any proof that writing, maintaining, and deploying Ruby/Bundler is substantially better than writing, maintaining, and deploying Node/npm for backend JSON APIs especially given the gratis performance benefit and ease-of-use of Node/npm.

The same or better result with lower overhead and better performance. Before I ever wrote a line of JS intended to be executed via Node.JS, I actually thought Ruby was better as well :)

*

NOTE: I am quite aware that some Haskell lover is probably laughing and sticking their nose up at this entire conversation. That is perfectly fine because I'm willing to bet they can actually provide the concrete example I am looking for.

[tinco]

> Please, no book, but I would be happy to read one concrete example of why Ruby/Bundler is substantially better hands down.

One illustrative example might be the existance of Celluloid. The idea that you as a developer of Ruby apps can swap out the I/O system to something that's arguable better than what what the default style is. The reason Javascript can't do that is because it doesn't have synchronous I/O, nor multithreading, it's simply lacking those primitives.

I don't like the callback style, and I'm not entirely sold on promises.

In any case both those 'issues' might be close to fundamental differences between Ruby and Javascript but if I'm honest, this is going to sound like I'm back pedalling, but in real measurable terms they won't affect the quality of your codebase. I don't think porting a library from Javascript to Ruby would solve any real problem (as Haskell would), and it would result in your library being slower.

The dozens of little things that make Ruby a more pleasant language, they are what keeps me on the Ruby side for most projects.

> I am quite aware that some Haskell lover is probably laughing and sticking their nose up at this entire conversation.

Haha, I'm actually also a Haskell programmer. My top 3 is Ruby, Haskell, C# ;) I do Ruby and CoffeeScript for a living, build games in C# as a hobby and am building a C compiler in Haskell as my secret plot to take over the world. I have a sideproject that's a REST API in Haskell as well, but I'm not 100% convinced yet that Haskell is right for that.

Easy proofs for Haskell superiority: You can compile into a static executable. You can make the typesystem enforce the correctness of your user input parsing (this is crazy effective in JSON Apis, so effective that I now use Grape in Ruby to do sort of the same thing). Its lack of OO and focus on processing data leads to very clean architecture. Its level of abstraction is so crazy that they can actually swap out their entire I/O system for another one without changing any application interfaces, this one blew my mind, it's the change that makes GHC 7.8 run the Warp webserver twice as fast. They actually changed it so the 'fork' system call does not actually spawn a new thread, it spawns a fiber that's run in an event loop type system, and changed all the I/O functions to use asynchronous I/O on that event loop. All of this without changing a line in Warp, they just transparently made every traditional Haskell use modern I/O principles. Academics man, they're smart ;)

C# is cool because it manages to stay clean, fast and structured even though it's super powerful and implements almost every paradigm known to man. It's a statically typed compiled language with near native performance, yet code in it is nearly as succinct as Ruby. If I'd jump ship from Ruby because of performance reasons, it'd be to C#, not Node.js. Provided it runs smoothly on linux of course ;)

[wilmoore]

> Haha, I'm actually also a Haskell programmer...building a C compiler in Haskell as my secret plot to take over the world.

Haha; I got a kick out of reading that. Nice!

> I have a sideproject that's a REST API in Haskell as well, but I'm not 100% convinced yet that Haskell is right for that.

I'd be interested in what you are finding there. I have been wondering if I should start moving toward Haskell or Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and I'm liking it.

What has given you grief on the Haskell side?

> Easy proofs for Haskell superiority...

Wow! I had no idea Haskell was so flexible. Perhaps I really should spend a bit more time there. I've never read anywhere else about this level of flexibility in Haskell.

If nothing else, this conversation was well worth it just for that...thanks :)

[tinco]

> I have been wondering if I should start moving toward Haskell or Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and I'm liking it.

I wouldn't know about that, I only took a glance at Erlang, didn't really like the syntax but Elixir seems really pretty (Rubyist speaking of course ;)). I'm also a bit put off by how Erlang has distributedness integrated in its language, I didn't really try it out so take this with a grain of salt, but I have the feeling that it makes it more of a domain specific language, and it perhaps would be in the way of generic programming. I also had to deal a lot with a misbehaving RabbitMQ at work, so I might have channeled my incompetence into a opinion of Erlang :P

> What has given you grief on the Haskell side?

Well, both web projects I did using the Scotty framework, which I adore. The first was a web adaptation of a school project, you can take a look here[0], I like that a lot. But the second project was a docker container provisioning tool, and it had to do a bunch of stream processing and such. It's not that the libraries are bad, but there's a lot of research being done and there's 5 different popular I/O stream libraries, with various amounts of super high level abstractions, it just slowed me down a lot having to research all of it and dealing with some really high level Haskell.

That's one down side of Haskell. There's an easy way to do things, with nice pure functions and a I/O monad here and there. And there's the hard way of Haskell with monad transformers and generic type classes and what have you. You can easily avoid the hard stuff, but if you get sucked in you'll feel like a total dumbass and it'll cost you time and motivation :P

> If nothing else, this conversation was well worth it just for that...thanks :)

No problem, thanks for making me back up my ludicrous opinions ;)

0] https://github.com/tinco/Ergo/blob/master/scotty.hs