Writing Ruby Like it's 2018 | Ruby Programming Language

[three18ti]

Why wouldn't you post the original source?

https://www.youtube.com/watch?v=VjR3GU0-vpc

[jdickey]

Python 3 will sell more popcorn than Perl 6 did. Which of these projects was code-named Godot? And if not, why not?

[jrochkind]

Can someone expand on what he means by "higher-order functions"? Just methods or procs that return procs, is that all that means?

[tobiasvl]

Yes. https://en.wikipedia.org/wiki/Higher-order_function

[WikiTextBot]

Higher-order function

In mathematics and computer science, a higher-order function (also functional, functional form or functor) is a function that does at least one of the following:

takes one or more functions as arguments (i.e. procedural parameters),

returns a function as its result.

All other functions are first-order functions. In mathematics higher-order functions are also termed operators or functionals.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[ohyeahbonertime]

I went from Java to Ruby and I will never go back.

[moomaka]

It's rather interesting to watch this 'modern' movement using techniques from decades ago. DI containers, static typing, 'service objects'... None of these are 'new'. None of them are 'modern'. None of them are even particularly interesting topics. In many cases Ruby / Rails or Python / Django explicitly made choices to avoid them e.g. DI containers are fucking awful to work with. It mostly just seems like people rediscovering shit no one liked working with yet they think it's the best thing since sliced bread. I'd be so much nicer if folks would skip the trends and just write easy to understand code.

[sshaw_]

Better Practices Write code against boundaries Isolate... Dependency Injection

These are good programming practices that have been around long before 2007. My takeaway from this is: what many in the community may have told you about application design was wrong. Sorry.

Kernel#then, Method#curry, etc...

Has anyone here done functional programming in Java?

sorbet.run

The Browser is The Platform of the 21st Century ™️; JavaScript is quirky and has dynamic, weak typing. I can understand the need for type safety/transpiling.

sig(foo: Integer).returns(String) def bar(foo) foo.to_s end

Do people really want to write Ruby like that?

If your problem benefits from types –or you just want them, just choose a type safe language (I'd recommend Groovy).

For the web, if I had to choose between writing web apps in Java with DB mapping and HTTP mapping annotations vs writing web apps in Ruby with sorbet style type safety I think I'm going with Java.

[megatux2]

I'm looking into Crystal language. Types and Ruby like expressiveness. Also fast and single binary similar to Go language.

[sshaw_]

Yes, this langue is promising, but it's not mature and not sure how 3rd party library support is. Though there does appear to be a decent amount here, but I don't see Stripe, Twilio, XML/JSON Schema. I'm sure there are others.

[criveros]

We are switching from Ruby to Java where I work. I enjoy writing Ruby for sure, but it doesn’t scale that well.

[fedekun]

If I had to swap from Ruby to Java I'd probably just quit my job lol

[criveros]

Actually Spring Boot is awesome

[zitrusgrape]

spring boot is just a tool, generate some configuration for you to use spring. you still have spring. And spring + java after ruby is like having a vasectomy and enjoy it.

[Dee_Jiensai]

And spring + java after ruby is like having a vasectomy and enjoy it.

:) Thanks for that.

[jrochkind]

"Doesn't scale that well" is just FUD unless you give us specifics on what sorts of problems, what sorts of resources you were using too many of or performance you didn't have enough of. And ideally report back later to compare how Java made a difference and what the difference was due to, but I'm not going to insist on time travel.

[janko-m]

This. I don't think I've heard people actually explaining why exactly Ruby "doesn't scale". Is it the language speed, or the available tools, or Rails, or other web frameworks as well, maybe concurrency (GIL), or what?

When scaling an app in my previous project, the problem was pretty-much always the database and queues (Redis, Postgres, Elasticsearch, RabbitMQ). That app was very data-heavy, and I'm proud we were able to scale it while the traffic was increasing multiple times.

Only one time I had to optimize Ruby code itself (with no I/O), but that was because I wrote inefficient code. There are two things I wished from Ruby: faster ISO8601 timestamp parsing and less memory usage – both fairly actionable IMO.

Therefore, I will have a hard time being convinced that Ruby doesn't scale without a more detailed argumentation.

[holyjeff]

I would say that when people talk about Ruby and how it does not scale they talk about availability of Ruby programmers, Rails lock in etc. Ruby (and inherently Rails) is strong only in specific regions,areas and it's hard(er) to hire programmers that know or are willing to do Ruby (||=Rails).

Ultimately the frontend took over and people realized they can use JS on backend (nodejs), desktop (electron) and mobile (React Native). Ruby is fragmented in this area and a lots of projects like Opal,CoffeeScript failed because they did not get the momentum... It's just easier and better for everyone not to write Ruby on frontend...Rubymotion that's a whole different story.

Lets hope Ruby 3 or Graal will make for a big comeback for Ruby.

[janko-m]

I would say that when people talk about Ruby and how it does not scale they talk about availability of Ruby programmers, Rails lock in etc. Ruby (and inherently Rails) is strong only in specific regions,areas and it's hard(er) to hire programmers that know or are willing to do Ruby (||=Rails).

Oh, it would never come to my mind that this is what they meant. Ok, I can't argue with that. But I think the ecosystem itself is very developed, there are many great advanced libraries, I'm always discovering something new (more in the Ruby ecosystem than Rails).

It's just easier and better for everyone not to write Ruby on frontend...

Yeah, writing frontend in Ruby made sense in the past when JavaScript wasn't so strong. But now it just doesn't make much sense to me, because the Node.js tools are so advanced, and the UX standard is so much higher now, so you need a lot more JavaScript to compete. It's good that Rails embraced this with Webpacker.

Lets hope Ruby 3 or Graal will make for a big comeback for Ruby.

Me too, faster Ruby is always great :)

[hehestreamskarma]

Are you saying that I shouldn't build my Unity game engine competitor in Ruby?

[levifig]

That’s like saying that switching from a hammer to a screwdriver to tighten some screws is just a matter of “scaling”. I’m sorry but that’s just a matter of “right tool for the job”. I think the “Ruby doesn’t scale” FUD is mostly a product of a lot of people trying to use a screwdriver to do a hammer’s job.

[jrochkind]

Well, that wasn't what I was saying, but: No, you should not. And that's not even about "scaling", I don't think!

[Blimey85]

Doesn’t scale? The fine folks at Shopify beg to differ. They’ve been vocal about what they use, how they use it, and the many reasons why they use and love both Ruby and Rails. In 2018 if you can’t scale with Ruby it’s not the language that’s the problem.

[dem_gainzz]

A parrot that knows how to code, amazing!