15 ms·

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. In other languages, things don’t flow like that. I’ve tried purely function languages and I just can’t wrap my head around them because they abstract too much. I’ve tried python, but I end up having to deal with the mess of importing modules and having to set up loops when all I want to do is map data. Node.js comes so close but anemic standard library and absolute mess of explicit async everywhere just gets in the way. I want to love JavaScript. :( Then there is Rails. Nothing even comes close. The attempts to replicate it in other languages ends up missing part of what makes it so great. I’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap. My entire career has been in Ruby on Rails. I hope improvements to Ruby can keep it relevant. If not, I suppose JavaScript will do.

mehphp 5y ago
I just left a rails gig to go back to django. I like ruby ok but not a big fan of rails. I totally see the value and understand why someone would like it but I just never could get to that point with it. I much prefer the explicit imports, loops, etc I suppose
- chespinoza 5y ago
  That's interesting, what you think Django excels that Rails doesn't? Which ones were the pain points in your opinion?
  - mehphp 5y ago
    I think it’s just preference really. I don’t think Django is better I just prefer some of it’s choices. For example, I really don’t like that rails implicitly imports stuff into the namespace. I like being able to follow the imports explicitly at the top of the file. I feel like there is way less of “where does this come from or what IS this?” when working with Django.
  - t-writescode 5y ago
    Autoloading is a major source of pain in Ruby, I think. What function did I import, exactly? Which of the 37 “update” calls did I call when I called it on this?
pull_my_finger 5y ago
>Node.js comes so close but anemic standard library The nodejs API is rather big really. If you're using Ruby as your standard of normal sized almost everything would look small in comparison, but "anemic" is a stretch. You'd really hate Lua. If you're taking suggestions, you might enjoy Janet[1]. It has a pretty large user API, lots of bells and whistles included in the standard libs like you'd find in Ruby, and lots of different ways to achieve the same result like Ruby. It's been a while since I checked out the ecosystem, but I was _very_ happy with the Joy Framework[2]. It definitely doesn't come close to the scope of Rails, but I think it _does_ near Rails in it's easy of use for the developer with it's scaffolding, controller generation etc. [1]: https://janet-lang.org/ https://janet-lang.org/ [2]: https://github.com/joy-framework/joy https://github.com/joy-framework/joy
- kayodelycaon 5y ago
  Funny you should mention Lua. It’s a fun little language I very much enjoy. Lua isn’t typically used for business applications with heavy logic and a lot of data manipulation.
- chespinoza 5y ago
  >If you're taking suggestions, you might enjoy Janet[1]. Just curious about why you'd suggest going from a popular stack to Janet? I'd rather suggest Common Lisp as it's a way more stable, mature and standardized technology.
Buttons840 5y ago
> I’ve tried python, but I end up having to deal with the mess of importing modules Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called? If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both solved problems, no matter what language you're using. If you're not using an IDE, that's a more interesting situation, and without an IDE I much prefer having the explicit imports so that I at least know where to start digging.
- prescriptivist 5y ago
  Those are fair points, but I just kind of hold the entire program space in my head. I work on a pretty large and complicated Rails app that does real world things (handle money, deal with people and companies, etc) and it's daunting at first but after a while it's sort of become one big system of objects interacting with other objects in a global objectspace and that's how it exists in my head. I think for people that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.
  - prescriptivist 5y ago
    Which isn't to say lexical scope isn't important in a ruby program -- it's paramount, especially for resolving constants -- it's just that after a while it's not that big of a deal that there is some ambiguity about where things come from. For me it's one of the most intuitive languages I've ever worked with but it requires a sense of intuition that is learned over time, as contradictory as that sounds.
    - regularfry 5y ago
      It also requires a certain sense of confidence that whoever named that method you're calling gave it a good name. Fortunately (and not, I think, coincidentally) the ruby community has always tended towards good naming being really important.
scrose 5y ago
> I’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap. You might like some of the recent Rails 7 previews. I believe they’re removing Webpack out of the box and trying to simplify things on that end[0]. [0] https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-released/ https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-r...
- clairity 5y ago
  to me, this is what makes the upcoming rails 7 release really exciting: no more node, npm, webpack, & yarn! all that js tooling complexity thrown right out the window, replaced with the much simpler set of es6 modules, turbo & stimulus (and maybe strada too).
  - Lio 5y ago
    There seem to a lot of ruby pieces falling into place for Rails 7. The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that. That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now. 1. https://github.com/socketry/falcon https://github.com/socketry/falcon 2. https://github.com/github/view_component https://github.com/github/view_component
    - clairity 5y ago
      yes, websocket connections/memory use was a problem, will have to take a look at falcon. i'm personally not a fan of tailwind (or bootstrap) for being overly/cryptically verbose, but i understand why it's popular when coupled with view components, which do seem useful.
davidlee1435 5y ago
I quite like Kotlin when it comes to a language's "flow." Pity there's not a better web server framework for it
- stepbeek 5y ago
  We've been building on top of Spring Boot with nodejs as a part of the build process for front-end assets. It's not as nice as rails, but we love kotlin so it's hard to give up.
fn1 5y ago
> Just about every array operation I could want is there, waiting for a code block. In other languages, things don’t flow like that. This is a question about standard-library. The standard-library of kotlin is equally amazing (but Kotlin more or less requires the IntelliJ eco-system of course).
jb3689 5y ago
> Then there is Rails. Nothing even comes close Have you tried Phoenix? It's really close. It's better in some ways. The data layer is quite different however. As much as I like Ruby, Elixir made a lot of things I liked about Ruby better
- joelbluminator 5y ago
  Are you happy with the way things are going for Elixir? It seemed to me like the Elixir community was hoping for it to become the next Ruby and I don't see that happening anymore. It will have to settle for being a well respected but obscure piece of tech, kinda like what Erlang is.
  - jjdeveloper 5y ago
    I see Elixir pulling in a lot of people in with Liveview, especially those in the node/react world who are getting tired of the churn and build complexities.
  - cpursley 5y ago
    Elixir and Phoneix are more popular than ever, especially with the release of LiveView. The ecosystem and community continues to absorb refugees from Ruby and other stacks. It's such a better platform than Ruby and Rails that I won't bother writing about it here - there are already hundreds of blog posts about it. Productivity is at least on par with Ruby (I believe better) and performance on another plane of existence.
    - joelbluminator 5y ago
      Sorry that really doesn't add up to what I see when I look at job boards, Elixir has really poor numbers. The Ruby guys who wanted to jump ship to Elixir already did so a few years ago (some of them will continue to jump ship from Elixir to Rust or Go because hey why not). So I don't know where new growth will come to Elixir. It's not just jobs, by any metric you can think of Elixir is an obscure tech, if you want I will add sources to this claim but hopefully we can agree.
karmasimida 5y ago
Bet one entire language's future on a single framework isn't working very well I guess. It is 2021, web frameworks are ... one of the solved problems. Polyglot is the future, and people are already adapting
- joelbluminator 5y ago
  > Polyglot is the future, and people are already adapting Yes, right. I like how you can read into the future. Let's see what happens 10-20 years from now, things tend to change. But even if we look at how things are now, plenty of places still commit to 1-2 languages (in fact if you're a small shop it's pretty crazy to try anything else).
  - regularfry 5y ago
    It depends heavily on the problem you're solving. A few jobs back I was in a small shop and we were all regularly bouncing between Java, C, Ruby, JS, Perl, Python... Go crept in round the edges too. We wouldn't have been able to deliver without the full set just because of what we had to interface with. It's more than doable as long as the culture is "learn the necessary skills".
  - karmasimida 5y ago
    > plenty of places still commit to 1-2 languages That might be true, but it didn't mean they will commit to ONE language for forever. Even governmental agency's code gets rewritten in newer languages eventually: https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-u-s-air-force-mainframe-to-aws/ https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-...
    - joelbluminator 5y ago
      C, Java, Javascript, Ruby, PHP, Python, all these languages are 30-50 years old. I don't see any of them fading away the coming 20 years from now (you might argue about Ruby since it's much smaller, but it has a very strong community keeping it moving). You could bet your career on any of these and I'm pretty sure you will be fine 20 years from now.
