I don't get the purpose of the article. So the first complaint is that programming was hip but isn't now. Who cares? Do you program because it is hip or did you choose the language, framework and so on because it is hip? I hope not. Maybe if that is one of the concerns, just change the language. Is Nodejs still hip or Go or do you need to program your stack in Swift even before the language is really stable or as an official package manager?
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.
They're probably bothered because of the realisation that the foundation of their toolset is made of clay tied together with duct tape.
And one can only add so much to the typical web development toolchain before if falls down like a house of cards.
To me it's surprising to see some people finally begin to figure out that dynamic typing, monkey patching, importing packages upon packages can only get you so far. Yesterday it was Ruby, today it's node.js.
Maybe tomorrow we'll have something that doesn't have to be replaced in 6 years again.
I don't see the problem. If you get so far and then need to do something else, only then is the time to start worrying about doing something else. Until that point the focus should be on shipping a quality product that satisfies a need. Do that well enough and you will be in a position to start worrying about using better languages for certain problems. Almost every tech company that is slightly mature has multiple languages in production anyhow and they got there because they built stuff and shipped it.
The big question is if they got there because of the tools and practices they use or in spite of them. With enough money and talent one can use pretty much anything.
And the problem with having to rewrite your stuff is that the company might go out of business while doing it. Assuming it's something complex, and not e.g. reddit (which I suppose is not at all easy to build as a full product, but at the end of the day is an online forum)
If your company goes out of business because you spend time re-architecting then you're doing it wrong. The thing with stuff like Rails is that we don't need money to start quickly. They are amazing for validating a business idea and doing fast iterative agile development which is the core to building a successful startup. Once you've done that and have either cashflow or serious funding you can afford to pull out some functionality into separate services with more appropriate architecture etc. For what most MVP's are, tools like Rails are very good as they optimise for build speed. Clearly they can't do everything and shouldn't be used for some things but for most web things they are a solid choice. Companies that optimise prematurely are far more likely to go out of business.
Not really. I fully admit that C++ has its share of problems and the tools too. However, it's a known quantity and one can build upon previous knowledge.
I won't have to learn a new framework because it's the cool new thing or rewrite everything in X because I had en epiphany, it's too slow or doesn't run on some platform. I can focus on solving problems and improving my skillset. C++ is a tool, not a way of life and it gives one a surprising amount of mileage. It was used 20 years ago, it evolves and will probably still be used in 20 years to come.
Perfect skill reuse does not exist in our industry, one can at best hope that when the next thing hits one doesn't have to learn it from scratch. C++ offers a good compromise between evolution and stability IMO, I could go back to doing C++03 and the tools, libraries, etc would still be there.
So these days about every language supports any form of "gem" import.
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...
What about cherry-picking modules, briefly going through their source code (and, hopefully, test suite), then manually (read: copy/paste) importing them into the project at hand?
What are the ethical implications of this, though? Is it different than importing the module directly via package managers, license file and all?
I have this same problem with Python apps. One has to verify if the dependencies are acquired in a reasonably secure way, because security is a second (nay third) thought for developers.
So error handling improvements, dependency consolidation, good gradual typing, good JIT are all things that Ruby will never see? He dismisses NodeJS despite it not having quite the same bag of problems, for one having excellent JIT and (IMO) gradual typing.
Complaining about coffeescript...There is absolutely no reason anybody needs to use coffeescript in a Rails project. Rails works perfectly well without it. Now, some people prefer the syntax and find the extra layer of transpiling to be worth it. But if you don't, just use vanilla Javascript! Rails certainly has some things to complain about, but coffeescript ain't one of them.
MMkay, Rails is old and should be replaced. Well... to be replaced you need to use something instead, something at least not worser thann "yesterday’s software". Rails still great software, despite its "super slow" negative fame it still pretty damn good at getting things done (also faster than like 80% php frameworks)
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
Half the things he's complaining about can be fixed by streamlining dependencies.
If PHP can sort out their mess with more modular components, seemingly driven by Composer and Syphony, then I can't see why Ruby can't sort themselves out.
I had the same complaint with Rails: There's too many libraries injecting things into various places, and it's hard glancing at the documentation for any library to see what the rules of the game are.
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.
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:
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.
"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.
For those who thought "tl;dr", I can sum up this entire post in one sentence - "programming is hard and to be effective as a programmer you need to have at least a reasonable amount of knowledge of the language and frameworks you are using".
I like Rails a lot, but mostly program in C++, and I can assure any disheartened Ruby programmers that many of Ruby's perceived issues are minor compared to the ones I face when programming in C++...
Incidentally, it may seem odd to say - I enjoy programming in C++, even with its problems there is a lot I like about it.
I guess we agree to disagree then. What was the overarching message you got out of it?
Incidentally, I encourage everyone to also read the article, then make up their own mind. Nobody has to take my word for it, but I suspect many will think the same thing I stated above after having read the article.
Perfect knowledge of one's tools can only mitigate some of their weaknesses, not overcome them completely. They seems to have realised that their tools are weak, and the brand new thing is also weak and they don't know what to do.
But if you think the state of web development nowadays is fine and better inderstanding of ones tools is enough, then we have a fundamental disagreement.
Sorry, is that your opinion in general or are you giving me what you believe is the overarching idea behind that post? Because I sure as heck didn't get that out of that article!
Right. So in other words, his complaint is that programming is hard and there aren't enough tools to allow those who don't have a reasonable level of knowledge and skill to develop scalable and maintainable programs in Ruby.
By the by, perhaps a problem of inadequate tooling requires the development of more adequate tools?
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.