9 ms·

For some reason people seem to constant doubt Ruby-ists and Rails Devs. I completely get that other languages have huge benefits over Ruby. Golang being compil

• tty7 8y ago
  I looked into rails in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).
  • sampl 8y ago
    Yeah, I never found Rails as easy to learn as others did. Maybe it’s because I was younger and less experienced than now. Or maybe I’m dumb.
    • Shank 8y ago
      There is definitely a learning curve. For me, Rails was unapproachable until I started to give up the idea that I needed a ton of custom stuff in my stack. The "allure" I saw of pulling together a basic routing system and hooking things up by hand completely disappeared after building a pretty substantial web app in _Sinatra_. Rails makes a lot of decisions for you, but the decisions it makes are the _right_ ones. It's like having a "best practices" box that you can just shove your custom system into, rather than trying to build them in yourself. It's really quite something. For context: I basically learned Rails by way of building a proof of concept election management system in Rails in about three weeks (more like 1.5 in actual programming time). It also stored votes on a blockchain (ethereum). Even with a relatively complex storage system and interaction model, the Rails best practices left me with a really satisfactory application in no time flat. Perfect for a fast PoC.
    • ethbro 8y ago
      Depending on how long ago, I've noticed that the comprehensiveness of third party documentation (i.e. googling "how do I x?") can really change the experience. My memories of trying to install Linux circa 2000? Not favorable. Though to be fair I was a lot younger then too.
  • Shank 8y ago
    It's best to pick a project and try to build it, rather than learn things from the outside. In isolation, Ruby can be annoying to learn because it's syntactic sugar seems unnecessary. In context of an app, though, it's great. The sugar makes sense. Rails has a bit of a learning curve, but that learning curve is well rationalized. To borrow a Steve Jobs-ism: you're starting on the 10th floor, when everyone else is starting on the 2nd floor. Out of the box, you get a killer asset pipeline and complete MVC system that's standardized and conventional. You can throw together a well built webapp without cutting corners in a fraction of the time doing it by hand. Things like a solid REST API practically come free with Rails. That's really valuable.
    • modernerd 8y ago
      What are the best resources to learn Ruby/Rails these days?
      • guu 8y ago
        https://www.railstutorial.org/book https://www.railstutorial.org/book is quite good
        • mooreds 8y ago
          This is what I used to jump from "I've hacked on a rails 3 app and gone through some ruby Katas" to "I am building out a full fledged SaaS product in a Rails 4 app as technical co-founder". Highly recommended.
      • webbrahmin 8y ago
        Pick up rails book from pragmatic bookshelf. Give it a quick read. Then watch railscast videos. Then to rails doc and gorails.
        • richjdsmith 8y ago
          Another vote for Gorails. It's certainly the next step from beginner Rails dev to, well, not beginner.
  • jypepin 8y ago
    The community is so big, and so focused on conventions over configurations, usually googling "rails <questions>" returns a LOT of links to stack overflows and blogs that clearly explains everything. Rails offer so much syntactic sugar/plug and play gem systems that usually things are setup in fewer lines of code than anywhere else. The downside is that it's easy to build something while barely having any idea how it works, but if you want something up quickly (or if you already know how things work) then it's perfect.
• PostOnce 8y ago
  Are you aware that Flask exists for Python? I might take that bet about no one being able to go quicker than a Rails dev.
  • figgis 8y ago
    Agreed. Flask or Aiohttp + templating engine of choice + flask-login or aiohttp-security is extremely fast and simple.
    • djd20 8y ago
      Pyramid - https://trypyramid.com/ https://trypyramid.com/ - lightweight like flask but with that little extra that makes life easier (authentication, sqlalchemy integration). Not as heavy/opinionated as django. In fact, would argue, not opinionated at all.. just the right balance.
    • dempseye 8y ago
      You left out persistence, which is the most annoying bit of setting up a Flask project, imo.
  • pjonesdotca 8y ago
    From the Ruby side Sinatra is just as fast as flask to get something going. Having supported all three ( Rails, flask, Sinatra ) if it's going to be an API. I usually start with Sinatra.
