6 ms·

There's a lot of comments of the form "I tried getting into Ruby and it never clicked" that I want to respond to. I think that if you're just writing a script

by dlkf 7y ago

There's a lot of comments of the form "I tried getting into Ruby and it never clicked" that I want to respond to. I think that if you're just writing a script to solve a math problem or automate a task, there isn't really a strong argument as to whether you should use Ruby, Python, bash any other high level language. You should probably use whatever you're most comfortable with. But if you're making an application with a database, RoR is an extremely powerful tool. And this isn't just a case of Ruby having the best library (in the same way that Python has the best scientific computing library). It's a case of the library functionality and the language playing together really well. Ruby statements look more like natural language statements than those in other languages. This is a really helpful design choice when you're building a crud application. In that context, you're not thinking about X, Y, -Log(X + Y) or whatever. You're thinking about a new customer, or whether some old customer is a member? of some mailing list, etc In a weird way, it's similar to how Haskell users love the fact that statements in Haskell are mathematical truths. In the case of logic programming this is a handy feature to have. In the case of writing the business logic of a CRUD app, it's handy if your statements look like natural language statements about the underlying real world objects whose representation you are reasoning about.

thrwaway69 7y ago
I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in). From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated. If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain. I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries. For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture) None. For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith. I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job. I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.
- dlkf 7y ago
  I like your post a lot. I don't disagree with anything in it per se, but I think there are a couple qualifications worth making. > From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. > If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Roughly speaking I agree. However, two comments: 1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby. 2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have. > I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language. I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.
  - thrwaway69 7y ago
    Yeah, my original comment is disorganised. Essentially, I meant to distinguish between two business sides (there are others) rather than making point for any language or situation. The compiled language part was an example to long standing businesses where you are aware of many details like software sweeping cycles, culture, goals, requirement changing tendencies, etc. > That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. Yes, see this puts you into short standing business bucket. > Syntax doesn't provide enough value on its own in a general programming language. I actually didn't mean this literally. I think of tools as a means to move around and give shape to a product, team, business or yourself. Syntax can be relevant to that while relying on syntax in seldom is a bad idea. Examples: People who like ruby syntax and are attracted to it is a different bunch than those who are attracted to java. While you may prefer to use java, you don't necessarily want programmers attracted to java in your team. Using statically typed language may provide more friction to think about the structure or slow you down a bit which may be important for shaping the product. In short, you don't want tools to decide your fate. Sometimes, using less than the 'best' is a better choice.
JMTQp8lwXL 7y ago
I don't understand why the Node community doesn't have an analogous to Rails. I love the Ruby language, but given that much of my work is on the front-end, I'd love to avoid context-switching between two languages for my stack. Also, with some requirements like server-side rendering, being able to natively do that in my web server is nice. I haven't used Rails since the early 2010s.
- petre 7y ago
  They do have Sails but it's nowhere as good as as RoR. At least prefer something fast like Fastify or Koa if using Node.js.
  - cutler 7y ago
    Doesn't this kinda prove the point that Node.js is only more performant when used with micro-frameworks like Express? That Sails failed to match Rails should tell you something. A fair comparison with Express would be something like Grape or Rhoda. Node.js itself should be compared with Rack which is pretty fast.
    - JMTQp8lwXL 7y ago
      The fact that Sails never caught on to match or exceed Rails usage doesn't mean the main problem was primarily performance. Rails, for one, has a huge incumbency advantage (2004). Second, Rails is just easier than throwing together a pile of NPM modules. Imagine if you had 0 knowledge of the NPM ecosystem. It'd be quite a lot of decision making to evaluate a basket of modules that could emulate all of what rails provides.
      - petre 7y ago
        Thworing together a pile of third party NPM modules is a bad decision anyway. This is precisely why we picked Mojolicious to use as a Perl web framework: minimal dependencies, minimal breakage, reimplements some functionality. It turned out to be a good decision as it's also actively maintained compared to the others.
