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

91–100 of 360 posts

Re: Where is Ruby Headed in 2021?

#91

Post by 88913527 »

Scarbutt wrote: post #26
navaneethpk wrote: post #24

We recently migrated ToolJet ( https://news.ycombinator.com/item?id=27421408)'s server from Ruby ( Rails ) to TypeScript ( Nest.js ). Our goal was to have only one language in our stack so that it will be easy for the open-source contributors. I have been working as a Ruby dev since 2015 and I really love Ruby. Initially I thought we might miss a lot of things when we switch to TS. But it turned out to be a great dec…

Honestly typeorm and nestjs are pretty bad.

NestJS has some pretty horrific default settings, like a max 1MB request payload size. And you have to write custom content-type processors for anything other than 'application/json'. So if you're doing say, file upload's over 1MB, you already have to make 2 configuration changes. But you wouldn't assume that OOTB 1 MB file upload isn't supported for what claims to be a full nuts-and-bolts web application framework.

Re: Where is Ruby Headed in 2021?

#92

Post by Mikeb85 »

friedman23 wrote: post #41
Mikeb85 wrote: post #8

Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).

> Honestly I don't get why some people want to move to static types I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, th…

> People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time.

You just develop on the running program... If you just write it in your editor, run, check for errors, stop, edit more, run, stop, etc... then yes, you don't gain anything.

Re: Where is Ruby Headed in 2021?

#93

Post by dragonwriter »

fastball wrote: post #64
tambourine_man wrote: post #43

Earlier quoted context omitted.

> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch…

When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.

> The argument has always been whether or not the price of that correctness is too high.

No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time.

> But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.

If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.

Re: Where is Ruby Headed in 2021?

#94

Post by bcrosby95 »

eldavido wrote: post #70
HeyImAlex wrote: post #52

Earlier quoted context omitted.

It’s not that they’re fashionable, it’s that their ergonomics have improved significantly over the past decade. I saw dynamic types as a response to cumbersome static type systems, but increasingly type systems are becoming more expressive and less cumbersome.

Yeah, this is how I see it, too. Sort of a gradual convergence. On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List () rather than having to stupidly repeat the type e.g. List x = new List (). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10…

But C# has had everything you've listed for over 10 years. Along with a great IDE that has provided very useful intellisense since pretty much the beginning.

Re: Where is Ruby Headed in 2021?

#95

Post by JohnBooty »

whakim wrote: post #78
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…

In my experience this here (usually some method unexpectedly getting passed `nil`) is the single biggest class of bugs in production Ruby applications. Also, what happens when you don't get a NoMethodError? Duck typing is an extremely common practice in Ruby, which means that you can easily run into situations where code "runs" but the output is nonsensical.

    In my experience this here (usually some 
    method unexpectedly getting passed `nil`) 
    is the single biggest class of bugs in 
    production Ruby applications.
Right, but how do tests help you here?

Your specs aren't passing those unexpected nils, and if they were, your specs would fail on the resulting NoMethodError.

Static analysis can find these potential problems in a statically typed language - I miss the days when Resharper would let me know about potential nulls/nils. That's a strong argument for static typing. But, this particular comment thread is about addressing this class of bug in Ruby via tests, and my vote would be generally no.

    Duck typing is an extremely common practice 
    in Ruby, which means that you can easily run 
    into situations where code "runs" but the output 
    is nonsensical.
I've been working with Ruby full time for years (admittedly, mostly boring CRUD Rails apps) and I've just never found this to be a problem. It obviously can happen, but I just don't see those name collisions ever happening.

Re: Where is Ruby Headed in 2021?

#96

Post by Mikeb85 »

fastball wrote: post #64
tambourine_man wrote: post #43

Earlier quoted context omitted.

> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch…

When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.

> it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.

Ruby has a pretty nice language server, nice linter, REPL (Pry), many other tools.

The best development experience IMO is still stuff like SLIME or Smalltalk environments.

"Intellisence" just makes using statically typed languages bearable. It's not a unique feature.

Re: Where is Ruby Headed in 2021?

#97

Post by antod »

jamesfinlayson wrote: post #59
pcwalton wrote: post #56

Personally, I still haven't really found a better tool for little one-off throwaway scripts than Ruby. Python's always been verbose for me and lacks the awk heritage that makes text processing tasks so easy. Node forces me to deal with async I/O. Shell has annoying quoting rules. I don't feel strongly about any of this and if another language is your favorite for small one-offs, that's great. Ruby works well for me t…

Agreed - I really like Python but the ease with which you can do a Ruby one-liner on the command line makes it just that bit nicer.

I'm in the same boat. The syntax sugar for shell integration in quickly hacked up scripts is the main (only?) area I prefer Ruby over Python.

Re: Where is Ruby Headed in 2021?

#98

Post by valenterry »

prescriptivist wrote: post #86
Buttons840 wrote: post #74

Earlier quoted context omitted.

> I’ve tried python, but I end up having to deal with the mess of importing modules Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called? If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both…

Those are fair points, but I just kind of hold the entire program space in my head. I work on a pretty large and complicated Rails app that does real world things (handle money, deal with people and companies, etc) and it's daunting at first but after a while it's sort of become one big system of objects interacting with other objects in a global objectspace and that's how it exists in my head. I think for people tha…

I think this is actually a very efficient way of programming. but it doesn't scale in project size and team size. Similar for Lisp. This is why these languages are really good for prototyping, but not as good anymore for big, longterm projects imho.

That's also why I don't think it's a great idea to add types etc. to programming languages like python or ruby. They are not made for this and they should focus on what they do well. Use the right tool for the job, don't try to make every tool being able to be used for the same task.

Re: Where is Ruby Headed in 2021?

#99

Post by skunkworker »

hello_moto wrote: post #7
Gigachad wrote: post #5

Earlier quoted context omitted.

Ruby on rails still hasn't peaked yet so I'm not sure what you mean by the tail end. Rust micro services might be the new trend for big tech but there would be more rails apps in development now than there ever has been.

> Rust micro services might be the new trend Golang is the trend. (I don't have any opinion in either Golang or Rust; but most jobs out there are looking for Golang microservice deployed in K8S)

This is more accurate, where I work we are a predominantly ruby shop actively using JRuby in production for a number of years, though in the last year or so we have been adding Go based RPC servers in addition to our Ruby RPC servers. We've been converting over the simple ones that are utilized the most (mainly reads) and ones that have logic that won't change often.

But day to day I use JRuby and Go quite often, and in the process of converting some Ruby code over to Go, for specific performance, dependency and memory reasons.

Re: Where is Ruby Headed in 2021?

#100

Post by revskill »

I see Ruby and RoR is the best gateway to become a senior fullstack engineer.

I've seen some folks dealing with Java, NodeJS, Python as their first (and only) tech stack and they never become a senior developer one.

So, what i love the most from Ruby and RoR is how it helps you on your career path to become a better engineer in a concise way that no other framework/languages can offer you.

Learn from what the Ruby/RoR teach you in a short timespan and you'll see the whole new world of real world programming.

From my story: I started with Ruby and RoR in 2 years then i can master all other languages, framework in NO time. All concepts are there, learnt from Ruby/RoR already. No need to re-learn new things to get the job done in your future tech stack.

Post reply on HN