shafyy 5y ago
I feel very similarly with Ruby and especially Rails. After working in Rails for multiple years, I'm now doing a freelance gig where the tech stack is React, NodeJS with TypeScript on Firebase Cloud Functions, and it almost sucks out all of the joy of programming. Making software in Rails feels creative, and the act of writing code in itself is very satisfactory. A good opportunity to re-read the Rails Doctrine: https://rubyonrails.org/doctrine https://rubyonrails.org/doctrine Now, I know that this is very subjective and I can see how others might prefer other languages or frameworks, so I'm not adding this here to start a discussion. Just to share my feelings :-)
- chowchowchow 5y ago
  I had this exact realization getting ramped up in a large rails codebase: ruby is optimized for experience of the code author, while most of the things people miss from it (explicit imports, static types) help with code maintenance and codebase scalability. The small/large project distinction makes sense to me. I think there’s a clear point in project size where the joy of writing code has to be deprioritized behind maintainability and simplicity, even if it becomes less fun to write code that way.
  - horsawlarway 5y ago
    It's not a pleasant experience to come on board and deal with a typeless, styleless, inconsistent mess. And that's what Ruby on Rails will create, unless you spend an inordinate amount of effort on adding back all the tooling you need to make functional software in large groups. Even then - there's no real path to a mature and maintainable language/framework. In my area (Atlanta) we're seeing a glut of RoR devs available because a lot of the large employers have given up and shut down the RoRs projects in favor of anything more suitable to teams in the 15 to 500 engineer range. Usually this has been typescript/java/.net. Even within the RoR guys I know - a LOT of them are trying to get out and work with something else (several folks I know are moving to elixir)
    - AlchemistCamp 5y ago
      Elixir is also dynamically typed but due to its pattern matching and immutability, I've found it eliminates about 90% of the issues that I've found with dynamic typing in other languages. It's still got most of what made Ruby a joy to work with and several unique advantages, too!