skohan 7y ago
> RoR is an extremely powerful tool The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, and then I would end up with something that felt like a hack to circumvent Rails' default behavior. That, or I would want to do something which is very simple conceptually, but I would have to add some unnecessary complexity and/or ceremony around it to fit into Rails' interfaces. Also I'm not a huge fan of the Rails' model of having everything from request handling to routing to DB access in one big framework. The needs of each application can be quite varied, and I'd rather plug whatever components together I want to for a given project than to be limited by some outer structure. > Ruby statements look more like natural language statements than those in other languages The more I program, the more appreciative I am of a strict compiler. What I've always found with interpreted languages is, while they seem convenient at first, projects inevitably start to slow down under the accumulated "squishiness" due to lack of strictness. I find it's pretty easy to get used to syntax, but there can be a lot of hidden "gotchas" in interpreted code which tend to outweigh any benefits. Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.
- deleted 7y ago
  [deleted]
- bigiain 7y ago
  > The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, I think this is the first part of the insight needed. The second part, which by far the most productive full stack web dev I know has got completely nailed, is that mostly the right answer to that is to push back on the business/requirements with a good alternative to what they _think_ they want that _is_ in "the blessed path". A good Ruby dev who has the ability/skill/respect to do that is maybe the closest thing I've ever seen to the mythical "10x engineer" on a consistently repeatable basis... And this goes for other things besides RoR too, I've got a Python/Django guy who can build amazing stuff in weeks, but he'll tell me why I am not getting what I asked for but this other thing that does the same job (sometimes better) because "that's the right way to do it with Django".
fantasticsid 7y ago
I think focusing on the syntax level is a bit superficial. While Ruby (especially in the context of RoR) lends itself very well to making DSLs and making abstractions, and thus writing superficially good looking, concise, easy to follow (on a syntax level) application code, it really breaks down when the abstraction does not work perfectly the way you want it. If you have debugged a Rails app and tried to find where in the 10 level call stack a side effect is introduced, knowing that at each level a 'method_missing' could've changed things, and thus you're really looking at a non-linear call stack since each function call can branch out, you'll know the beautiful looking syntax is not free and in fact very costly. And don't get me started on poorly documented (if any) CoC (black magic)..
- alanh 7y ago
  CoC means many things. What do you use it to mean here?
  - RussianCow 7y ago
    Probably "convention over configuration".
  - agumonkey 7y ago
    my best bet: Convention over Configuration (had to google tbh)
  - fantasticsid 7y ago
    Yeah, sorry for the abbreviation. I meant 'Convention over Configuration'
- rajangdavis 7y ago
  I agree with you on the comment about abstractions, but I think I would rather have Rails with esoteric code than something less "conventional" with esoteric code.
  - fantasticsid 7y ago
badrabbit 7y ago
I just didn't like the tooling,it's quite messy. Python is similar enough, I would hate to do things in both.
deleted 7y ago
[deleted]

by dlkf 7y ago

thrwaway69 7y ago

I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in). From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated. If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain. I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries. For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture) None. For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith. I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job. I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

dlkf 7y ago
I like your post a lot. I don't disagree with anything in it per se, but I think there are a couple qualifications worth making. > From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. > If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Roughly speaking I agree. However, two comments: 1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby. 2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have. > I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language. I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.
- thrwaway69 7y ago
  Yeah, my original comment is disorganised. Essentially, I meant to distinguish between two business sides (there are others) rather than making point for any language or situation. The compiled language part was an example to long standing businesses where you are aware of many details like software sweeping cycles, culture, goals, requirement changing tendencies, etc. > That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. Yes, see this puts you into short standing business bucket. > Syntax doesn't provide enough value on its own in a general programming language. I actually didn't mean this literally. I think of tools as a means to move around and give shape to a product, team, business or yourself. Syntax can be relevant to that while relying on syntax in seldom is a bad idea. Examples: People who like ruby syntax and are attracted to it is a different bunch than those who are attracted to java. While you may prefer to use java, you don't necessarily want programmers attracted to java in your team. Using statically typed language may provide more friction to think about the structure or slow you down a bit which may be important for shaping the product. In short, you don't want tools to decide your fate. Sometimes, using less than the 'best' is a better choice.

JMTQp8lwXL 7y ago