• wybiral 8y ago
  The benefit of Golang isn't that it's compiled. It's that it has a good IO and concurrency model and the language is strict enough to force certain good practices on developers. IMO it would be almost as good even if the code execution were as slow as Python or Ruby.
  • matt2000 8y ago
    I hear this a lot about Go, but doesn't the webserver handle concurrency for you in most cases? I don't do a whole lot of explicit threading work when I write webservers in Java for example. Or is there something I'm missing that you use the Go primitives for in these cases?
    • wybiral 8y ago
      I'm not as familiar with Java but It's more about concurrency than threads. I have more familiarity with Python, so using that as an example... There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain. Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context. NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go. Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.
• vvanders 8y ago
  If backend speed/scale is your concern I'd also throw a vote in for Phoenix. Lots of similar heritage to Rails but built on Elixir/Erlang instead.
  • strken 8y ago
    Phoenix loses my vote for being quick to set up for a web application, because last time I used it, it didn't have a good authentication framework that worked with JSON APIs. What took ten minutes to set up using Devise in Rails took me two days using Coherence in Phoenix. Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.
    • mercer 8y ago
      I'm a huge fan of Phoenix, in part because it addresses the main issue I had with Rails (too much magic). But I do agree that losing the huge ecosystem of gems is a significant downside. Hopefully that'll change over time, because other than that, Phoenix really feels like the next iteration of Rails to me.
      • mooreds 8y ago
        That's my biggest gripe with Phoenix--so much good stuff can't be used. I understand that sometimes moving on the next thing requires this, but man, it isn't just Rails that has tremendous value when creating a web app. The entire ecosystem has so much good "drop in"/"near drop in" functionality.
    • arrel 8y ago
      Guardian has worked great for us for JWT auth
• fyfy18 8y ago
  I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow. You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later. I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.
  • meesterdude 8y ago
    iirc, the ruby 3x3 benchmark project is getting a ruby game (i think mario) to run at 60fps, and ruby 2.5 already hit that target. even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.
  • technion 8y ago
    I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual. I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
    • busterarm 8y ago
      "Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better). One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done. That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
      • jaggederest 8y ago
        Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases. Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
• meesterdude 8y ago
  Totally agree. Rails is really powerful; it not only gets you up and running fast, but it can carry you very far. Like, years and years. And for a lot of places (like github, hulu) they seem to manage fine with it as their stack. > Rails becomes not so great in other cases like building speedy backend jobs Rails is still pretttty good for this. I mean, gosh; maybe not a game engine or something like THAT - but for much of what is done on the web rails can be optimized to complete requests in ~25ms. > But for a small user-facing web app "small" as in 95% of websites out there that aren't facebook/google. I mean, shopify handles 80,000/req/sec on a rails stack and they are the backbone of a lot of small (and not so small) e-commerce stores.
• nicostouch 8y ago
  I started building a SaaS in Java/Spring and months in realised Ruby/Rails would have been stunningly faster to get the same result. The full write-up is here for reference http://tayler.io/5-lessons-learned-as-an-indie-hacker/ http://tayler.io/5-lessons-learned-as-an-indie-hacker/
  • gspetr 8y ago
    Your site completely refuses to load with noscript. Are you sure the complexity needed for it warrants this?
• antoaravinth 8y ago
  On a side note, if someone asks me to prototype anything on Java world, will pick Grails. Getting a webpage up and running in Grails is so easy.
  • vorg 8y ago
    Which version of Grails was that? If you mean version 3, why is virtually no-one starting new projects in it, or upgraded from v.2 ? Grails 3 looks like nothing more than a wrapper around Spring Boot, so why not just use that? If you're talking about version 2, why has its plugin ecosystem died?
• naikrovek 8y ago
  Well, here's one reason: the amount of time saved when standing up a webapp on Rails is absolutely insignificant compared to the life of that webapp in all situations where that webapp is anything serious. Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall. In short: you don't save any time at all, in the big picture, and now you have all the long-term disadvantages of Ruby.
  • matthewmacleod 8y ago
    I entirely disagree with this. Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term. Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.
    • naikrovek 8y ago
      Everytime I say anything on this orange website anymore it is immediately voted down. I guess the orange website isn't for me anymore.
      • dempseye 8y ago
        Well, your comment contained a bit of a generalisation. It may or may not be true depending on the size of the app, its purpose, the number of developers, their level of experience, and a bunch of other factors. The response contained a generalisation too. Horses for courses.
  • aianus 8y ago
    Assuming we’re talking about a startup, the expected lifetime of your product is ~0 and so is the number of customers. If you’re somehow lucky enough to ever have so many users that you have issues with rails, you will have the money (VC or otherwise) to deal with it.