louissm_it 5y ago
You nailed it. I work with Ruby, TypeScript (React, Node) and Elixir. While Elixir has more than enough uses and I love it dearly, nothing comes close to the productivity and expressiveness of Ruby (+ Rails). I have very high hopes for JS/TS. Using a single isomorphic language for web development must have some benefits, but I'm afraid it's not there yet.
helloguillecl 5y ago
I got sucked into React, graphQL and Nodejs and and always missed Rails, with all the hype I never thought that the environment would be so far behind. It's all my fault. But now that Rails has incorporated Stimulus as a sane approach to the client-side of things, I'm coming back and it will be difficult to take me away again.
bamboozled 5y ago
I like your honesty. I’ve bounced around over the years and I’m doing a lot of Python now. It’s funny You said that about “loops” because I do feel like I’m always looping something in Python ha
dudeinjapan 5y ago
> I’ve tried python, but I end up having to deal with the mess of importing modules It's funny, the fact that Ruby doesn't have a facility to import modules is one of my biggest gripes with it. Instead of importing into a specific scope, the global namespace becomes a dumping ground for anything that has ever been loaded, and you need something like Zeitwerk to do auto-loading for you. Which I guess can be seen as a convenience initially, but it makes things harder to manage as your app grows in complexity.
- regularfry 5y ago
  I have mixed feelings about autoloading. I never use it for my own stuff, ever: explicit `require`s all the way. But I do appreciate not needing the boilerplate in Rails. It would have been nice to be able to do something like: `MyActiveRecordImport = require('activerecord')` to take control of the constant name, but honestly it's not something I hugely miss.
