4 ms·
If you ignore performance and mathematical elegance and safety and just look at how much a language lets you get away with from a productivity standpoint, I thi
by adverbly 11mo ago
If you ignore performance and mathematical elegance and safety and just look at how much a language lets you get away with from a productivity standpoint, I think Ruby is a pretty standout winner and nobody else even comes close really...
Very clear APIs and syntax(with the possible exception of blocks which can be weird because they aren't quite functions), and tons of raw metaprogramming powers.
You can argue it sacrifices too much of the other things to deliver on these things, but it's hard to argue against it doing well at what it optimizes for!
- jnovek 11mo agoI love writing Ruby. It’s one of the most pleasant and elegant languages I’ve used… but the footguns it comes equipped with rival those of Perl.
- ajoski9 11mo agoAgreed. Also pretty to look at IMHO
- IshKebab 11mo agoBut awful to navigate - the terse syntax combined with lack of static types and regular use of generated identifiers turns large codebases into Where's Wally. Good luck finding where the `process` function is called from. You can't even search for `process(` like you can in most languages.
- 15155 11mo agoYou can search for "def process" - it's inheritance and metaprogramming that make finding the underlying implementation difficult.
- Someone 11mo ago>> Good luck finding where the `process` function is called from. You can't even search for `process(` like you can in most languages. > You can search for "def process" That tells you where it is defined, not where it is called from.
- 15155 11mo agoTrue. `caller` tells you where it is called from, during runtime.
- speleding 11mo agoWell, just add "puts caller" in the function to find out. You can do this in your own code, but also you can also just briefly patch the library you're working with, if that's where the process is. By the way, the generated identifiers are more a rails thing than a ruby thing.
- IshKebab 11mo agoDoesn't that just tell you the functions that happen to call it when you run a program? That's not remotely as good as just getting a complete list at the click of a button.
- lloeki 11mo ago> lack of static types RBS is a thing; we use it extensively. > Good luck finding where the `process` function is called from I don't use it like that but I seem to recall RBS itself has a query mechanism and can answer these kind of questions.
- IshKebab 11mo ago> we use it extensively Who is "we"? The Ruby projects I use are Asciidoctor and Gitlab and neither of them use it. Also putting types in a totally separate file is an abysmal UX.
- lloeki 11mo ago> Who is "we"? $dayjob; does it really matter who as long as it's an example of it being useful to someone? > putting types in a totally separate file is an abysmal UX. Is it though? I much prefer def frobz(fizbazbang) # ... the code to def frobz(Hash<Symbol | String | Integer, Array<String | Integer>> fizbazbang) -> Array<Hash<String | Integer, String>> fizbazbang # ... the code It's the job of the code editor to get that information surfaced to me at the proper place (e.g virtual content like vim inlay hints, hover tooltips, those vscode embeds or whatever they are called). If I need to jump quickly I have projections† set up. Having the types inline isn't that useful anyway as it gives yo only the signature but gives you no info of whatever type intermediate things are without much thinking. And interesting things happen when you have separate `.rbs` files: I started to develop some things type first then progressively fill the implementation in. † Well known because of https://github.com/tpope/vim-projectionist https://github.com/tpope/vim-projectionist but projections are not limited to vim.
- tenacious_tuna 11mo ago> I love writing Ruby I work at an enterprise running Rails (you've heard of us, if you're in North America). Discussions about rails abound, and my opinion has distilled into "I love writing Ruby, I loathe reading it"
- asa400 11mo agoSame! I had a job at a shop with a monolithic Rails app where I had so much trouble understanding the codebase I almost quit the industry entirely. Maybe I am just stupid when it comes to reading Ruby/Rails or maybe that codebase was uniquely awful, but it was ~impossible to figure out where things were defined or how data moved through the system. A huge ball of mutable state that was defined at runtime. When people say "I love writing Ruby" what I hear is "I love writing greenfield Ruby". Everybody loves writing greenfield code! The difference between greenfield and brownfield Ruby is stark, in my experience. And to be clear I do not hate Ruby. It got me into the industry, it taught me a lot, it just optimizes for a set of values that I don't happen to share anymore, which is fine.
- tenacious_tuna 11mo agoA lot of Ruby's syntax lends itself towards cramming as much business logic on the screen as it can. I used to say it's a "semantically dense" language, but I don't actually know if that's technically accurate. Compared to Java or Rust I certainly felt like Ruby fit more "logic" into a screenful of code, but at the cost of any other context (type annotations, import notes, etc) I strongly appreciate how much decision fatigue Rails avoids by just offering you so much batteries-included stuff. I tried getting into Django and immediately spun out fretting over what ORM or migration manager or caching system to use. (One of my coworkers who is a huge Django says I'm nuts and that Django offers those things too, so I may be misremembering.) Rails being as opinionated as it is saves so much thinking effort along those lines. I think both of those facets make it extremely appealing to, as you say, anyone greenfielding code, and are the exact things that make it an absolute trash fire to maintain anything of appreciable size. We're constantly fielding incidents due to something being undefined or unexpected nils or other basic typecheck failures. > it just optimizes for a set of values that I don't happen to share anymore That is a lovely way to put it, I'm gonna steal that
- fhars 11mo agoDoes Base https://github.com/garybernhardt/base https://github.com/garybernhardt/base still work with current versions?
- jimbokun 11mo agoVarious Lisps can give it a run for its money, depending on the problem. Metaprogramming is Lisp's canonical super power. Ruby is going to win out on tasks where it has built in syntax, like matching regular expressions. But once you get to metaprogramming Lisp macros are going to give Ruby a run for its money. I will say one of the under appreciated aspects of Ruby is the consistency of its semantics, where everything is message passing very much like Smalltalk.
- tombert 11mo agoI am extremely partial to Scheme’s `define-syntax` construct. I remember the first I saw it, I thought it was one of the elegant and amazing things I had ever seen in a programming language, and I kind of got annoyed that it wasn’t something easily available in every language. I love me some Clojure, and its macros aren’t bad or anything, but I feel Scheme (and Racket) has the most elegant metaprogramming.
- shevy-java 11mo agoRight. But ruby also has awful crap. The documentation - look at opal, webassembly and many other projects in ruby. The documentation is just total garbage. rubygems.org also has decided to, rather than fix on existing problems, eliminate all former maintainers and instead put in Hiroshi Shibata as the solo lead - the same guy who keeps on writing on different github issue trackers how he does not have time to handle any issue requests for low-used projects. Wowsers.
- chihuahua 11mo ago"If you ignore performance and safety..." Other than that, how was the play, Mrs. Lincoln? Also, add readability and maintainability to that list, and scaling to a large codebase. And good debugger support.
- ramon156 11mo agoWhat about PHP/Symfony? I have more experience in that and, after trying rails out this week, so much was overlapping.
- tartakynov 11mo agoLet's be honest, when you're starting a startup, Ruby's performance won't be a bottleneck until much later, when you're successful and get tons of usage - at that point you can afford to hire someone to fix it. Your productivity will be a bottleneck from the very beginning. Pieter Levels writes his startups in PHP and hasn't had a performance bottleneck so far. For most applications, the performance of the language won't be an issue. I personally wouldn't pick PHP for any of my own projects, but Ruby I'd pick any day.
- tliltocatl 11mo ago> at that point you can afford to hire someone to fix it That's the reason why we can't have nice things.
- bjclark 11mo agoRuby’s performance has not been a bottleneck for multiple companies that have IPO’d and are worth billions of dollars.
- wutwutwat 11mo ago> if you ignore performance man, people are still parroting decade old, incorrect talking points I see. Is ruby as performant as C, probably not, although, actually, in some cases, it outperforms C -> https://railsatscale.com/2023-08-29-ruby-outperforms-c/ https://railsatscale.com/2023-08-29-ruby-outperforms-c/ One of the largest ecommerce apps in the world runs ruby, shopify. Ruby now has a JIT, there has been insane effort put into making ruby faster.
- aw1621107 11mo ago> actually, in some cases, it outperforms C -> https://railsatscale.com/2023-08-29-ruby-outperforms-c/ https://railsatscale.com/2023-08-29-ruby-outperforms-c/ Bit of a clarification after reading the article - that article demonstrates a pure-Ruby implementation [0] outperforming a C extension [1], which is not what I had originally expected when first clicking on the link. [0]: https://github.com/tenderlove/tinygql https://github.com/tenderlove/tinygql [1]: https://github.com/rmosolgo/graphql-ruby/tree/master/graphql-c_parser https://github.com/rmosolgo/graphql-ruby/tree/master/graphql...