Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Ode to Ruby

blog.yboulkaid.com

Post reply on HN
Print view View original

91–100 of 204 posts

Re: An Ode to Ruby

#91

Post by KerrAvon »

iterati wrote: post #32
Mikeb85 wrote: post #28

Earlier quoted context omitted.

Nope. Can't stand that Python uses built-in functions for basic things like list, map, fold, etc... instead of methods on base classes. Here's a super basic example. Add one to an array [1,2,3] and print results. Python: print(list(map(lambda x: x + 1, [1,2,3]))) Ruby: print [1,2,3].map {|x| x + 1} So much more readable, easy to write, etc... Ruby keeps it consistent by making pretty much everything an object and you…

print([x + 1 for x in [1,2,3]])

This really goes to the heart of the problem with modern Python. It's lost the simplicity of the language which was the whole point of it in the first place. OO and functional paradigms were bolted on to varying degrees of success, but an outsider can no longer look at average Python code and understand it at a glance.

Re: An Ode to Ruby

#92

Post by jack_riminton »

ryanbrunner wrote: post #78
jack_riminton wrote: post #34

I like that the Ruby community has embraced the fact it is no longer cool. I recently interviewed for a ruby/rails job where the dev team had come from a previous start up that tried to port an existing Rails app to a React/Microservices one with disastrous results. For this job they were relishing coming back to a monolithic Rails app. I hope this trend continues!

My latest job is at a place where we have an extremely 'old-school' Rails app. The vast majority of UI is server-rendered HTML, Javascript (at least that we wrote, we do use Turbo) is very, very minimal, and we're just one very large service. The previous place I was at was a microservice heavy (the count of services was almost on par with the number of developers) React and Node based application. I'm orders of magn…

I'm not surprised.

I have a theory that there's a perverse incentive for startups to make their work more expensive and therefore more complicated. It's related to this quote by Paul Graham about funding:

"VCs don't invest $x million because that's the amount you need, but because that's the amount the structure of their business requires them to invest. Like steroids, these sudden huge investments can do more harm than good. Google survived enormous VC funding because it could legitimately absorb large amounts of money. They had to buy a lot of servers and a lot of bandwidth to crawl the whole Web. Less fortunate startups just end up hiring armies of people to sit around having meetings."