MrWiffles 5y ago
> [...] I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that sweet spot of great productivity that is a direct result of a fantastic developer experience created through a programming language that just "flows" linguistically so much easier than...well, everything else I've personally ever seen (with Python being an arguable tie there). My biggest gripes about Ruby and its ecosystem have been the pain in the posterior it is to deploy apps (all those gems, which eventually wind up abandonware and now you've got dependency hell, especially with apps not maintained in 5 years or something) and its relative sluggishness when compared against some other deployable artifacts. Personally, I think Crystal (https://crystal-lang.org/ https://crystal-lang.org/) fixes pretty much all of this, as long as you're willing to cede a few things due to the nature of the beast (compiled vs. interpreted). And that's not considering the speed improvements Ruby's gained in the last few years (3x3); it's undoubtedly far better now than when I last released an app with Ruby or Rails (circa ~2016, maybe ~2017ish). I'm just so disappointed that everything's "JavaScript this" or "Go(lang) that". Not that I have a problem with Go (I do have many problems with JavaScript, which I strongly dislike, but that's a separate topic), it's just that this industry acts like lemmings in a lot of cases. "New shiny!" attracts the horde, and that critical mass creates a new tyranny of being the "snowflake" technology/stack/developer, which has a lot of risks for both the organization paying for what you build in tech stack $X (rare language, can I replace this hire later, can I find somebody that knows $X, lower risk if we use $Y b/c we can find plentiful/cheap talent in $Y or $Y salaries are lower than $X), and by that token therefore it's a risk to the developer's career to get hard core on anything perceived as "snowflake" or otherwise not "flavor of the $(month || year || interval)". Which is just so sad, and I feel like it's a contributing factor in Ruby's decline (in terms of hiring demand for full time positions). It's not at all the technology's fault, and it's not a performance "issue" whatsoever anymore (really wasn't in the first place unless you were nickel and diming literally everything or did stuff just plain stupid). Go, Rust and friends all have their own benefits and drawbacks too, and they're fine languages with their own killer features and/or quirks. They can produce pre-compiled code for a variety of platforms from a single machine, resulting in (if desired) a single file binary deployable artifact that can be installed and simply run, no dependencies to install, no OS configuration necessary. Ruby, without lots of hacks potentially questionable hacks and potential future abandonware, doesn't do that at all AFAIK, but Crystal can also produce fat binaries just like Go can (and I assume Rust can too), making it the best of both worlds in my opinion. Crystal: compile Ruby-like code to a "fat" binary for single file, zero-config/dependency deployment that runs true multithreaded apps as native code. And most of those tradeoffs you'd have to give up because "compiled" - most of those you can work around pretty easily and I've heard you can even have it embed source code in the binary to be run in interpreted mode at runtime, so you can have your app compiled for the vast majority of use cases, then have it run its own code inside itself interpreted/JIT'd when run, giving you access to many (all?) of the features you'd otherwise think you'd have to sacrifice. So yeah, I love Ruby, and I think Crystal is definitely the next evolutionary step for that language and ecosystem. No hate on Ruby there whatsoever, I just see it as a more mature option for a lot of use cases, but definitely not all. I don't know if you can do that metaprogramming magic Ruby is so amazing at any faster in Crystal since you'd have to run the code as interpreted at runtime, not pre-compiled (AFAIK), so it's not an outright replacement. Still, I think it's damn near one, and you can probably "color outside the lines" just a tiny bit as needed when you absolutely MUST have that feature anyway. Okay, end stream-of-consciousness. I haven't been able to sleep for 3 days, so rambling is a sort of unavoidable side effect...sorry about that. But yeah, try Crystal if you haven't already, you'll likely be very happily shocked at how amazing it is!
pmarreck 5y ago
> I’ve tried purely function languages and I just can’t wrap my head around them because they abstract too much. Not sure what you mean here specifically (do you not understand Enumerable.inject in the Ruby stdlib? That's about the hardest thing to understand and once you're there, functional langs are pretty trivial) I was already coding in a functional style in Ruby (PORO, intentionally not mutating vars, etc.), so that wasn't an issue for me at least, when I hopped to Elixir. The kicker was when I spent an entire month debugging a problem that would have been impossible to occur in Elixir/Phoenix- I was working on a million-line Rails codebase and there was a session issue where sessions would seemingly randomly get dropped... it was nondeterministic and absolutely maddening, a number of other devs had attempted to fix it and failed, and I finally did- and it ended up being a key-overwrite issue with a regular Hash being merged with a HashWithIndifferentAccess in the ENV variable passed between rack layers (and god, was that hard to find! I had to write custom debugging tools that walked through every Rack layer and deep-diffed the ENV hash, etc.). That was the last straw. So far, Elixir/Phoenix has been fantastic for me at NOT producing "flagging tests", nondeterministic-seeming bugs, etc. Massive productivity boost.
- joelbluminator 5y ago
  Or...you are working on way smaller Elixir projects. Lets see how fun it is to inherit a million line old Elixir project 7 years from now. Or a million line codebase split into 50 services. I am sure you'll be productive as hell cos Elixir!
  - sergiomattei 5y ago
    I sometimes wonder whether your job is to be a full-time dick about Elixir. It's been years of this nonsense. Let it go.
    - deleted 5y ago
      [deleted]
  - pmarreck 5y ago
    :: let me hand-wave a merely possible but not at all guaranteed negative future scenario to argue against a better solution today :: that's basically what you just did. "Electric cars will pollute someday! Just you wait!" >..< Keep in mind that I've worked on small Ruby projects as well, and still prefer Elixir. I'm not gonna suggest that there wouldn't be challenges in that scenario, but it just seems to me so far that they'd be much more manageable given the thoughtful design of Elixir. The biggest problem in my app currently is actually JS/Node dependency hell, not Elixir code... and the JS only makes up a small portion of my app! (I should have never used AdminLTE as a design template...) At least my JS is tested (which was another huge PITA to figure out... simulating a DOM...)

mehphp 5y ago

I just left a rails gig to go back to django. I like ruby ok but not a big fan of rails. I totally see the value and understand why someone would like it but I just never could get to that point with it. I much prefer the explicit imports, loops, etc I suppose

chespinoza 5y ago
That's interesting, what you think Django excels that Rails doesn't? Which ones were the pain points in your opinion?
- mehphp 5y ago
  I think it’s just preference really. I don’t think Django is better I just prefer some of it’s choices. For example, I really don’t like that rails implicitly imports stuff into the namespace. I like being able to follow the imports explicitly at the top of the file. I feel like there is way less of “where does this come from or what IS this?” when working with Django.
- t-writescode 5y ago
  Autoloading is a major source of pain in Ruby, I think. What function did I import, exactly? Which of the 37 “update” calls did I call when I called it on this?

pull_my_finger 5y ago

>Node.js comes so close but anemic standard library The nodejs API is rather big really. If you're using Ruby as your standard of normal sized almost everything would look small in comparison, but "anemic" is a stretch. You'd really hate Lua. If you're taking suggestions, you might enjoy Janet[1]. It has a pretty large user API, lots of bells and whistles included in the standard libs like you'd find in Ruby, and lots of different ways to achieve the same result like Ruby. It's been a while since I checked out the ecosystem, but I was _very_ happy with the Joy Framework[2]. It definitely doesn't come close to the scope of Rails, but I think it _does_ near Rails in it's easy of use for the developer with it's scaffolding, controller generation etc. [1]: https://janet-lang.org/ https://janet-lang.org/ [2]: https://github.com/joy-framework/joy https://github.com/joy-framework/joy

kayodelycaon 5y ago
Funny you should mention Lua. It’s a fun little language I very much enjoy. Lua isn’t typically used for business applications with heavy logic and a lot of data manipulation.
chespinoza 5y ago
>If you're taking suggestions, you might enjoy Janet[1]. Just curious about why you'd suggest going from a popular stack to Janet? I'd rather suggest Common Lisp as it's a way more stable, mature and standardized technology.

Buttons840 5y ago

> I’ve tried python, but I end up having to deal with the mess of importing modules Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called? If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both solved problems, no matter what language you're using. If you're not using an IDE, that's a more interesting situation, and without an IDE I much prefer having the explicit imports so that I at least know where to start digging.

prescriptivist 5y ago
Those are fair points, but I just kind of hold the entire program space in my head. I work on a pretty large and complicated Rails app that does real world things (handle money, deal with people and companies, etc) and it's daunting at first but after a while it's sort of become one big system of objects interacting with other objects in a global objectspace and that's how it exists in my head. I think for people that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.
- prescriptivist 5y ago
  Which isn't to say lexical scope isn't important in a ruby program -- it's paramount, especially for resolving constants -- it's just that after a while it's not that big of a deal that there is some ambiguity about where things come from. For me it's one of the most intuitive languages I've ever worked with but it requires a sense of intuition that is learned over time, as contradictory as that sounds.
  - regularfry 5y ago
    It also requires a certain sense of confidence that whoever named that method you're calling gave it a good name. Fortunately (and not, I think, coincidentally) the ruby community has always tended towards good naming being really important.

scrose 5y ago

> I’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap. You might like some of the recent Rails 7 previews. I believe they’re removing Webpack out of the box and trying to simplify things on that end[0]. [0] https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-released/ https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-r...

clairity 5y ago
to me, this is what makes the upcoming rails 7 release really exciting: no more node, npm, webpack, & yarn! all that js tooling complexity thrown right out the window, replaced with the much simpler set of es6 modules, turbo & stimulus (and maybe strada too).
- Lio 5y ago
  There seem to a lot of ruby pieces falling into place for Rails 7. The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that. That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now. 1. https://github.com/socketry/falcon https://github.com/socketry/falcon 2. https://github.com/github/view_component https://github.com/github/view_component
  - clairity 5y ago
    yes, websocket connections/memory use was a problem, will have to take a look at falcon. i'm personally not a fan of tailwind (or bootstrap) for being overly/cryptically verbose, but i understand why it's popular when coupled with view components, which do seem useful.

davidlee1435 5y ago

I quite like Kotlin when it comes to a language's "flow." Pity there's not a better web server framework for it

stepbeek 5y ago
We've been building on top of Spring Boot with nodejs as a part of the build process for front-end assets. It's not as nice as rails, but we love kotlin so it's hard to give up.

fn1 5y ago

> Just about every array operation I could want is there, waiting for a code block. In other languages, things don’t flow like that. This is a question about standard-library. The standard-library of kotlin is equally amazing (but Kotlin more or less requires the IntelliJ eco-system of course).

jb3689 5y ago

> Then there is Rails. Nothing even comes close Have you tried Phoenix? It's really close. It's better in some ways. The data layer is quite different however. As much as I like Ruby, Elixir made a lot of things I liked about Ruby better

joelbluminator 5y ago
Are you happy with the way things are going for Elixir? It seemed to me like the Elixir community was hoping for it to become the next Ruby and I don't see that happening anymore. It will have to settle for being a well respected but obscure piece of tech, kinda like what Erlang is.
- jjdeveloper 5y ago
  I see Elixir pulling in a lot of people in with Liveview, especially those in the node/react world who are getting tired of the churn and build complexities.
- cpursley 5y ago
  Elixir and Phoneix are more popular than ever, especially with the release of LiveView. The ecosystem and community continues to absorb refugees from Ruby and other stacks. It's such a better platform than Ruby and Rails that I won't bother writing about it here - there are already hundreds of blog posts about it. Productivity is at least on par with Ruby (I believe better) and performance on another plane of existence.
  - joelbluminator 5y ago
    Sorry that really doesn't add up to what I see when I look at job boards, Elixir has really poor numbers. The Ruby guys who wanted to jump ship to Elixir already did so a few years ago (some of them will continue to jump ship from Elixir to Rust or Go because hey why not). So I don't know where new growth will come to Elixir. It's not just jobs, by any metric you can think of Elixir is an obscure tech, if you want I will add sources to this claim but hopefully we can agree.

karmasimida 5y ago

Bet one entire language's future on a single framework isn't working very well I guess. It is 2021, web frameworks are ... one of the solved problems. Polyglot is the future, and people are already adapting

joelbluminator 5y ago
> Polyglot is the future, and people are already adapting Yes, right. I like how you can read into the future. Let's see what happens 10-20 years from now, things tend to change. But even if we look at how things are now, plenty of places still commit to 1-2 languages (in fact if you're a small shop it's pretty crazy to try anything else).
- regularfry 5y ago
  It depends heavily on the problem you're solving. A few jobs back I was in a small shop and we were all regularly bouncing between Java, C, Ruby, JS, Perl, Python... Go crept in round the edges too. We wouldn't have been able to deliver without the full set just because of what we had to interface with. It's more than doable as long as the culture is "learn the necessary skills".
- karmasimida 5y ago
  > plenty of places still commit to 1-2 languages That might be true, but it didn't mean they will commit to ONE language for forever. Even governmental agency's code gets rewritten in newer languages eventually: https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-u-s-air-force-mainframe-to-aws/ https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-...
  - joelbluminator 5y ago
    C, Java, Javascript, Ruby, PHP, Python, all these languages are 30-50 years old. I don't see any of them fading away the coming 20 years from now (you might argue about Ruby since it's much smaller, but it has a very strong community keeping it moving). You could bet your career on any of these and I'm pretty sure you will be fine 20 years from now.

