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

Happy Birthday, Ruby

github.com

Post reply on HN
Print view View original

171–180 of 239 posts

Re: Happy Birthday, Ruby

#171

Post by sethrin »

cutler wrote: post #161
sho wrote: post #14

Earlier quoted context omitted.

Me too actually. I flirted with programming around uni-time and after - PHP, java, friggin' ada - and just couldn't see myself enjoying it so I went into network management instead. 10 years later I was thoroughly sick of that, so started to look around and heard about this little language called Ruby - and it was love at first sight. Then this little software project called Rails started to gain momentum and there w…

I don't get this Elixir as the natural progression for Rubyists. OO/mutable Ruby and functional/immutable Elixir are worlds apart beyond the superficial syntax similarities.

Ruby does lend itself to writing a lot of functional code. One can write Ruby so that it looks very similar to Bash or other Algol-derivatives, but it's also possible to write code which avoids side effects, mutable state, or variables in general.

Re: Happy Birthday, Ruby

#172

Post by sethrin »

sevensor wrote: post #133

The decision to implement DSLs by overriding method_missing seems to have opened a can of worms and the community has never managed to put the lid back on. More than anything else, this is the thing that seems to cause no end of consternation with Rails. At the same time, it's pretty much the defining feature of Rails.

I'm not aware that this has caused much consternation. I disagree that DSLs are a defining feature of Rails. There are other ways to implement DSLs besides `method_missing`, and rubocop and other style guides warn against using this method.

Re: Happy Birthday, Ruby

#173

Post by jrvarela56 »

I love the syntax, but I'm hating the debugging. Feel like a big chunk of my time is wasted chasing after errors that a compiler could catch for me.

Would love to have optional some kind of optional typing. Has anyone tried any of these? https://github.com/soutaro/steep https://github.com/plum-umd/rdl

Any other suggestions?

Re: Happy Birthday, Ruby

#174

Post by aaronmacy »

jrvarela56 wrote: post #173

I love the syntax, but I'm hating the debugging. Feel like a big chunk of my time is wasted chasing after errors that a compiler could catch for me. Would love to have optional some kind of optional typing. Has anyone tried any of these? https://github.com/soutaro/steep https://github.com/plum-umd/rdl Any other suggestions?

I've not personally tried it, but I remember thinking rdl sounded promising after seeing this talk (looks like there's a video online): https://www.thestrangeloop.com/2017/type-checking-ruby.html

Re: Happy Birthday, Ruby

#175

Post by jeremycw »

colechristensen wrote: post #145
TheRealDunkirk wrote: post #67

Earlier quoted context omitted.

So, I'm old, and have done lots of stuff in lots of languages in frameworks. For about a dozen years, Rails was my go-to toolkit. I've written a couple dozen production applications with it. Unfortunately, Rails has really fallen out of favor lately. Even a Rails-specialty shop I worked for briefly has pivoted to using ASP.NET. I've played around in that stack, and found it lacking. (EF just doesn't compete as an ORM…

Opposite ask: What would your state of the art be for starting something new with Rails? / suggestions to become quickly productive

Just read through https://guides.rubyonrails.org/ Unlike the sibling comment I suggest staying away from additional gems as much as possible especially if you're a beginner. Do things the officially blessed Rails way and you will run into the least amount of problems. All gems that try to 'fix' something in Rails will often have downsides of their own and can cause hard to debug issues in corner cases.

Re: Happy Birthday, Ruby

#176

Post by erik_seaberg »

mberning wrote: post #96

It seems like it is currently Ruby's turn to take a beating just like Java before it. I guess people relentless hate on Java even to this day, so maybe it will never get much better. But Ruby certainly holds a special place in my tool box. Here's to another 25 years.

Most of the Java complaints date back to the https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... era. A lot of things were needlessly painful before Java 8.

Re: Happy Birthday, Ruby

#177

Post by beforedawn »

pavlov wrote: post #16