• crag 8y ago
  Laravel. It's PHP and (assuming you know Laravel) you can get a it up in minutes. It's development time is as fast as Rails. I'm not taking any chips from Rails. Rails was the first and is still one of the best. Just pointing out that there are other frameworks that are designed to move to production fast.
• reitanqild 8y ago
  Somewhere around 2006, after my first enthusiasm about Rails I realised I could get almost the same, with a language that is more natural for me, has more developers here, as well as cheap hosting options (less of a concern now) by going with php/symfony. Later I've been enjoying - a php microframework that slips my mind - python/flask/sqlalchemy - JavaEE (yup, except JSF)
• _hardwaregeek 8y ago
  I keep on running into this problem where I try to use a new framework/language for backend, like Go, Kotlin, even Node, but I just get so damn bored with writing the same boilerplate. Say what you will about Rails, but at least the maintainers try to automate the boring parts. Not to mention between Elastic Beanstalk, Heroku and even plain old Capistrano on a VPS, deploying Rails is a breeze. Maybe some people take some perverse joy from writing CRUD operations for the millionth time, but I don't.
  • alfredallan1 8y ago
    I’m curious: once one has written a CRUD app, why can’t they use that as the boilerplate for other CRUDs they need to write? Replace the bits specific to each individual app. If the program is designed in a sufficiently modular fashion, shouldn’t this be doable?
    • Larrikin 8y ago
      That assumes you're allowed to use the code you wrote in a previous project in your new project.
      • alfredallan1 8y ago
        Eh, are you perhaps hinting at that horrible lawsuit where Oracle sued Google(?) for a lot of money for copying about 9(?) lines of code that was basically a looping routine? That notwithstanding, I was asking about code that could be considered “boilerplate”, not things that could be considered proprietary business logic. So the code to do a login, or check for cookies, or get something from a db, or anything of that sort should be broadly reusable (for a general CRUD app).
• xstartup 8y ago
  It's hard for us to train new devs in Ruby and Rails. We've found Go to be superior in deployment + speed up on new developers.
  • mooreds 8y ago
    Curious about specific difficulties with Rails? And what web frameworks do you use with Go?
• cpursley 8y ago
  > no way anyone is beating a Rails dev in setting one up I disagree. Elixir/Phoenix is as simple as Ruby/Rails and an order of magnitude more performant out of the box. Especially if you already know Ruby and the basics of functional programming. Plus, unlike Rails, you probably won't need separate servers for background jobs, websockets and caching.
  • rishav_sharan 8y ago
    And if the next order of magnitude of performance is needed, there's always Crystal
    • blunte 8y ago
      But since it is much newer, the docs and examples are much thinner than Phoenix. Plus, except for unoptimized database actions (which would equally affect Crystal), Phoenix responses are usually sub 200ms. Some are sub 1ms. So it really isn't in need of performance increase. Ecto, however, is really not pleasant imo.
  • trcollinson 8y ago
    Sorry to fact check here but on my Rails app I am getting 200ms return times. This is running a web application and a few hybrid mobile applications. Are you saying that basically out of the box with Elixir/Phoenix I would get 20ms return times? That would be amazing but I find that highly unlikely.
    • cpursley 8y ago
      Yes, and likely faster. http://www.akitaonrails.com/2015/10/27/how-fast-is-elixir-phoenix http://www.akitaonrails.com/2015/10/27/how-fast-is-elixir-ph...
      • trcollinson 8y ago
        That’s quite interesting. I’m going to have to give this a try under real world condition. This gives a pretty good argument for massive improvement.
• egyptiankarim 8y ago
  Agreed! I have a template built that allows me to spin up a basic web app with all my baseline common dependencies ready to go and a handful of little nice-to-haves in place and deploy to Heroku in well under an hour. I love Rails!
• mattmanser 8y ago
  You can literally start and publish a C# web app to azure in minutes if you wanted to. They have built in deploy from GitHub. I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.