shafyy 5y ago

I feel very similarly with Ruby and especially Rails. After working in Rails for multiple years, I'm now doing a freelance gig where the tech stack is React, NodeJS with TypeScript on Firebase Cloud Functions, and it almost sucks out all of the joy of programming. Making software in Rails feels creative, and the act of writing code in itself is very satisfactory. A good opportunity to re-read the Rails Doctrine: https://rubyonrails.org/doctrine https://rubyonrails.org/doctrine Now, I know that this is very subjective and I can see how others might prefer other languages or frameworks, so I'm not adding this here to start a discussion. Just to share my feelings :-)

chowchowchow 5y ago
I had this exact realization getting ramped up in a large rails codebase: ruby is optimized for experience of the code author, while most of the things people miss from it (explicit imports, static types) help with code maintenance and codebase scalability. The small/large project distinction makes sense to me. I think there’s a clear point in project size where the joy of writing code has to be deprioritized behind maintainability and simplicity, even if it becomes less fun to write code that way.
- horsawlarway 5y ago
  It's not a pleasant experience to come on board and deal with a typeless, styleless, inconsistent mess. And that's what Ruby on Rails will create, unless you spend an inordinate amount of effort on adding back all the tooling you need to make functional software in large groups. Even then - there's no real path to a mature and maintainable language/framework. In my area (Atlanta) we're seeing a glut of RoR devs available because a lot of the large employers have given up and shut down the RoRs projects in favor of anything more suitable to teams in the 15 to 500 engineer range. Usually this has been typescript/java/.net. Even within the RoR guys I know - a LOT of them are trying to get out and work with something else (several folks I know are moving to elixir)
  - AlchemistCamp 5y ago
    Elixir is also dynamically typed but due to its pattern matching and immutability, I've found it eliminates about 90% of the issues that I've found with dynamic typing in other languages. It's still got most of what made Ruby a joy to work with and several unique advantages, too!

