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

Where is Ruby Headed in 2021?

bignerdranch.com

Post reply on HN
Print view View original

291–300 of 360 posts

Re: Where is Ruby Headed in 2021?

#291

Post by joelbluminator »

dnautics wrote: post #258
joelbluminator wrote: post #163

Earlier quoted context omitted.

Pepsico, Toyota ...come on now that's weak. They're not even IT companies let alone Tech. Whatsapp is running on a fork of Erlang afaik , not Elixir. Look I'm not saying no one is using Elixir, I'm just saying there's little jobs that's all. Cherry picking some famous names isn't gonna change that.

how about PagerDuty, Divvy, Slab? I once worked at a company where the CTO said 'elixir is an unknown quantity and I'm not sure we want to rely on it' and here we were using three critical services (one financial!) that were running on elixir. > there's little jobs that's all wasn't an issue for me. I applied for five elixir jobs in a limited sector (fintech) and got an offer.

Have never heard of Divvy and Slab. PagerDuty is a nice company though. Thats still not much. You can't compare it to Go or Kotlin or Swift who are about the same age as Elixir.

Re: Where is Ruby Headed in 2021?

#292

Post by phyrex »

tonyedgecombe wrote: post #283
phyrex wrote: post #238

Earlier quoted context omitted.

There’s an implicit “arguments” function argument through which you can access the extra parameters. It’s JSs way of function overloading

Which looks like an array but isn't.

There’s a lot of that kind of thing in JS, isn’t there? :(

Re: Where is Ruby Headed in 2021?

#293

Post by joelbluminator »

whakim wrote: post #290
joelbluminator wrote: post #288

Earlier quoted context omitted.

Null exceptions can even happen in Java. I wasnt refering to those.

But most types (besides primitives) in Java are nullable, right? Sorbet literally wouldn't let you write this code: https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A... Null is simply the most frequent example of this issue. Getting an integer rather than a string is super common, for example. Or a string instead of a date.

What does super common mean? Do I see these bugs once a month? No, I do not. Null exceptions are common I agree with that. For me its not enough to appreciate something like Java or Go but I understand the argument.

Re: Where is Ruby Headed in 2021?

#294

Post by joelbluminator »

handrous wrote: post #276
joelbluminator wrote: post #220

Earlier quoted context omitted.

I think people may be traumatised by what happened to Perl or Cobol. They don't want to become obsolete. In reality what happened to Perl isn't the norm imo.

PHP is the more recent one. Folks who worked in PHP but got out at the right time look at all the low-paying PHP jobs (and there are lots of them!) and see mostly-PHP-experience job candidates dismissed out of hand for higher-paying jobs that would offer work experience outside PHP and think "there but for the grace of God, go I".

PHP has declined but its by no means a dead or dying tech. Pay should be good in the good companies (Slack? MessageBird? I am sure there are some big names I dont follow the PHP world that much). What I am saying is that even declining tech can provide stable income for decades. Perl is a different story though. I dont know if the Perl people can still get jobs writing Perl.

Re: Where is Ruby Headed in 2021?

#295

Post by eropple »

zerocount wrote: post #147
abstract_put wrote: post #75

Earlier quoted context omitted.

Do you have any specific examples of things that make JS nice that have been lost because of the popularity of TS? As with types in Ruby, I was under the impression nothing was really lost as TS could be added incrementally as developers saw value. I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost fru…

The dynamic nature of JavaScript is lost when using TypeScript. Although TypeScript can be added incrementally, in practice I've only seen it totally replace JavaScript. While I do believe more people prefer TypeScript over JavaScript, I think it's because those people never deep dived JavaScript or bothered to learn it enough to see how powerful it really is. There are also people that just prefer typed languages an…

I have implemented a JavaScript virtual machine. I feel confident in my knowledge of JavaScript as a language and as an operating environment.

What power am I no longer able to leverage using TypeScript when it's appropriate to do so?

Re: Where is Ruby Headed in 2021?

#296

Post by clairity »

Lio wrote: post #162
clairity wrote: post #127

Earlier quoted context omitted.

to me, this is what makes the upcoming rails 7 release really exciting: no more node, npm, webpack, & yarn! all that js tooling complexity thrown right out the window, replaced with the much simpler set of es6 modules, turbo & stimulus (and maybe strada too).

There seem to a lot of ruby pieces falling into place for Rails 7. The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that. That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now. 1. https://git…

yes, websocket connections/memory use was a problem, will have to take a look at falcon.

i'm personally not a fan of tailwind (or bootstrap) for being overly/cryptically verbose, but i understand why it's popular when coupled with view components, which do seem useful.

Re: Where is Ruby Headed in 2021?

#297

Post by Minor49er »

coldtea wrote: post #257
Minor49er wrote: post #254

Earlier quoted context omitted.

I'm game

OK, let's get it on. I'm bookmarking this. God willing, we can check back in 5 years. Would job postings and TIOBE be enough?

Possibly. I mean, would maintaining legacy applications count towards growth?

Re: Where is Ruby Headed in 2021?

#298

Post by inopinatus »

mypalmike wrote: post #191
inopinatus wrote: post #122

Earlier quoted context omitted.

For that, there's object.method(:name).source object.method(:name).source_location but frankly this is still thinking in a rigid mindset that suits other languages better. Ruby isn't just "dynamic dispatch"; a typical metaprogramming technique handles all incoming calls without named methods, or by dynamically writing the code. To put it bluntly, assuming there's a method on the other side of your message, is practic…

The best features about this bridge are that it's made out of soap bubbles and it doesn't necessarily span the river at any given time. This flexibility is wonderful.

That is not a good metaphor for anything, really: no-one was enlightened; at best some reddit-grade snark was conveyed.

Re: Where is Ruby Headed in 2021?

#299

Post by inopinatus »

rhizome31 wrote: post #156
inopinatus wrote: post #119

Earlier quoted context omitted.

Ruby's dispatch is Smalltalk-like, not Java-like; it is (very) late-bound. The consequences for interface design are dramatic, the natural style being one in which objects notify each other, rather than telling each other what to do, and the result is loose coupling and ease of composition. People trying to write Java-like OO in Ruby end up confused and frustrated.

I've worked with Java, Ruby and Python but I don't get your point. Can you recommend any resource to help understand what you mean? Or maybe some short examples in Python and Ruby that would highlight how implicit imports allow solving problems in a way that explicit imports prevent?

Sandi Metz's talks, and Avdi Grimm's MOOM course.

Re: Where is Ruby Headed in 2021?

#300

Post by JohnBooty »

emodendroket wrote: post #66
JohnBooty wrote: post #49

Earlier quoted context omitted.

I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tri…

> I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh. You're talking like that's rare and not something people constantly do when writing tests in Ruby.

It is of course super common. Unit tests should be stubbing out as much as possible/reasonable.

The presumption is that we're talking about a well rounded test suite with both unit tests and integration tests, and the integration tests would indeed be catching the fact that A is passing entirely the wrong thing to B.

Of course, this does mean we're leaning heavily on the test suite here. But, in any nontrivial application I hope that we would have a robust test suite, right? Otherwise we're going to have some problems whether we're statically or dynamically typed.

Post reply on HN