(from here http://www.paulgraham.com/venturecapital.html)

For those that aren't VC funded I think that a lot can be explained by cargo-culting; "If startup X is using Node/React/Redux/microservices and they just scored a 20m Series A then we'd better do it too"

Re: An Ode to Ruby

#93

Post by m12k »

pantulis wrote: post #47
brigandish wrote: post #18

Earlier quoted context omitted.

I also took a while to get used to the typing in Crystal but once you do get it, it's worth the effort IMO. I occasionally still fire up Ruby but if I have anything more to do than a quick command-line command, I use Crystal, so many less problems.

Crystal was overall a pleasant experience, which I cannot say for Rust. Although it was probably my fault: 1) for being "rusty" as a programmer myself, and 2) having zero experience with Rust. I want to believe that once you get over the learning curve in Rust development speed becomes much higher. Surprisingly, Crystal seems to be much leaner in runtime size than Rust, with similar performance (although the use case…

I've heard it described that Rust allows you to write programs in a specific way. If you try to write them in any other way, you're going to have a very, very bad time, and fight the borrow checker every step of the way. But if you embrace that way of writing programs, it makes it pretty easy, you get really good error messages, and as a cherry on top your program will be provably sound in a way pretty much no other language can guarantee. So it all comes down to whether you're interested in learning that specific way of structuring programs.

Re: An Ode to Ruby

#94

Post by pantulis »

rattray wrote: post #64
pantulis wrote: post #11

Earlier quoted context omitted.

What was cool was Rails, IMHO, and Ruby was the surprise inside it. I've had my own personal Advent of Code these holidays, coding a small API for a personal need. Ruby (Sinatra) took one morning to full deployment in Heroku. Then I tried Crystal (Kemal) and it took me a couple of days to figure out how to map JSON to Crystal data structures. Then I rewrote it again in Rust (Rocket). Two weeks till I figured out, wel…

Surprised you didn't try Elixir? What about Sorbet?

Well, I did a little bit of research on Elixir a couple of years ago, so I felt like I had that covered. Using Kotlin + Ktor was also tempting.

Re: An Ode to Ruby

#95

Post by pantulis »

m12k wrote: post #93
pantulis wrote: post #47

Earlier quoted context omitted.

Crystal was overall a pleasant experience, which I cannot say for Rust. Although it was probably my fault: 1) for being "rusty" as a programmer myself, and 2) having zero experience with Rust. I want to believe that once you get over the learning curve in Rust development speed becomes much higher. Surprisingly, Crystal seems to be much leaner in runtime size than Rust, with similar performance (although the use case…

I've heard it described that Rust allows you to write programs in a specific way. If you try to write them in any other way, you're going to have a very, very bad time, and fight the borrow checker every step of the way. But if you embrace that way of writing programs, it makes it pretty easy, you get really good error messages, and as a cherry on top your program will be provably sound in a way pretty much no other…

That's true, but then it is not "allowing" or "enabling" me, it is "forcing" me to do it that way. Of course, the Rust compiler is catching a gazillion bugs beforehand, so this is cool: you finally feel like your program will have no bugs once you manage to compile it.

Error management through Option values, the borrowing checker... they are cool technologies for a C-like language, but they are not palatable at the beginning (maybe they are an acquired taste like beer?). I am tempted to stretch it a little bit more and see how productive I can become writing Rust code, but also not so sure about the effort.

Re: An Ode to Ruby

#96

Post by clairity »

bachmeier wrote: post #10

One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.

ruby and rails is a much nicer, more complete, more consistent, and easier to learn ecosystem relative to js/node. and node is just the js server, so you need need a framework on top of it, like react/angular/vue/ember, to be equivalent. for most use cases, i really can't recommend the js-heavy route now that rails comes with hotwire (a transparent js framework for live/async html transfer, rather than json).

for authentication/authorization/security, it's great to learn by writing those from scratch, but unless you want that to be your career focus, you'd really be much better off to defer to battle-hardened libraries in those areas for any commercially-/publicly-oriented web app.

Re: An Ode to Ruby

#97

Post by Mikeb85 »

bachmeier wrote: post #10

One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.

Rails is shockingly easy, especially Rails 7.

Strait up, use Rails with all the defaults (ImportMap, Hotwire) but use Postgres and maybe Tailwind (`rails new myapp --database=postgresql --css=tailwind`). No extra gems are needed really (if anything, they add more complexity as not all are updated to be compatible with Rails 7).

Re: An Ode to Ruby

#98

Post by sodapopcan »

revscat wrote: post #53
sodapopcan wrote: post #19

Earlier quoted context omitted.

Equally maybe. Simpler? I'm not sure, I don't know Python very well. A couple of things I found surprising about Python was having to do the whole `re.compile` thing instead of just `//` in Ruby. Also, no one will ever convince me that a list comprehension is simpler than `map` and related functions. Also, it's hard to beat the convenience of libs that let you do `1.day.ago`. Ruby gets complicated when people start t…

> Ruby gets complicated when people start throwing around metaprogramming where they shouldn't. This is true. Thankfully it appears that the broader Ruby community has recognized this as well, and has moved away from metaprogramming to a large extent. It's still there, but you don't see it utilized nearly as frequently as you once did.

I'm fine with it for libraries. In fact, its use in libraries is a lot of makes ruby great! It goes too far when people start sprinkling it in business logic making it impossible to find where anything is defined. I'd say you'd either have to go full-lisp and create an entire DSL for your domain (and document it) or keep it completely out of business logic (which, as you say, the community as a whole has pretty much figured this out).

Re: An Ode to Ruby

#99

Post by busterarm »

ace33 wrote: post #12
Mikeb85 wrote: post #6

It's too bad Ruby isn't seen as 'cool' anymore, it's just so easy to be productive in it. And now MJIT, YJIT and TruffleRuby are making some very impressive performance gains. Rails is also better than ever and I still can't think of a better language for scripting.

"I still can't think of a better language for scripting." Python I find equally if not more simple. Would you agree?

Python forces you to wrestle with its'/Guido's idiosyncracies. It wears them on its sleeve almost like a badge of honor. You may enjoy them, but I don't. Lack of Tail Call Optimization is a huge red mark for me, personally.

Ruby, on the other hand, is literally meant to delight you with its choices/options/expressiveness and I find that it absolutely delivers on that promise.

Re: An Ode to Ruby

#100

Post by busterarm »

regularfry wrote: post #71
junoper wrote: post #57

Earlier quoted context omitted.

Python, I think, has n number of ways of doing the same thing while Ruby's everything is object approach forces you down a single approach. So while reading ruby code, you usually don't have to shift your mental model from OOP to procedural/list comprehension etc. If Ruby gets a good machine learning library on par with something like Pytorch, I am sure many folks will shift to it and we might see new DSL emerge.

Which is ironic, given that "There should be one-- and preferably only one --obvious way to do it" is in PEP 20.

The vast majority of Python code that I have had to interact with professionally seems to ignore the fact that PEP even exists.
Post reply on HN