louissm_it 5y ago

You nailed it. I work with Ruby, TypeScript (React, Node) and Elixir. While Elixir has more than enough uses and I love it dearly, nothing comes close to the productivity and expressiveness of Ruby (+ Rails). I have very high hopes for JS/TS. Using a single isomorphic language for web development must have some benefits, but I'm afraid it's not there yet.

helloguillecl 5y ago

I got sucked into React, graphQL and Nodejs and and always missed Rails, with all the hype I never thought that the environment would be so far behind. It's all my fault. But now that Rails has incorporated Stimulus as a sane approach to the client-side of things, I'm coming back and it will be difficult to take me away again.

bamboozled 5y ago

I like your honesty. I’ve bounced around over the years and I’m doing a lot of Python now. It’s funny You said that about “loops” because I do feel like I’m always looping something in Python ha

dudeinjapan 5y ago

> I’ve tried python, but I end up having to deal with the mess of importing modules It's funny, the fact that Ruby doesn't have a facility to import modules is one of my biggest gripes with it. Instead of importing into a specific scope, the global namespace becomes a dumping ground for anything that has ever been loaded, and you need something like Zeitwerk to do auto-loading for you. Which I guess can be seen as a convenience initially, but it makes things harder to manage as your app grows in complexity.

regularfry 5y ago
I have mixed feelings about autoloading. I never use it for my own stuff, ever: explicit `require`s all the way. But I do appreciate not needing the boilerplate in Rails. It would have been nice to be able to do something like: `MyActiveRecordImport = require('activerecord')` to take control of the constant name, but honestly it's not something I hugely miss.

