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

281–290 of 360 posts

Re: Where is Ruby Headed in 2021?

#281

Post by billybones123 »

saghm wrote: post #77
eloisius wrote: post #6

The RBS files seem like a weird compromise to me. I I'm not sure I see the practical benefit, but maybe someone who has used .d.ts files can explain it. Is it just helpful if your IDE has tooling to use it? Seems like it could be helpful, but also sounds like it will become an annoying "code quality" hoop those of us that don't use VSCode will have to jump through for little benefit. When you read code outside of you…

I think the idea is that it lets you provide type definitions for external libraries. I've never used TypeScript before, but I've heard from friends who use it that sometimes people will write type definitions for third-party libraries whose original authors might not have the time or interest to do it themselves. Basically, it lets you use an arbitrary JS library as though it's properly typed, as long as the maintai…

This is the use case that I'm familiar with. For packages that don't bundle types, type definitions are often available through DefinitelyTyped[0].

  npm install --save-dev @types/node
> The types should then be automatically included by the compiler

[0] https://github.com/DefinitelyTyped/DefinitelyTyped

Re: Where is Ruby Headed in 2021?

#282

Post by oblio »

dnautics wrote: post #261
oblio wrote: post #202

Earlier quoted context omitted.

Plus these companies tend to have tens of techs stacks and hundreds of projects, you never know if what they're highlighting isn't some small internal project used by just one team and developed by more or less a lone wolf developer, with the project on life support after said developer left the company.

Pepsico and Toyota are sponsors for elixir events on the regular.

Nice!

Re: Where is Ruby Headed in 2021?

#283

Post by tonyedgecombe »

phyrex wrote: post #238
mypalmike wrote: post #197

Earlier quoted context omitted.

My favorite recent discovery is calling a js function with too many or too few parameters. It'll just go ahead and do it.

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.

Re: Where is Ruby Headed in 2021?

#284

Post by handrous »

Scarbutt wrote: post #40
whakim wrote: post #17

Earlier quoted context omitted.

Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.

dramatically reducing the number of bugs you write. I would say that's a big overstatement.

It's not, because "bugs you write" includes bugs that don't make it to production. I doubt there's a programmer who's worked in a language without static types who's not familiar with the "write, run, read error, find silly bug, fix silly bug, repeat" development loop. Usually it becomes second nature.

Re: Where is Ruby Headed in 2021?

#285

Post by handrous »

mykowebhn wrote: post #104
hsn915 wrote: post #72

Earlier quoted context omitted.

I started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++. Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs. What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to…

Have you wrangled with JSON using Go? Absolutely dreadful. Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with…

> Have you wrangled with JSON using Go? Absolutely dreadful.

Yes. Of course it's dreadful. It's JSON. It's way better in Go than Ruby or Javascript, though.

Re: Where is Ruby Headed in 2021?

#286

Post by whakim »

joelbluminator wrote: post #195
whakim wrote: post #76

Earlier quoted context omitted.

I don't think that static typing obviates the need for tests. However: * Static typing catches many kinds of bugs earlier by simply not allowing you to write incorrect code in the first place. * No matter how good your test suite is, you're still putting the burden on the human to always remember to write tests for corner cases. * Static typing allows you have to write many fewer tests by making invalid data unrepres…

> Static typing allows you have to write many fewer tests by making invalid data unrepresentable. You don't have to write millions of unit tests of the type "what if this list is empty" if the function literally can't accept an empty list. We just don't write these kind of tests on our Rails codebases and we are fine. The world hasn't exploded yet anyway. If some piece of code is super tricky and sensitive then sure…

I'm surprised that you never have bugs of the type "this thing is nil and I didn't expect it to be". This is by far the most common type of bug I see in production Ruby applications and it simply can't happen with something like Sorbet.

Re: Where is Ruby Headed in 2021?

#287

Post by whakim »

BurningFrog wrote: post #223
whakim wrote: post #76

Earlier quoted context omitted.

I don't think that static typing obviates the need for tests. However: * Static typing catches many kinds of bugs earlier by simply not allowing you to write incorrect code in the first place. * No matter how good your test suite is, you're still putting the burden on the human to always remember to write tests for corner cases. * Static typing allows you have to write many fewer tests by making invalid data unrepres…

If you do TDD, you catch bugs before the code is even written. I don't write a million tests. There are much better strategies for testing. Simple tests that just executes the code will catch the vast majority of type mistakes.

If you're just testing pieces of code in isolation, then you're either writing lots of tests or making assumptions about the kinds of input that your function could reasonably receive or return. If you're testing end-to-end, you're either writing lots of (much more expensive) tests or you're missing corner cases. I don't think that's problematic per se. Testing is just a bit of a mismatch for the problems that type systems solve.

Re: Where is Ruby Headed in 2021?

#288

Post by joelbluminator »

whakim wrote: post #286
joelbluminator wrote: post #195

Earlier quoted context omitted.

> Static typing allows you have to write many fewer tests by making invalid data unrepresentable. You don't have to write millions of unit tests of the type "what if this list is empty" if the function literally can't accept an empty list. We just don't write these kind of tests on our Rails codebases and we are fine. The world hasn't exploded yet anyway. If some piece of code is super tricky and sensitive then sure…

I'm surprised that you never have bugs of the type "this thing is nil and I didn't expect it to be". This is by far the most common type of bug I see in production Ruby applications and it simply can't happen with something like Sorbet.

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

Re: Where is Ruby Headed in 2021?

#289

Post by chespinoza »

MrWiffles wrote: post #245
chespinoza wrote: post #228

Earlier quoted context omitted.

I wonder why Crystal is not more popular today that it reached 1.X, as you say, it fixes some important Ruby issues but most importantly it also fixes Elixir's weaker points.

I can't comment on the Elixir stuff since I haven't really touched it at all yet (only ever seen one job opening in hundreds over 5+ years mentioning Elixir - only one, total!). But I have a theory on the rest... I think the actual reason why it's not more popular is something I personally call "The Tyranny of the Masses". In short, what's popular/flavor-of-the-month is automatically "right", and everything else is a…

In all these years the only thing I've seen has been despise against JS, if it was popular it was 'cause we hated it, we hated how bad designed it was, but then Node appeared and someone said that isomorphic JS would be a good idea as looking for backend engineers would be easier. Now there are tons of JS libs in npm, but a big percentage are quite minimal, unnecessary and of questionable quality.

Re: Where is Ruby Headed in 2021?

#290

Post by whakim »

joelbluminator wrote: post #288
whakim wrote: post #286

Earlier quoted context omitted.

I'm surprised that you never have bugs of the type "this thing is nil and I didn't expect it to be". This is by far the most common type of bug I see in production Ruby applications and it simply can't happen with something like Sorbet.

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.

Post reply on HN