Ruby is the very least favorite of all the programming languages I've had to use regularly over my career. Its syntax strongly favors cuteness over familiarity. Wherever Ruby can diverge from expectations to give you a pointless little tickle of whimsical inventiveness instead, it seems to do so. Visually it looks like an unwanted love child of Pascal and Python. There's no clear rhyme or reason to the use of sigils…

So true. Best was ActiveRecord, the most cumbersome ORM I have ever met, it could create 20 SQL requests out of a simple query.

There must be a reason that Ruby dropped few places on Github's Octoverse 2018.

While I was never against Ruby, every time has its tools, it was the culture of the Ruby community which I didn't like. Being a Rubyist was always a good excuse to not help on the frontend or help with some devops.

Now they escape into Elixir which is the next good academic excuse to not help with the frontend because React is so working class...

Re: Happy Birthday, Ruby

#178

Post by bonquesha99 »

dnautics wrote: post #157
empath75 wrote: post #11

Earlier quoted context omitted.

I'm not sure what language would be more beautiful than ruby, to be honest, and it's not even my favorite language to use. Let's do a mini code challenge in the thread -- implement fizzbuzz in the most beautiful way you can, in the most beautiful language you know:

> I'm not sure what language would be more beautiful than ruby. Elixir (with static type analysis) - gets a bit of an edge, IMO, thanks to pipes, which are way prettier than .then: defmodule FizzBuzz do @spec fizzbuzz(integer)::String.t def fizzbuzz(int) do cond do rem(int, 15) == 0 -> "FizzBuzz" rem(int, 5) == 0 -> "Fizz" rem(int, 3) == 0 -> "Buzz" true -> inspect int end end end 1..100 |> Enum.map(&FizzBuzz.fizzbuz…

Elixir/Unix style pipe operations in Ruby!

https://github.com/LendingHome/pipe_operator

Re: Happy Birthday, Ruby

#179

Post by TheRealDunkirk »

jeremycw wrote: post #175
colechristensen wrote: post #145

Earlier quoted context omitted.

Opposite ask: What would your state of the art be for starting something new with Rails? / suggestions to become quickly productive

Just read through https://guides.rubyonrails.org/ Unlike the sibling comment I suggest staying away from additional gems as much as possible especially if you're a beginner. Do things the officially blessed Rails way and you will run into the least amount of problems. All gems that try to 'fix' something in Rails will often have downsides of their own and can cause hard to debug issues in corner cases.

I can see where you're coming from, but I wouldn't advise rolling your own authentication and/or authorization systems, especially as a noob.

Re: Happy Birthday, Ruby

#180

Post by dnautics »

bonquesha99 wrote: post #178
dnautics wrote: post #157

Earlier quoted context omitted.

> I'm not sure what language would be more beautiful than ruby. Elixir (with static type analysis) - gets a bit of an edge, IMO, thanks to pipes, which are way prettier than .then: defmodule FizzBuzz do @spec fizzbuzz(integer)::String.t def fizzbuzz(int) do cond do rem(int, 15) == 0 -> "FizzBuzz" rem(int, 5) == 0 -> "Fizz" rem(int, 3) == 0 -> "Buzz" true -> inspect int end end end 1..100 |> Enum.map(&FizzBuzz.fizzbuz…

Elixir/Unix style pipe operations in Ruby! https://github.com/LendingHome/pipe_operator

it's not nearly the same. Piping in elixir is a macro; it lets you preserve the other arguments in your function call.

The IO.inspect(value, label: "label string") semantic is incredibly powerful. During debugging I often do this:

    value
    |> IO.inspect(label: "A")
    |> do_something
    |> IO.inspect(label: "B")
    |> do_something_else
    |> IO.inspect(label: "C")

    ...
This gives me full visibility over the data transformations that are happening. And removing the IO.inspect's are trivial with an IDE like atom, vscode, etc. Also the way that the BEAM handles concurrent IO means that none of those strings that I send will be interrupted by other content, which is critical to interpretable println debugging in a concurrent environment. I haven't used the debugger (or IEX.pry, whic I hear is powerful) once.
Post reply on HN