MrWiffles 5y ago

> [...] I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. Totally agree, 100%. Ruby isn't "perfect", but it's a pleasure to use. As in, I actually want to use it, not just am "ok" or ambivalent about it. I have my nitpicks about Ruby, about Rails and other things just like anyone, but I second your comment that nothing else has been able to match that sweet spot of great productivity that is a direct result of a fantastic developer experience created through a programming language that just "flows" linguistically so much easier than...well, everything else I've personally ever seen (with Python being an arguable tie there). My biggest gripes about Ruby and its ecosystem have been the pain in the posterior it is to deploy apps (all those gems, which eventually wind up abandonware and now you've got dependency hell, especially with apps not maintained in 5 years or something) and its relative sluggishness when compared against some other deployable artifacts. Personally, I think Crystal (https://crystal-lang.org/ https://crystal-lang.org/) fixes pretty much all of this, as long as you're willing to cede a few things due to the nature of the beast (compiled vs. interpreted). And that's not considering the speed improvements Ruby's gained in the last few years (3x3); it's undoubtedly far better now than when I last released an app with Ruby or Rails (circa ~2016, maybe ~2017ish). I'm just so disappointed that everything's "JavaScript this" or "Go(lang) that". Not that I have a problem with Go (I do have many problems with JavaScript, which I strongly dislike, but that's a separate topic), it's just that this industry acts like lemmings in a lot of cases. "New shiny!" attracts the horde, and that critical mass creates a new tyranny of being the "snowflake" technology/stack/developer, which has a lot of risks for both the organization paying for what you build in tech stack $X (rare language, can I replace this hire later, can I find somebody that knows $X, lower risk if we use $Y b/c we can find plentiful/cheap talent in $Y or $Y salaries are lower than $X), and by that token therefore it's a risk to the developer's career to get hard core on anything perceived as "snowflake" or otherwise not "flavor of the $(month || year || interval)". Which is just so sad, and I feel like it's a contributing factor in Ruby's decline (in terms of hiring demand for full time positions). It's not at all the technology's fault, and it's not a performance "issue" whatsoever anymore (really wasn't in the first place unless you were nickel and diming literally everything or did stuff just plain stupid). Go, Rust and friends all have their own benefits and drawbacks too, and they're fine languages with their own killer features and/or quirks. They can produce pre-compiled code for a variety of platforms from a single machine, resulting in (if desired) a single file binary deployable artifact that can be installed and simply run, no dependencies to install, no OS configuration necessary. Ruby, without lots of hacks potentially questionable hacks and potential future abandonware, doesn't do that at all AFAIK, but Crystal can also produce fat binaries just like Go can (and I assume Rust can too), making it the best of both worlds in my opinion. Crystal: compile Ruby-like code to a "fat" binary for single file, zero-config/dependency deployment that runs true multithreaded apps as native code. And most of those tradeoffs you'd have to give up because "compiled" - most of those you can work around pretty easily and I've heard you can even have it embed source code in the binary to be run in interpreted mode at runtime, so you can have your app compiled for the vast majority of use cases, then have it run its own code inside itself interpreted/JIT'd when run, giving you access to many (all?) of the features you'd otherwise think you'd have to sacrifice. So yeah, I love Ruby, and I think Crystal is definitely the next evolutionary step for that language and ecosystem. No hate on Ruby there whatsoever, I just see it as a more mature option for a lot of use cases, but definitely not all. I don't know if you can do that metaprogramming magic Ruby is so amazing at any faster in Crystal since you'd have to run the code as interpreted at runtime, not pre-compiled (AFAIK), so it's not an outright replacement. Still, I think it's damn near one, and you can probably "color outside the lines" just a tiny bit as needed when you absolutely MUST have that feature anyway. Okay, end stream-of-consciousness. I haven't been able to sleep for 3 days, so rambling is a sort of unavoidable side effect...sorry about that. But yeah, try Crystal if you haven't already, you'll likely be very happily shocked at how amazing it is!

pmarreck 5y ago

> I’ve tried purely function languages and I just can’t wrap my head around them because they abstract too much. Not sure what you mean here specifically (do you not understand Enumerable.inject in the Ruby stdlib? That's about the hardest thing to understand and once you're there, functional langs are pretty trivial) I was already coding in a functional style in Ruby (PORO, intentionally not mutating vars, etc.), so that wasn't an issue for me at least, when I hopped to Elixir. The kicker was when I spent an entire month debugging a problem that would have been impossible to occur in Elixir/Phoenix- I was working on a million-line Rails codebase and there was a session issue where sessions would seemingly randomly get dropped... it was nondeterministic and absolutely maddening, a number of other devs had attempted to fix it and failed, and I finally did- and it ended up being a key-overwrite issue with a regular Hash being merged with a HashWithIndifferentAccess in the ENV variable passed between rack layers (and god, was that hard to find! I had to write custom debugging tools that walked through every Rack layer and deep-diffed the ENV hash, etc.). That was the last straw. So far, Elixir/Phoenix has been fantastic for me at NOT producing "flagging tests", nondeterministic-seeming bugs, etc. Massive productivity boost.

joelbluminator 5y ago
Or...you are working on way smaller Elixir projects. Lets see how fun it is to inherit a million line old Elixir project 7 years from now. Or a million line codebase split into 50 services. I am sure you'll be productive as hell cos Elixir!
- sergiomattei 5y ago
  I sometimes wonder whether your job is to be a full-time dick about Elixir. It's been years of this nonsense. Let it go.
  - deleted 5y ago
    [deleted]
- pmarreck 5y ago
  :: let me hand-wave a merely possible but not at all guaranteed negative future scenario to argue against a better solution today :: that's basically what you just did. "Electric cars will pollute someday! Just you wait!" >..< Keep in mind that I've worked on small Ruby projects as well, and still prefer Elixir. I'm not gonna suggest that there wouldn't be challenges in that scenario, but it just seems to me so far that they'd be much more manageable given the thoughtful design of Elixir. The biggest problem in my app currently is actually JS/Node dependency hell, not Elixir code... and the JS only makes up a small portion of my app! (I should have never used AdminLTE as a design template...) At least my JS is tested (which was another huge PITA to figure out... simulating a DOM...)