I've worked with Ruby for nearly ten years and have been hearing some variation of "Ruby is dying" since forever.
I've worked with Ruby for nearly ten years and have been hearing some variation of "Ruby is dying" since forever.
Ruby is a flawed language (I especially dislike the lack of real namespaces) but the hate it gets is often not based in reality.
And there aren't many good Ruby developers. There are too many noobs who write Ruby code that make my eyes bleed. I know, because I have to see this at work and they're supposedly "rockstar" developers. Ha! I swear most so-called "engineers": 0. don't grok software engineering, 1. weren't formally-trained in software engineering AND computer science, and 2. happily push shitty code that there will be no incentive to refactor through automated means.
If you want to enforce coding standards in Ruby, you better learn LISP / S-expressions, because that's what Rubocop uses.
That said the serious reason I don't try it out is because I fear it would be like Python, and I don't need two Pythons in my life. If Ruby had been dominant I'd likely be using Ruby and thinking the same of Python.
a particular era of hipster web and app
development, ~2007-2010. I don't know why
but it's not quite attractive.
That was a really fun era.~1997-2007 was fun but it was a mess. It seemed like every project was its own bespoke "framework" and everything was a Java or PHP spaghetti monstrosity.
2007-2014 was the era when "majestic monolith" MVC frameworks with a strong emphasis on automated tests really began to coalesce. Rails led the way here, I think. It was a brief island of sanity if you ask me. MVC may not be perfect but it's a fine choice most of the time for anything CRUD.
I suppose there was kind of a "hipster" aesthetic around Ruby/Rails (Ruby devs kind of prided themselves on being quirky or whatever, as opposed to staid corporate Java drones, I guess?) but I did not find it to really be a factor.
2015-present has been a nightmare. Nearly every web application is now two apps: front and back-end. For apps with highly interactive UIs this is an obvious win but for the vast majority of web applications it has been a disaster. User-facing performance of the modern web is awful and I have never felt less productive as a developer. Every developer thinks they need to do things "like Amazon" or "like Facebook" and just.... no. The Javascript community has absolutely lost all connection with sanity and the era of the full-stack developer is over.
First of all, regardless of what everyone says regarding how "inovative" Rails was, Tcl and Python did it first, with AOLServer and Zope.
During the .com wave, I was part of a startup with a product for CMS development, that was basically inspired from AOLServer, although we did our own thing.
It supported Windows 2000/NT, Aix, HP-UX, Solaris, Linux (only for dev purposes), SQL Server (Sybase and Microsft variants), Informix, Oracle, Access (only as demo concept), and we were in the process of adding DB 2 support as well.
We went down in the .com crash, and Lisbon isn't SV, so hardly anyone heard of us, but it doesn't change the fact we were already better than Rails v1.0 in 1999.
Second, I know Python since version 1.6, so Ruby hardly brings anything other to the party than a Smalltalk inspired workflow, without the IDE experience.
It's like when a game/band/tv show becomes popular, the more popular the more toxic the community becomes, and the louder the hate seems to be. I don't want to pull names out of hats, but pick any of the most used languages and you'll be able to find people banging on about objectively bad parts of the language, and yet they're still the most popular languages.
Admittedly, I don't really prefer Ruby over other languages, but just like PHP I wish people would stop being so dramatic over it. It's plenty good enough to get shit done, if someone likes working with it power to them.
Let’s make a very simple naive test using Google search, "I love Ruby" matches 98,400 results, while "I hate Ruby" returns 7,740 results (from my current terminal).
There is even a book named "I love Ruby" it seems.[1] Compare that to the existence of "The UNIX-HATERS Handbook".[2]
Can you be more precise about what features you miss in Ruby modules compared to "real namespaces"?
[1] https://i-love-ruby.gitlab.io/ [2] https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook
Vaguely similar in performance to Python and PHP (not an order of magnitude off), slower than Java and .NET (for typical web based workloads with mainstream frameworks, .e.g Rails vs Django vs Laravel vs Spring Boot vs ASP.NET), still good enough for most web projects out there.
Even Rails just seems like your average flagship framework, if not an entire platform - certainly on the heavy side, with its own quirks and opinions, but definitely a safe option for getting things done.
It's jarring to see Ruby's popularity be on the decline, though you could also say the same about PHP in many cases.
Ruby, having at least million users around the world, is in immortal category.
What fascinated me in the original post is "...data model on the principles of the Value Object, introduced by Martin Fowler."
I mentioned Haskell because there is a long, long history of the use of immutable objects in computing science, dating back to Church and Turing's communication. The immutability is what differentiates lambda calculus and Turing machine.
That is why I remembered Haskell and the video above.
Yet, it is "introduced by Martin Fowler," for some reasons.
This is very sad.
Or do people think that before Java we didn't have any architecture astronauts on large corporations?!?
For comparison, i've spent many months to hack on Java framework in a company before to deliver a hackable feature.
By the same time, i also released 3 production applications from scratch with Rails.
The issue is not Java is impossible to have such productivity, it's the mindset, the culture issues from Enterprisey people.
Had Ruby and Rails been embraced at the same scale, you can bet there would exist a comparable flavour of Ruby EE.
If you're at work and want to get shit done fast for the salary reason: There's no reason NOT to use Rails.
If you want to go enterprise, use something lightweight and modular, composable instead. Throwing a bunch of inheritable BeanClass serves no purpose on the job.
UNIX philosophy came long ago, before JAVA.
CORBA was born on UNIX, original implementation targeted C, C++ and Smalltalk.
Java was years away to be created, again by a UNIX company.
Java EE, was reborn from an canceled Objective-C project created by Sun and NeXTSTEP, again two UNIX companies.
You don't solve problem by solving it. You solve it by decomposing it, and compose again.
On the enterprise mines, the minions do what they say.
> The issue is not Java is impossible to have such productivity, it's the mindset, the culture issues from Enterprisey people.
I do think that a lot of it will depend on what sorts of projects people work with, as well as how old the frameworks are. Some design choices made in the development of those will certainly show their age. Consider this article, for some nice arguments in that regard: https://earthly.dev/blog/brown-green-language/ (I'd say this also applies to frameworks, not just languages themselves)
I actually recently used Dropwizard to create a proof of concept system for storing and querying millions of files by their metadata and using Java wasn't too bad in the end: https://blog.kronis.dev/tutorials/1-4-pidgeot-a-system-for-m...
I'd vaguely rank the frameworks and libraries as follows:
- Java/Jakarta EE: pretty dated at this point, you'll mostly see it in legacy projects, generally not a "modern" feeling experience, if you need to configure a separate web server instead of an executable .jar file, you're going to have a bad time
- Spring: if you see plain old spring, you'll have a bad time, it's the definition of "enterprise" code and will waste lots of your time
- Spring Boot: can be good if you start a new project with a recent version, still somewhat enterprise but lots of integrations are just plug & play
- Dropwizard: takes a bunch of idiomatic Java packages and glues them together, comparatively lightweight, you can even get by without dependency injection, most of the cruft that you need to deal with ends up being because of the language itself instead of a framework with bunches of weird dynamic class loading and reflection
- Quarkus/Vert.X/...: new frameworks and libraries that try to build something more modern and performant, generally you can look in the direction of these for many of the modern projects that you want to do, though their lack of maturity might show sometimes (e.g. if you try doing something unsupported, or just run into their learning curve, e.g. how the Vert.X event loop works)
I guess I can sum up my thoughts with: Is Java as a language inherently a bit more annoying to work with than some of the other web dev languages? Definitely.
Have its frameworks and the language itself gotten better in the past years, especially after newer versions than Java 8 came out? Yes.
Are many out there going to pick it for its decent static type system, good runtime performance (JVM is great) or bunches of stable packages? Sure.
Are some going to be pigeonholed into working with horrible legacy projects that are absolutely demotivating and show off the worst of the language? Sadly, also yes.
Are others going to look in the direction of something like Kotlin, which attempts to solve some of its nuisances, or maybe other languages altogether? Also yes.
But at the end of the day, a lot of it comes down to familiarity: if you feel like you'll be more productive in .NET, Node, Ruby, Python or another language, and there aren't external external factors that force your hand in a particular direction, pick whatever fits your needs the best.Java could be a much nicer language with much less allowance for architectural space programs.
Type classes were introduced into Haskell as early as 1988-1989. At 1991 you could have programming in language with parametric polymorphism, type inference and principled (albeit called ad-hoc) overloading, there was at least one.
The ST monad, one of the first effect-containing abstractions, was introduced as early as 1992 - I think it was close to introduction of IO monad.
So, at the time Java was introduced in 1995, it could have all these nice properties which greatly simplify programming and make architectures easier to understand and more future-proof (Haskell's solution to an Expression Problem [1] is one of the simplest, it uses what was available in 1995, more or less).
[1] https://en.wikipedia.org/wiki/Expression_problem
Thus, we could have a programming language that makes architecture rocket launch much harder. But we did not.
The slogan was "write once, run anywhere" without any regards on how much is needed to be written or how to safely compose what is written.
These feature flags are not "architecture space odyssey," though. Usually they reduce boilerplate, often significantly.
They are also artifact of Haskell being "research language," as mentioned in video above.
To be fair, there has been some effort to ease the insanity. Record classes, lambdas, and the like lessen the pain of trying to write Java against its original orthodoxy. But before that, a simple "sort list of lists by first value" method involved making a class available in the current scope that implemented Comparator<List<X>> which contains a method "compare".
As opposed to "sortby (comparing fst) list_o_lists"
There was no Java when GoF book came out, CORBA and DCOM were used all over the place, SOAP was initially driven by Microsoft and its COM/.NET group (see Don Box), when enterprise architects get FP into the enterprise, scalaz happens.