I don't understand why the Node community doesn't have an analogous to Rails. I love the Ruby language, but given that much of my work is on the front-end, I'd love to avoid context-switching between two languages for my stack. Also, with some requirements like server-side rendering, being able to natively do that in my web server is nice. I haven't used Rails since the early 2010s.

petre 7y ago
They do have Sails but it's nowhere as good as as RoR. At least prefer something fast like Fastify or Koa if using Node.js.
- cutler 7y ago
  Doesn't this kinda prove the point that Node.js is only more performant when used with micro-frameworks like Express? That Sails failed to match Rails should tell you something. A fair comparison with Express would be something like Grape or Rhoda. Node.js itself should be compared with Rack which is pretty fast.
  - JMTQp8lwXL 7y ago
    The fact that Sails never caught on to match or exceed Rails usage doesn't mean the main problem was primarily performance. Rails, for one, has a huge incumbency advantage (2004). Second, Rails is just easier than throwing together a pile of NPM modules. Imagine if you had 0 knowledge of the NPM ecosystem. It'd be quite a lot of decision making to evaluate a basket of modules that could emulate all of what rails provides.
    - petre 7y ago
      Thworing together a pile of third party NPM modules is a bad decision anyway. This is precisely why we picked Mojolicious to use as a Perl web framework: minimal dependencies, minimal breakage, reimplements some functionality. It turned out to be a good decision as it's also actively maintained compared to the others.

skohan 7y ago

> RoR is an extremely powerful tool The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, and then I would end up with something that felt like a hack to circumvent Rails' default behavior. That, or I would want to do something which is very simple conceptually, but I would have to add some unnecessary complexity and/or ceremony around it to fit into Rails' interfaces. Also I'm not a huge fan of the Rails' model of having everything from request handling to routing to DB access in one big framework. The needs of each application can be quite varied, and I'd rather plug whatever components together I want to for a given project than to be limited by some outer structure. > Ruby statements look more like natural language statements than those in other languages The more I program, the more appreciative I am of a strict compiler. What I've always found with interpreted languages is, while they seem convenient at first, projects inevitably start to slow down under the accumulated "squishiness" due to lack of strictness. I find it's pretty easy to get used to syntax, but there can be a lot of hidden "gotchas" in interpreted code which tend to outweigh any benefits. Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.

deleted 7y ago
[deleted]
bigiain 7y ago
> The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, I think this is the first part of the insight needed. The second part, which by far the most productive full stack web dev I know has got completely nailed, is that mostly the right answer to that is to push back on the business/requirements with a good alternative to what they _think_ they want that _is_ in "the blessed path". A good Ruby dev who has the ability/skill/respect to do that is maybe the closest thing I've ever seen to the mythical "10x engineer" on a consistently repeatable basis... And this goes for other things besides RoR too, I've got a Python/Django guy who can build amazing stuff in weeks, but he'll tell me why I am not getting what I asked for but this other thing that does the same job (sometimes better) because "that's the right way to do it with Django".

fantasticsid 7y ago

I think focusing on the syntax level is a bit superficial. While Ruby (especially in the context of RoR) lends itself very well to making DSLs and making abstractions, and thus writing superficially good looking, concise, easy to follow (on a syntax level) application code, it really breaks down when the abstraction does not work perfectly the way you want it. If you have debugged a Rails app and tried to find where in the 10 level call stack a side effect is introduced, knowing that at each level a 'method_missing' could've changed things, and thus you're really looking at a non-linear call stack since each function call can branch out, you'll know the beautiful looking syntax is not free and in fact very costly. And don't get me started on poorly documented (if any) CoC (black magic)..

alanh 7y ago
CoC means many things. What do you use it to mean here?
- RussianCow 7y ago
  Probably "convention over configuration".
- agumonkey 7y ago
  my best bet: Convention over Configuration (had to google tbh)
- fantasticsid 7y ago
  Yeah, sorry for the abbreviation. I meant 'Convention over Configuration'
rajangdavis 7y ago
I agree with you on the comment about abstractions, but I think I would rather have Rails with esoteric code than something less "conventional" with esoteric code.
- fantasticsid 7y ago

badrabbit 7y ago

I just didn't like the tooling,it's quite messy. Python is similar enough, I would hate to do things in both.

deleted 7y ago

[deleted]