Today I accept that Rails is yesterday’s software

The next complain is that Ruby is slow. Ok, fine maybe you build the next Uber and you need to scale almost unlimited. Then maybe Ruby is not the tool you should use (disclaimer: I know not that much about scalability with Ruby). Before you need to scale you usually need to get to the market and if your stack is easy and fast to build with Ruby just use Ruby and then rewrite critical stuff with "faster" languages. Hopefully everything is faster then and you don't discover that the database is the bottleneck.

Only the last complaint is something I get, debugging and all the gems. That is something I had problems with when doing Nodejs projects too. Still, being able to add just a module that does all the OAuth2 handling and I just needed to add 2 or 3 lines of code was nice.

So in the end, what is the point of the article? Is it just the roadmap of Ruby that bothers you? Is it the Rails community that consists of lazy thinkers (not my opinion)? Or do you see all the people doing fancy and hip stuff like Protocol-based programming and functional programming and you doing still OOP stuff? If that's it, learn a language from those realms and try it, I'm pretty sure you will find those being the silver bullet either.

I know my comment sounds like a rant, it is not meant like that. I'm just wondering what got you to write the article and what is really bothering you. Also, why are so many people afraid to miss the next big thing? While developing and working with a language and framework you're not just learning that particular language and framework but you learn how to approach certain problems, what pitfalls to consider and so on. You can use that with most other language/frameworks again. You didn't waste your time.

Even Go makes it extra easy because the developer does not even need to care about packaging as long as there is a git endpoint with the code.

And there are two ways of seeing this:

- One says that this is awesome. Microlibraries allow to make every little module really good by allowing multiple people to iterate on it. That having 100s of dependencies of small modules that "do their thing right" is better than writing functions oneself, which surely leave some corner cases out and decrease the quality of the applications.

- The other says that this is fucked up. That dependencies break your apps in ways you couldn't have imagined and by surprise. That tracking these problems down is a pain and often requires reading through obscure core that does way more than what you need in the end because it's generalized for every use case. That maintaining dependency hell ends up eating the benefits of not having written the code oneself.

I personally find scary when someone runs "./mvn build", "sbt assembly", "bundle install" and this triggers a download of dozens to hundreds of nested dependencies from a place which has to be online and hopefully hasn't been compromised. On the other side, it is clear that if an existing module does the job, why would you re-invent the wheel? And aren't small modules and microlibraries the expression of "simplicity" the author demands? Not sure there is an easy answer for this debate...

I don't see any competitors out there. Well.... Phoenix looks pretty damn good. Still, with not-so-mature ecosystem (~2k packages vs ~100k for ruby, same goes for SO questions/answers, blog posts etc) it can't be solution for everyone as of yet. So... What's the meaning of

To give one example, the documentation for just about every function seems to say that it returns 'Object'. What kind of object? You have to dig through the source to find out.

I typed 'image' into rubygems.org and here's the first example: http://www.rubydoc.info/gems/fastimage/2.0.0/FastImage

It doesn't seem hard to use, but notice that all the attributes are listed as returning 'Object'. If I look at the 'type' method, I wonder a few things:

* What is a uri exactly? Is it any old string? Is it an object returned by parsing a string using some standard Ruby library?

* What can be returned? They give some examples of symbols that can be returned. What is the full list?

Contrast that with the types listed in this image library I just looked up on Hackage:

https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/C...

I've never used this library before, and I can see roughly how I would use it just looking at the types:

readImageWithMetadata :: FilePath -> IO (Either String (DynamicImage, Metadatas))

"readImageWithMetadata takes a filename, and reads the file returning either an error message or an image together with its metadata"

What exactly is an image? You can click through and see it's one of 13 things:

https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/C...

What exactly is an image's metadata? You can click through and see it's an abstract type that can be manipulated using operations like you'd find on a map(a dictionary). In particular, see the 'lookup' function to see how to access things.

Here's a more complex example:

encodeGifImages :: GifLooping -> [(Palette, GifDelay, Image Pixel8)] -> Either String ByteString

"encodeGifImages takes a number of times to loop and a list of palettes, delays, and images of 8-bit pixels, and returns either an error message or a sequence of bytes representing the .gif"

I feel like it would be less clear what needs to be done to call this function with the Ruby equivalent. I'd probably end up looking through the source.

Just as important with the signatures is what the functions are not doing: encodeGifImages isn't rewriting any symbol tables, monkey-patching new methods into existence, changing global variables, writing to a database, opening a file, or printing a log message. I can say all of this because its type doesn't allow it to. I could run encodeGifImages in an interpreter or test without needing any setup.

The Ruby library here wouldn't give anyone trouble either. The examples are probably sufficient to use it. I think with Ruby as long as you can find examples close enough to your specific case you can usually make it work.

But if you're debugging something that doesn't have an example readily handy, the static type system makes it much easier to see what something is doing.

I used Haskell here, but C# or C++ would probably work just as fine for this purpose. Well, unless you're the type who likes to cast everything to void* so he doesn't have to worry about the types.

Hope this helps.