I like that the Ruby community has embraced the fact it is no longer cool.
I recently interviewed for a ruby/rails job where the dev team had come from a previous start up that tried to port an existing Rails app to a React/Microservices one with disastrous results. For this job they were relishing coming back to a monolithic Rails app. I hope this trend continues!
My latest job is at a place where we have an extremely 'old-school' Rails app. The vast majority of UI is server-rendered HTML, Javascript (at least that we wrote, we do use Turbo) is very, very minimal, and we're just one very large service.
The previous place I was at was a microservice heavy (the count of services was almost on par with the number of developers) React and Node based application.
I'm orders of magnitude more productive with the Rails app, it's more well regarded by our customers, and using it, there's no obvious telltale signs that it's not using the modern SPA approach.
I have a theory that there's a perverse incentive for startups to make their work more expensive and therefore more complicated. It's related to this quote by Paul Graham about funding:
"VCs don't invest $x million because that's the amount you need, but because that's the amount the structure of their business requires them to invest. Like steroids, these sudden huge investments can do more harm than good. Google survived enormous VC funding because it could legitimately absorb large amounts of money. They had to buy a lot of servers and a lot of bandwidth to crawl the whole Web. Less fortunate startups just end up hiring armies of people to sit around having meetings."
For those that aren't VC funded I think that a lot can be explained by cargo-culting; "If startup X is using Node/React/Redux/microservices and they just scored a 20m Series A then we'd better do it too"
> For those that aren't VC funded I think that a lot can be explained by cargo-culting; "If startup X is using Node/React/Redux/microservices and they just scored a 20m Series A then we'd better do it too"
Part of it is also from employees: "everyone else is using Node/React/Redux/microservices, if I can push my company to do it I will have more relevant skills for the market". I often hear that for k8s too.
Yeah, I think it helps that we're very intentionally lean (we currently have just 2 engineers servicing about 100,000 paid subscribers, which is a bit too lean for comfort for me, but at least makes us think very hard about introducing complexity).
I’ve often thought that this would be a good constraint i.e instead of hiring a dev ops to migrate to a complicated AWS/k8 setup, it might be better to spend that wage on added Heroku costs to keep things simple
Even in the AWS world, there's simpler options than k8. We run a pretty basic elastic beanstalk setup that serves us well enough. A big part of that is having a monolithic service though, most of the complexity either disappears or becomes pointless when your stack is just app servers, a DB and redis.
I've already have had a good bunch of similar experiences at previous companies, where you hear all the time "we're moving away from the monolith". Problem is after you've been hearing for 5+ years, it probably means it will never go away. This particular company ended up with 100s of "microservices" around it, first in Elixir, then Elixir went out of favor so they started rewriting in Go, then came GraphQL so some microservices were serving GraphQL while others stuck with REST, then different frontends in React, some with Redux, then redux was not the current trend so MobX, then MobX was not cool because now it was all hooks, then some moved to Next.js because of course nobody understood our custom in house webpack setup. Now I've heard they're moving to Svelte.
I honestly don't see how that can be better than sticking to Rails/Laravel/Django and embrace the monolith. All this madness of building things at every single company as if it were Netflix or Amazon is an insane waste of resources. Some days I feel like we (engineers) are like kids playing with the toys we want to play with rather than be solving real business problems and maintaining our projects in good shape technically speaking.
You can’t unless you’re a decent programmer and only when you don’t think you’re 100x yourself
Otherwise it’s insanely hard to measure, bc people will come up with bs about how difficulty, complexity, test coverage, change management, dependencies.
People complain about car maintenance and the plumber, but programmers are worse.. you simply have to believe they’re working on magic… bc, we’ll, you wouldn’t understand right?
I had a coworker which was the most useless developer ever, not able to do absolutely anything by himself and totally unsure about everything. But given it was a big company it was easy for him to "hide" and rely on just showing up for meetings, talking to everyone, etc.
Then he was the first one to ask for raises, despite he was earning way, way, way more than he should already.
Then one day he came complaining that the mechanic wanted to charge him X for fixing his car and that it was too much and how could that be possible, etc, etc.....I just couldn't believe it.
I hear what you're saying but surely it's a responsibility of the tech leadership (and even the non-technical leadership to some extent) i.e. simple questions such as 'surely it shouldn't take this long to ship a simple feature?' or 'why is everything so complex and ever-changing?'
You don't understand, it's different today with all the micrososervices, packages, toolchain, kubernetes, docker, cloud, security, product management isn't clear, they change too often, it impacts all the code, we'll have to test everything again, this isn't php, compiling takes ages, we need faster machines with 128gb ram, it's complex because we need to be flexible, otherwise it will take ages when we want to add anything in the future, and we don't want to rewrite the whole codebase in the future, we spend all our time refactoring, the ops guys running the database aren't doing their job - that's why things are slow, not because we don't understand sql, the customer always makes user errors and we have to solve their problems, we need to do more peer programming,
bla bla bla bla bla.. It's just bs by incompetent and deceitful people
They measured it by the number of Jira tasks moved to "done".
The problem is, nobody is asking if those Jira tasks could have been avoided, or be a lot smaller if we were working on a more productive stack.
At the end of the day product managers get used to everything taking a lot of time and assume that's the only way (which, to be honest, in this context it is... as reached this point it is very difficult to go back).
And also, when productivity was discussed... there was always someone suggesting the problem was the current "legacy" stack (i.e. React, Elixir) and that we should instead move to this other new stack to be more productive (Go, Svelte) and there we go again...
Yes, I find that community interest tends to peak about 10 years before business interest peaks in any given language. Right now we have more companies using Ruby/Rails than perhaps we ever did, but community interest peaked 10 years ago. Perhaps we'll see something similar with Rust a decade from now.
A sports car might be cool but it's terrible as an Uber. Context is important when making any choice, tech stack or otherwise.
Ruby and Rails are pragmatic choices for building a business, they may not be cool anymore but they are focused on developer happiness and productivity.
It's too bad Ruby isn't seen as 'cool' anymore, it's just so easy to be productive in it. And now MJIT, YJIT and TruffleRuby are making some very impressive performance gains. Rails is also better than ever and I still can't think of a better language for scripting.
I love the fact that Ruby is no longer cool anymore and has finally matured enough that one can build a stable system on top of it. It now has been battle tested and powers some of the biggest platforms on the web.
I couldn't be happier with the direction that Ruby 3.0 and Rails 7.0 are taking at the moment. We have businesses to run and Ruby allows just for that. It's boring, it's stable and will deliver results.
I wouldn't pick it to build the next Discord though.. One must use the right tool for the job.
What was cool was Rails, IMHO, and Ruby was the surprise inside it.
I've had my own personal Advent of Code these holidays, coding a small API for a personal need. Ruby (Sinatra) took one morning to full deployment in Heroku. Then I tried Crystal (Kemal) and it took me a couple of days to figure out how to map JSON to Crystal data structures. Then I rewrote it again in Rust (Rocket). Two weeks till I figured out, well, almost everything.
My opinion: they will take dynamic typing from my dead cold hands.
I also took a while to get used to the typing in Crystal but once you do get it, it's worth the effort IMO. I occasionally still fire up Ruby but if I have anything more to do than a quick command-line command, I use Crystal, so many less problems.
Crystal was overall a pleasant experience, which I cannot say for Rust. Although it was probably my fault: 1) for being "rusty" as a programmer myself, and 2) having zero experience with Rust. I want to believe that once you get over the learning curve in Rust development speed becomes much higher.
Surprisingly, Crystal seems to be much leaner in runtime size than Rust, with similar performance (although the use case is so simple that even good old Ruby is fast enough).
But then again, I feel you cannot beat Ruby in terms of dev productivity.
I've heard it described that Rust allows you to write programs in a specific way. If you try to write them in any other way, you're going to have a very, very bad time, and fight the borrow checker every step of the way. But if you embrace that way of writing programs, it makes it pretty easy, you get really good error messages, and as a cherry on top your program will be provably sound in a way pretty much no other language can guarantee. So it all comes down to whether you're interested in learning that specific way of structuring programs.
That's true, but then it is not "allowing" or "enabling" me, it is "forcing" me to do it that way. Of course, the Rust compiler is catching a gazillion bugs beforehand, so this is cool: you finally feel like your program will have no bugs once you manage to compile it.
Error management through Option values, the borrowing checker... they are cool technologies for a C-like language, but they are not palatable at the beginning (maybe they are an acquired taste like beer?). I am tempted to stretch it a little bit more and see how productive I can become writing Rust code, but also not so sure about the effort.
I also gave Rust a go (last year? Hard to keep track since the pandemic) but the book I was using was geared to C programmers so I quickly lost interest, though I would like to understand what the hype is about.
I think the bit about productivity may certainly be true if you have to use libraries, obviously Ruby has many more available now (maybe forever), but I certainly feel more productive in Crystal now, maybe for things other than the language itself, admittedly. For example, producing a binary makes installation a breeze, and I don't worry about which version I'm running as I point the right compiler at the code; no Bundler now, library installs are sane (at last!); and socially I find the lack of "rockstars" in the main team refreshing, I have no fear of being dissed or dismissed, it makes contributing easier.
I think I'd be more interested in Crystal if it was easier to integrate into existing ruby code bases via something like the FFI.
As it is from Ruby 3.0 we have built in optional static typing and with interesting projects like Sorbet Compiler[1] we have the option to statically compile making use of that. It's still WIP I believe but it's giving ruby devs some cool options.
> I think I'd be more interested in Crystal if it was easier to integrate into existing ruby code bases via something like the FFI.
That would be very nice, I agree, though I've always found the FFI interface an under-documented pain so I'd probably end up just using Crystal or using some other way to interoperate, like pipes or HTTP.
On Sorbet, I just hate the look of it. I know it's subjective (possibly that's Ruby's own fault for being so delightful to look at, I'm spoiled!) but I can't abide the syntax. Crystal's is much nicer, and has some extra sugar sprinkled on top for the moments you're most likely to be using it (like external names in method signatures[1] or providing init args) that win out for me.
Sorry about the formatting, I can't work out HN's markdown :/
# Ruby
# from the Sorbet intro
extend T::Sig
sig {params(name: String).returns(Integer)}
def main(name)
puts "Hello, #{name}!"
name.length
end
# Crystal
def main(name : String) : Int
puts "Hello, #{name}!"
name.size
end
puts main "you"
That's so much nicer to my eyes, and you don't need most of it as it will be inferred.
Initialisation is nicer, too, (unless Ruby has been updated in this regard too? As I wrote, I use it much less now)
# Crystal
class A
getter name : String
def initialize(*, @name); end
end
a = A.new name: "Hacker News"
puts a.name
or without the getter and keyword arg:
# Crystal
class A
getter name
def initialize(@name : String); end
end
a = A.new "Hacker News"
puts a.name
Whatever suits.
# Crystal
# Example of external names
def increment(value, by)
# OK, but reads odd
value + by
end
def increment(value : Int, by amount : Int) : Int
# Better
value + amount
end
puts increment 1, 2
but those types are easily inferred so it's actually:
# Crystal
def increment(value, by amount)
# Even better
value + amount
end
I could go on because now I'm comfortable with it, it looks much better. I feel the way moving from Perl and C# to Ruby felt.
So you are accusing me of lying, how lovely of you!
Let's see if your accusations can hold up to Socratic questioning:
- If I haven't open sourced any Crystal projects does that mean I haven't written any?
- I have published several Ruby gems[0], when was the last commit or version bump for any of them? You're more interested that I am, tell me. I really should archive them, thanks for reminding me.
- You missed off my Gitlab, what was the last public contribution I made there? (hint[1])
- What's the last gem I created? I reckon it's this one that I didn't publish[2] because the Rack team changed a public API in such a dumb way that I'd have to rewrite it and then mucked me around with a pull request to Rack that one of the core team copy and pasted in as their own commit while arguing against the pull. Weird, but lovely people, like yourself. Meanwhile, your cookies lack security. Yes, I want to continue working within this language and ecosystem… Does the sarcasm come through in my writing?
- Why did you not check the Crystal repo?[3][4] Github has a search facility. Put my username in, and pick `commits` on the left.
- How did you miss the forks of Docopt.cr[5] and Fancyline[6]? They're right there in my public activity log. Did you not see the merges into Fancyline of my code?[7] I have more to give, just trying to find the time.
- Did you not see forks with commits such as xattr.cr[8], xdg.cr[9], and Pope.cr[10]
- You didn't see I'd provided a project[11] for Mint so it can be run easier with Docker Compose?
- Aside from that I have a whole host of changes to migrate.cr[12] still to push up. You can't know that but you might've guessed that I was at least working with that - and all the other forks of Crystal projects I have.
That is all public and not the half of the Crystal code I look at.
Should I expect an apology? If you were too cowardly to be straightforward with your accusations then I find it stretches credulity far beyond breaking that you could be big enough to provide one. We'll see, like you, I've been very wrong about people in the past.
Sorry, looking through the forks, they are all in sync with master, and most your contributions are small. It is great, nothing against it. The only thing that I wanted to say is that as soon as you start to work in a real project with Crystal you realize that it is not just a better ruby and it comes with it's own set of problems, patterns and etc. So I don't see a point to cite Crystal as option to ruby in every thread about ruby. That's my point.
> Sorry, looking through the forks, they are all in sync with master
I don't think you understand how Git works, which probably explains why you missed all the repos I needed to point out to you.
> , and most your contributions are small
What have you ever contributed? Show me.
> The only thing that I wanted to say is that as soon as you start to work in a real project with Crystal you realize that it is not just a better ruby and it comes with it's own set of problems, patterns and etc.
How would you know? Please share the repo in which you found this out. What is a "real" project?
> So I don't see a point to cite Crystal as option to ruby in every thread about ruby.
You've contributed nothing of worth, not even a specific criticism of Crystal, let alone anything worth knowing about Ruby.
> I don't think you understand how Git works, which probably explains why you missed all the repos I needed to point out to you.
LOL, you forked many repositories and didn't push any code. You just proved my point. Just people without experience in Crystal comes to ruby related threads to say "Dude, use Crystal". Happy learning <3
> LOL, you forked many repositories and didn't push any code.
Well, firstly that isn't true, and secondly even if it were true it's a good idea to fork repos you use. So, not only are you:
- childish ("LOL", really? This is HN)
- lying (always the sign of a strong argument)
- unable to search Github effectively
You also show bad development practices. Did you not see what happened this week with Colors.js[1]?
> You just proved my point.
Quite the opposite.
> Just people without experience in Crystal comes to ruby related threads to say "Dude, use Crystal".
Where is your repo showing your experience in Crystal? Or Ruby for that matter. Money where mouth is time, do you even have a single commit to a project in either language?
> You've contributed nothing of worth, not even a specific criticism of Crystal, let alone anything worth knowing about Ruby.
There is nothing in the text about Crystal. Why should I talk about Crystal?
> Where is your repo showing your experience in Crystal? Or Ruby for that matter.
I don't have too. That's not about Crystal, but about ruby :)
That's not about me and my code, not either about your little unknown rubygems, but the desire from people like to you to recommend Crystal as "drop-in" replacement for ruby, which is not.. Typical "I'm vegan" comment when people are talking about barbecue.
If you know nothing about Crystal, and seem unable to provide any evidence that you have anything of note to add about Ruby, then you have no way of knowing if Crystal can be a drop-in replacement for Ruby, and why you’re using quotes around “drop-in” when you’re the only person on the entire page to have used that word is telling.
Mendacious to the last. If you find a way to make a substantive or informed observation then do let me know, otherwise, please save it for your friends on Reddit.
> they would see how far from "better ruby" is Crystal
Are you accusing us both of lying? How strange.
now that I read "accusing us both of lying".. how could you interpret it like that? What I can see by your code, you are ruby developer trying to learn Crystal. See you in the next ruby thread ;)
I've had so many problems in the past, even on my own machine, writing quick scripts for Ruby that then fail because of clashing versions etc. Being able to produce a binary is nice, or even just using `crystal run`.
Btw, I took a look around your Github and found some really interesting projects (yours and others), thanks for replying!
Hot take: I'd love to see JSON die and get replaced with something more strongly typed and safer to work with. What, I'm not sure, but it is, as you say, a major pain point no matter what language you're in. Either it's easy to work with, but insecure, or it's difficult to work with.
Apparently Rails is the killer application for Ruby just like Unix/Linux is a killer application for C. What Ruby enabled is something that was not feasible to be done by Java, PHP, Perl and Python (top four most popular languages for web at the beginning of Rails). For better perspective on the matter please check an excellent article by Patrick Lee, the author of the new Stanza language.
Sorry I had to intervene here. I had the same sentiment about IDE support for Elixir from using the mediocre IntelliJ Plugin.
However... after dabbling a bit I discovered VS Code + Remote Containers Plugin (because of Docker) + ElixirLS + other minor Elixir plugins that have turned my Elixir development experience into pure bliss. I haven't used the debugger in the IDE yet but I am 99% sure it's gonna work out of the box.
Happy to try and share the setup if you want to try it out.
You probably don't want to use an ide-driven debugger for elixir, you'll want to use :dbg which has a different "conceptual model" than what you are used to and doesn't map well onto Conventional debuggers.
It's simply not the same due to the extreme high degree of concurrency in the beam VM
Literally, elixir doesn't work like that. There is a bunch of other stuff running around in the VM, even if you don't ask for it. It's like an operating system.
> is why people some people find the Elixir community off-putting
I mean ok. Note that I said "you probably". I'm just coming from a lot more experience than you have. But sure, keep giving yourself excuses to be closed minded. It really sounds like you went into the whole thing with the "let me find a reason to hate elixir" mindset, and not the "let me see what people are raving about mindset". Anyways, you're the one missing out.
> Literally, elixir doesn't work like that. There is a bunch of other stuff running around in the VM, even if you don't ask for it. It's like an operating system.
And yet, it does. Here's proof that you're wrong, a screenshot of the community Elixir plugin paused on a breakpoint, all the variables inspectable/modifiable and you can even jump around the stack: https://raw.githubusercontent.com/KronicDeth/intellij-elixir...
The problem was that I could not get the plugin to work consistently, but when it did work it was great.
> I'm just coming from a lot more experience than you have... giving yourself excuses to be closed minded....Anyways, you're the one missing out.
it's way different now. I've actually never deployed elixir on a deployment service till last week (either: "was R&D and never deployed to prod", "I ran elixir on-prem inside a DC", "my prod environments have been managed by ops team"). It was surprisingly easy, had my first deploy (including installing the service provider's tool) in about... 3 hours?
Nope. Can't stand that Python uses built-in functions for basic things like list, map, fold, etc... instead of methods on base classes. Here's a super basic example. Add one to an array [1,2,3] and print results.
Python: print(list(map(lambda x: x + 1, [1,2,3])))
Ruby: print [1,2,3].map {|x| x + 1}
So much more readable, easy to write, etc... Ruby keeps it consistent by making pretty much everything an object and you just call methods. Even Haskell has dot notation to chain functions since it's just so much easier to read and write...
Ok, that's a nicer result (obviously I don't write Python lol) but still seems inconsistent to me (putting the function before the array) considering Python is an OO language and most people are going to be writing methods for classes where you call methods with dot. I just remember list comprehensions from Coffee-script and not going to lie, I hate them. It's like reading backwards.
Ruby has map, filter, reduce and a bunch of other functional methods. It's more about the consistency of wondering what's a function versus what's a method and then things like list comprehensions and for loops. Python also doesn't have a lot of the goodies of a real functional language, it encourages for loops and seems to be even more procedural than Ruby but less OO?
Python, I think, has n number of ways of doing the same thing while Ruby's everything is object approach forces you down a single approach. So while reading ruby code, you usually don't have to shift your mental model from OOP to procedural/list comprehension etc.
If Ruby gets a good machine learning library on par with something like Pytorch, I am sure many folks will shift to it and we might see new DSL emerge.
How I wish that was a possibility. Unfortunately Python's dominance of ML and AI is a fait accompli. If anything is going to replace Python in this domain it won't be another scripting language with similar performance.
For me it's annotations. Looked at from a distance, what appears to have happened is that the implementation hit a certain level of complexity before class methods got implemented, and it ended up being easier to do them with "@classmethod" than with "def self.foo", or to fix whatever reason it is that makes "def foo(a,b,c)" not act like a class method if "a" isn't "self".
This is what really put me off Python as somebody who learned Ruby as their first proper (professional 9-5 usage) programming language.
There are other things too, like how print used to be written like a keyword not a function for some reason, and enforced indentation instead of braces or "end" keywords, all just really bugged me. It felt like somebody made YAML Turing complete...
This really goes to the heart of the problem with modern Python. It's lost the simplicity of the language which was the whole point of it in the first place. OO and functional paradigms were bolted on to varying degrees of success, but an outsider can no longer look at average Python code and understand it at a glance.
List comprehensions were added to Python in version 2.0, which was released 21 years ago. That was about six years after Python 1.0 was released. Are you seriously pining for the simplicity of Python 1.x? (Most of the "outsiders" you're talking about were in elementary school at the time, I don't think they were reading a lot of Python!)
Ruby has a focus on developer joy and productivity. In some cases this comes to the detriment of language simplicity, and existing features can complicate language evolution.
Surprisingly with this complexity Ruby has had a bit more success with optimized implementations than Python, such as Truffle Ruby.
Ruby is a bit more multi-paradigm than Python IMHO, and has been jokingly called a "language for connecting adults". One can monkey-patch override division to return fractions, with the person maintaining the project deciding if this is a good idea or not. This can potentially make projects with a large number of dependencies harder to debug, which interestingly seems to have created some push-back on importing lots of arbitrary dependencies.
With both Python and Ruby, you wind up having divisions between dependencies because of the poor mismatch between different paradigms - for instance, libraries built to work with Python Twisted or Ruby EventMachine for I/O, or libraries built to work generically or to integrate into say Django on Python's side or Rails on Ruby's side.
Interestingly the communities seem to have different key focus areas - Ruby has historically been very focused on testing (cucumber and selenium for instance) while Python has had a lot of focus on documentation (pydoc and sphinx). Oddly, neither really has had a noticeable literate programming push.
Equally maybe. Simpler? I'm not sure, I don't know Python very well.
A couple of things I found surprising about Python was having to do the whole `re.compile` thing instead of just `//` in Ruby. Also, no one will ever convince me that a list comprehension is simpler than `map` and related functions. Also, it's hard to beat the convenience of libs that let you do `1.day.ago`.
Ruby gets complicated when people start throwing around metaprogramming where they shouldn't.
I do like Python's file == module. Python seems like it would be a good functional programming language but it goes and only allows for single line lambdas.
> Ruby gets complicated when people start throwing around metaprogramming where they shouldn't.
This is true. Thankfully it appears that the broader Ruby community has recognized this as well, and has moved away from metaprogramming to a large extent. It's still there, but you don't see it utilized nearly as frequently as you once did.
I'm fine with it for libraries. In fact, its use in libraries is a lot of makes ruby great! It goes too far when people start sprinkling it in business logic making it impossible to find where anything is defined. I'd say you'd either have to go full-lisp and create an entire DSL for your domain (and document it) or keep it completely out of business logic (which, as you say, the community as a whole has pretty much figured this out).
> Python I find equally if not more simple. Would you agree?
Simple, yes. But when I want to write a script as fast as possible with the least amount of effort I don't want simple. I want convenient and powerful. Many things which in Python take multiple lines in Ruby are simple one liners.
There's a certain dichotomy between Ruby and Python that I also see in many other pairs of languages. One language is simple, easy to learn and easy to read (Python), but is not as powerful or convenient to write. The other language is more complex, harder to learn and harder to read (Ruby), but is more powerful and convenient to write.
It seems like most people prefer the first category, which I think is why languages like Python or Go are so popular. There's nothing wrong with that as it's a tradeoff, but I personally prefer the second category, which is the reason why I do all of my scripting in Ruby and not in Python like everybody else.
Simply put I don't really mind the extra complexity since it is essentially mostly a one time cost, so I always pick whichever tool will make me more efficient in the long run. And out of the two (Python and Ruby) that's Ruby. (With a few exceptions like, e.g. machine learning, where you don't really have a choice.)
Really depends on what you mean by "simple". "Simple" is one of those descriptors that gets tossed around a lot in programming by rarely with a clear definition.
Python is a "simpler" language with its preference for "one obvious way", and it does tend to support fewer paradigms than Ruby. Ruby is a more complex language, supporting many approaches. But if you are familiar with the various approaches, that can be "simpler" if it allows you to choose the most fitting approach for whatever problem you have at hand.
To put it another way, "simple" can mean "the language is small/has an obvious way it wants you to do things", or "simple" can mean "the language is flexible enough to be used to model your problem in the most appropriate way". Python is the first kind of simple, Ruby is the second.
IMHO Ruby is much more expressive than Python, and the stdlib is better designed and less crufty. Ruby really has one of the best stdlibs around, I think, and a lot of languages could learn a lot from it - particularly the design of `Enumerable`.
So I prefer Ruby when I have the choice. Part of that is probably just familiarity, but I've been a full time dev on both Ruby & Python projects for long stretches of time so I think I'm in a decent position to compare them. My personal preferences/taste is another aspect, of course, and there's no objective accounting for that.
The case where I often will prefer Python is if I'm scripting something that needs some degree of portability. If you pick a random Linux box it's much more likely to have some version of Python installed than Ruby, so if I'm writing something that should be easy to copy to a box and use without additional setup, I'm more likely to pick Python.
Ruby has the ability to automatically download required gems in single-file scripts via bundler. I don't know of any equally convenient alternative for my python scripts.
Having done both professionally, I'll take Python any day of the week. The "Expressivity" lauded by Ruby fans translates into a lack of readability. But the things that drives me crazy is the optional/alternative syntax of ruby.
Ruby is a lot like spoken language in that regard. When the many ways in which to do things are chosen well, Ruby reads like pure poetry. For that I will always enjoy Ruby.
Moreover, the choice of which idiom to use conveys the intent and mindset of the author.
But like any complex language, it's also possible to write very unpoetically, and like any complex language, readability is a function of familiarity with the language's syntax and idioms.
Python forces you to wrestle with its'/Guido's idiosyncracies. It wears them on its sleeve almost like a badge of honor. You may enjoy them, but I don't. Lack of Tail Call Optimization is a huge red mark for me, personally.
Ruby, on the other hand, is literally meant to delight you with its choices/options/expressiveness and I find that it absolutely delivers on that promise.
Python is entirely unreadable to me. Not in the sense that I can't but in the sense that I have to put effort into it in a way I don't have to with Ruby. Part of it is undoubtedly that I'm very picky about syntax and formatting and Python has made a lot of choices that are pretty much the opposite of what I want, but I just can't get used to reading Python code.
Even if you would rate the languages themselves equal to one another. The ecosystem of Python is several orders of magnitude larger. Anything you want to do has a python module or an example. I think the real question is, is it really worth giving up all that for two minor improvements in syntax.
As a Rails dev it's extremely rare for me to need some functionality that Ruby doesn't cover. If you're doing standard web development most likely you're gonna be fine with Ruby. I've been doing this with Ruby for around 8 years so I bumped into quite a few use cases...there are gems for all the standard things.
But yes outside web - data science, web crawlers etc...Python has the clear advantage.
i write python for a living (and have done so for the last five years) but i still find ruby fits my brain better, and it's what i reach for when i want to write a quick script for some personal use.
I'm having a blast nowadays with Laravel. After many years of building microservices and SPAs, I just can't believe how easy and refreshing everything is coming back to a "monolith". Yes, there's some spaghetti some times on certains parts, but I can just refactor stuff, create a PR, and easily improve the situation for me and my coworkers.
At my previous company you could only "touch" your own service, so once there was any kind of "architecture spaghetti"... good luck fixing that across 3 ~ 4 different services... and good luck aligning 3 ~ 4 teams priorities to fix it.
That said if you're in Ruby land and do want something "shiny", I'd encourage you to look at Jeremy Evans work (Roda and Sequel in particular) and some of the broader ecosystem beyond Rails. There's a lot of good stuff beyond just Rails :)
I no longer write Ruby professionally but in my last 18-24 months of Ruby work I leaned heavily on some of Jeremy's excellent work with roda, sequel, and others (forme, erubi, rack-unreloader, etc.). Top notch work, truly. I had no idea that he had written a book, thanks for pointing that out, and I'll definitely be picking a copy up.
A coworker of mine is leaving for a Ruby job, which caught me off guard, so I've had Ruby on the brain a bit lately. I was a big fan of Ruby for a few years back in 2004-2006 or thereabouts. Rails was the new hot thing, but I wasn't into web dev so I didn't pay all that much attention to it. I remember blindsiding my networking professor by using Ruby for an assignment when he expected but failed to specify Java or C ... he was a good sport, thankfully.
I strayed from the CS path into econometrics and then data science, so Ruby just wasn't a good fit for basically anything I do. That seems to remain the case, unfortunately, though I like it on the language level more than my bread and butter Python. Oh well.
I used Ruby for my MSc thesis... which involved applying statistical approaches to reduce error rates in OCR. I did have to call out to C code for a few things (k-means in Ruby 1.8.x was not fast...).
Most of my Ruby work has been outside of web. Message brokers, cloud orchestration and assorted devops, a text editor (for my own use - it's replaced Emacs for me), financial simulations. And that means the majority of my work for the last 15 years.
Ruby has gotten more low key, but for those of us who never really liked Rails that's not really mattered much.
One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.
> My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.
God, yes. Especially with Hotwire [1], which advertises being able to do modern web apps with a minimum of JS. I've played around with it, and for me it completely eliminates the need for AngularJS/React/whatever.
The Async gem and Ruby 3+ is an incredible piece of work. If you need to coordinate 3rd party services, it's the way to go in ruby and it just reads beautifully.
I don't know about miserable, but definitely easier to get side tracked deciding what libs to use. Rails tends to push users down a path that works for most things. This makes it much easier for new users. JS leaves it up to the developer to pick and choose what libs which is not new user friendly.
Strait up, use Rails with all the defaults (ImportMap, Hotwire) but use Postgres and maybe Tailwind (`rails new myapp --database=postgresql --css=tailwind`). No extra gems are needed really (if anything, they add more complexity as not all are updated to be compatible with Rails 7).
Rails and Django are both very pleasant and have enormous ecosystems where every imaginable problem has been encountered and "solved". It's been a while since i was writing Rails but from what I gather Rails 7 is a homerun release and has a lot of buzz around it.
Regarding Django, my problem with it is that it is not a "full stack" framework anymore. Both Rails and Laravel provide a very good frontend solution. Rails with hotwire, etc and Laravel with livewire. Just the fact that django has no official way to compile/build assets, and the templating language is really arcane and limited for today's needs. Just compare that with Blade (Laravel's templates) which allow you to build components out of the box.
ruby and rails is a much nicer, more complete, more consistent, and easier to learn ecosystem relative to js/node. and node is just the js server, so you need need a framework on top of it, like react/angular/vue/ember, to be equivalent. for most use cases, i really can't recommend the js-heavy route now that rails comes with hotwire (a transparent js framework for live/async html transfer, rather than json).
for authentication/authorization/security, it's great to learn by writing those from scratch, but unless you want that to be your career focus, you'd really be much better off to defer to battle-hardened libraries in those areas for any commercially-/publicly-oriented web app.
Rails is quite pleasant. There is a reason it became so popular.
I’d recommend using rails without any front-end framework initially so you understand the HTTP calls going on. Just return HTML from your controllers (classes that run specific code when you hit an endpoint.) Build up from there and you’ll get the hang of it while understanding what’s happening underneath.
Definitely consider Python with FastAPI too. I got a simple API up and running in a few hours with OAuth2. Auth comes batteries included and wasn't nearly as complex as I feared.
When you learn Rails, you mostly just learn Rails. If you want to learn the nitty gritty details I think a different language might be better suited. I think Go strikes a nice balance between "doing everything yourself" and "just putting pieces together" If you constrain yourself to the standard library.
I'm a Rails dev at $JOB, currently flirting with Phoenix, and while I think that both Elixir and Phoenix are really solid and even quite enchanting, I don't think they're the best choice for someone's first contact with webdev. Most people are more comfortable with imperative languages and Elixir only adds to the initial friction of not knowing the proper webdev lingo and concepts.
> Most people are more comfortable with imperative languages
Unscientific poll with possibly a biased sample: more people find functional easier to work with. But telling, the difference is more pronounced among bootcampers and informally educated programmers than formally educated programmers https://twitter.com/DNAutics/status/1459348334007787526.
Not to mention that Elixir is basically "mostly functional but you don't have to faff around with monads or anything to do imperative".
Language elegance is not the reason Node is chosen over Ruby. Async and performance is. If I want my app to call a couple of services without using a ton of memory Node is the better option.
Having tried both Node and Rails, Rails was a horrible experience. I hated every minute of it and will ignore any job listings including it. Your whole project is in a billion files and everything works by "magic." There is so much complexity and different flies that it sucks to work with. Meanwhile with Node you can start with a simple index.js and work your way up.
When you create a project it makes like 100 files that are all automatically executed somehow. Nothing really includes them, but you know it works. These files arp part of your project, but they is also a bunch of rails stuff so it blurs what is and isn't a dependency for your project.
With node projects they typically keep all of their dependency neatly under node_modules/ and you can clearly see how things are included and how things work.
I hear your point but the quantity of files produced by initializing a new rails project is very large, larger than an equivalent node project with server and framework. These aren't transient build artifacts either, they will live in the repo and may occasionally need attention.
FWIW It seems to me your comment about Rails is a more general comment re: frameworks.
Learning a language/runtime takes some effort but much less, IMHO, than learning a framework. Doesn't matter if that is Rails, Django, Ember, Angular, iOS SDK, Android SDK, React+Redux+???, and so on.
I don't think so out of your list I've used the Android SDK along with a react and redux stack and I didn't get the name kind of feeling. With those you start out with a mainly clean project and everything makes more sense to me how it works.
I never said it was quick or easy. It just makes more intuitive sense in how it works. Rails has a lot of "invisible" that is stored in libraries which obscrues how it works.
I love Ruby - Rails has been my day job for the past decade and my life is so much more pleasant when working with it than the odd time I've ventured off into things like Go or Java.
For personal things, my bread and butter is Sinatra and Sequel and that's a great combo as well.
My only real issue with it is differences in building native extensions on macos vs linux, usually need to set different compiler flags in the bundle config. Otherwise, works great.
I'm curious, do you know what function was being declared implicitly? That's really atypical in modern C code, so there's probably a missing #include somewhere that could be fixed upstream.
We're on an older version of Ruby so that's the most likely reason. MacOS Monterrey is really new and we deploy to RHEL so the differences in versions can be fairly stark.
So what's the upside for you with Sinatra? I'm embarrassed to having been doing Ruby for 8 years and never touching it. Just never saw the need - Rails in API mode seems adequate.
Sinatra is small (the main part is about 2k lines). That's the main upside and/or downside depending on your philosophy. As someone who likes to know what goes on, I love Sinatra, but Sinatra does force you to pull in other code as needed yourself - you don't get handheld the way you do with Rails.
If you need the kitchen-sink you might as well use Rails. But often you might need only a tiny fraction, and Sinatra is small enough to read. If you need a "halfway house" between Sinatra and Rails, Padrino layers nicely on top of Sinatra and you can pick and choose which parts of Padrino you want to use.
My preferred stack is Sinatra + Sequel as the ORM, but if I need something "quick and dirty" I might throw Padrino on top as it's lightweight and unopinionated enough it doesn't get in my face the way Rails does.
The caveat is that if your team is used to Rails chances are they'll hate you if you make them use Sinatra and they don't share a dislike for big frameworks.
Sinatra and the Camping microframework were an enormous help for me when I first started learning Ruby. Being able to read a minimal implementation of routing (for example) helped dispel a lot of the magic that I got hung up on in Rails.
I am a newbie to Ruby. I hadn't touched it before a few months ago, after coming to Shopify. But I really think Ruby is a fantastic language, I would much rather program in Ruby than in Python, JS or Java right now. It reminds me of small talk and is just nice to write. And Rails, wow Rails is such a good web framework, there's no surprises, and its opinionated nature makes it really easy to come up to speed in even a big code base.
Tech trends are weird, and the "hot new thing" is usually based off of some blog post or tech company saying its cool. Plus with things like TruffleRuby and Sorbet and JITs, there's some interesting development in the ecosystem.
That's not a coincidence. Ruby is heavily Smalltalk-inspired syntax with a dash of Perl and Awk thrown in (notice all the "$"+single character bits, as well as a look at the "-n" command line) wrapped in nicer syntax.
> For I once again have trouble installing Nokogiri.
One could consider https://rubygems.org/gems/oga, as it doesn't have any installation problems. It's not actively maintained though (mostly because the author considers it to be complete). I do think the author is a bit of a weirdo though :)
Started a new job in the past year and it's 50% rails, 50% react. Thought I would chafe after returning to ruby after ten years of nothing but JS and TS, but I quite like it.
I only wish there was slightly less magic and a bit more declaration. It always weirds me out that Ruby just finds stuff without me having to 'import' or 'require' it. I have a love/hate relationship with much of the DSL stuff too (more 'magic') but overall, working with Rails and Ruby is quite nice.
> Ruby just finds stuff without me having to 'import' or 'require' it.
That's either bundler (which `require`s every dependency you specify unless you tell it not to) or the Rails autoloader[1] (which goes hunting for a file that might define the constant, which also allows hot-reloading to work). Ruby itself requires you to `require` everything.
Here's my hot take on Ruby (as a big Ruby fan): Ruby libraries in general have bad documentation. Some other languages I've worked with in the same time frame that typically have better docs are node.js/regular js, Python, Golang and Elixir.
For many gems, all you're going to get are a couple of examples in the readme. If you're lucky, there will be some generated rubydocs, but quite often that isn't helpful either, because it's just a list of method names with no descriptions, or it's not clear at all which pieces are intended to be the public API. Even Rails has this problem sometimes. The guides are very good, but when I need to do something off that beaten path, I'm often reaching for stackoverflow.
My favorite documentation trick for ruby is to run your own doc server locally documenting the versions of the gems you are using. I use the "yard" gem.
yard server --gems --reload
For rails and ruby docs, I use Dash (on Mac). I use Dash for local docs for other languages and systems as well. Just a handy tool for local docs.
> Here's my hot take on Ruby (as a big Ruby fan): Ruby libraries in general have bad documentation. Some other languages I've worked with in the same time frame that typically have better docs are node.js/regular js, Python, Golang and Elixir.
JS libraries, IME, are often very bad, though there are some good ones. But, on Ruby, I would go further and say that, especially compared to Python which is so similar in many other respects, Ruby (and not just the library ecosystem,) has a very bad documentation culture.
In fact, more than in libraries, this is evident in the first-party documentation available on the language homepage.
OpenCV has wheels built for all common platforms so it should be fine now. If your platform or python version is too new/old/unsupported then yeah, you can forget about building it and use another platform/python version.
To be honest, it's always this dice roll with most things on pypi. If there are wheels for you, golden. If not, you better hope it's a pure python package or it doesn't pull any outside libs. Things are getting better though with solutions like cibuildwheel.
I constantly fear Spring Boot magically reconfiguring itself based on what it finds in the classpath, and half the codebase being annotations and import statements.
I've found the metaprogramming in Ruby much easier to understand and teach than Java's reflection and annotation processing.
I really gave Spring Boot a shot, it's just way above my head. Never felt like I had a good sense of knowing what the heck was going on what with all the Beans and annotations. But my Java was pretty poor - that could be the reason.
However I never had this difficulty with Rails/Django/Node, they all felt pretty intuitive to me.
I've lost countless hours to "works on my machine but not coworkers" which turned out to be issues compiling nokogiri with native extensions. It broke all the time between macOS updates. Vagrant / docker were a godsend to removing that element of uncertainty.
Coming from Scala and Kotlin I don't find working with Ruby extremely productive.
The IDEs have partial autocompletion but obviously not as good as with compiled languages. Same for finding where a method is used or how to refactor code without breaking the world.
Those are all IDEs features that made me more productive, made my codebase more robust and helped me refactoring often fearlessly.
Sorbet is a good attempt to fix some of that, but it then adds a lot of verbosity and it is difficult to use in practice since is not adopted by all the ecosystem and when relying on third parties you'll find yourself doing a lot of T.cast, T.unfase, T.must
That said I can see a lot of value in Ruby: concise code, powerful iterators, very expressive and very flexible. Perhaps so flexible that it gives you many ways to shoot yourself
Managing different projects with different Ruby versions with rbenv has been the bane of my existence the past couple weeks. Why isn’t this experience fleshed out better by now?
rbenv also automatically swaps versions based on .ruby-version files. I believe it accomplishes this by wrapping the ruby binary with a script that checks your project directory; it doesn't touch cd.
Also you can short circuit a lot of what you said with Crystal lang (for speed) or Ruby on Jets (for ease of deployment, serverless, etc). At Arist (YC S20), we were able to fully rebuild our app in Ruby on Jets, pass a pen test, get SOC 2 compliance, all in under 12 months. This frankly would have taken years if we couldn't lean on the Rails ecosystem, and our Appdex score is 0.999 typically, and we are prepared to 10-20x our current traffic because everything is serverless and each endpoint in each controller automatically becomes its own lambda upon deployment. Yet we can lean on the usual rails app structure, and use gems and features designed for rails.
With things like Go, basic string operations like reverse string are left to the user to implement. In the ruby/rails ecosystem we have Active Support. To that same point, you also get the most fully featured ORM in the world in the form of ActiveRecord. No other ORM comes even close to the features AR provides.
To your point though, we do use Rust for image and gif processing in one small lambda. I love Rust, but there simply isn't a web framework with the "sane defaults, everything included by default" mentality of rails yet. Cookie management, CSRF protection, etc., are largely left to the programmer to configure correctly, and it's simply a waste of time if you are trying to iterate quickly as a startup.
Thank you. I sometime read that too much "magic" and abstractions can quickly get in the way when doing something complicated that is not covered by a heavely opinionated framework. Is this nonsense in your estimation, or is this something to look out for?
This is very true if you don't actually understand and/or couldn't implement the magic yourself. As someone who has had to implement CSRF protection, cookie management, etc., from scratch in other languages/frameworks, it's just a pure productivity boost when I use something rails-based.
Where you can really get into trouble is if you take rails things for granted, and then go to a framework in another language. For example, you could have been brought up on rails and just take for granted that cookies are encrypted by default, and not realize that your supposedly server side cookie secrets stuff in express is being set in plain text.
What I like about rails, though, is it tries really hard to stop you from doing something stupid. Strong Params is a great example of that. You have to really fight ActionController to get it to do something actually unsafe. By that same token, properly configured rubocop will catch 100% of potential SQL injection vulnerabilities.
I recently interviewed for a ruby/rails job where the dev team had come from a previous start up that tried to port an existing Rails app to a React/Microservices one with disastrous results. For this job they were relishing coming back to a monolithic Rails app. I hope this trend continues!