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

Ruby methods are colorless

jpcamara.com

Post reply on HN
Print view View original

101–110 of 242 posts

Re: Ruby methods are colorless

#101

Post by slibhb »

lta wrote: post #98
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

> is a feature I was quite shocked to read this, as in it never brushed my mind that it could be. I personally doesn't feel like it is and is one of the reasons why I try to avoid working with that stack at all cost. I don't think the neon sign is a good excuse for the mess colored functions are. You easily can create a synchronous O(n^4) function, and there are probably tons of quick async functions. Moreover, your…

Async/await is clearly a feature in JS, though not for the reason the previous poster mentions. Async/await wasn't part of the language until 2017. If you don't like it, you can just use Promises. If you do that, there are no "colored function" (functions of color?).

As far as the article goes, I think the pattern in Ruby is great. I prefer it to JS. But the JS approach works fine and the whole controversy about colored functions is a little silly.

I would be interested in understanding why JS can't enable await from inside non-async functions. I (maybe naively) wonder if the compiler couldn't just figure out which functions to treat as async rather than making the programmer do it.

Re: Ruby methods are colorless

#102

Post by rco8786 »

newZWhoDis wrote: post #85
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

Ruby/rails is full of shortsighted crap like this. I feel stuck, our whole backend is legacy rails and I can’t escape.

Legacy codebases that are a joy to work with are few and far between, in any language.

Re: Ruby methods are colorless

#103

Post by akoboldfrying »

vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

It's a big neon sign that says "Either this function is expensive, or it isn't but some framework somewhere that sometimes needs to call expensive functions might also need to call this function using the same syntax".

Re: Ruby methods are colorless

#104

Post by segfaltnh »

newZWhoDis wrote: post #85
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

Ruby/rails is full of shortsighted crap like this. I feel stuck, our whole backend is legacy rails and I can’t escape.

Rails doesn't scale well in my experience. Or maybe rails devs don't scale well.

The language and framework are both centered around developer happiness, which in my experience drops off around 10,000 lines. That's about when projects start getting difficult.

Re: Ruby methods are colorless

#105

Post by Kamq »

hombre_fatal wrote: post #33
explaininjs wrote: post #27

Earlier quoted context omitted.

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code: a := &blah{} rA, err := engine.doSomethingWithA() b := &bloop{} rB, err := engine.doSomethingWithB() This might have started out with both the doSomethings being v…

Of course, the other nice thing about the JS example compared to Go is that it's trivial at the callsite to do this: const [[rA, errA], [rB, errB]] = await Promise.all([ engine.doSomethingWithA(), engine.doSomethingWithB() ]) At least these days you can ask an LLM to write the WaitGroup boilerplate for you in Go.

Yeah, go's a little boilerplatey, but you have to option to run two sync things concurrently as well with something like:

    type result[T any] struct {
        el T
        err error
    }
    chanA := make(chan result[aResultType])
    chanB := make(chan result[bResultType])
    go func() {
        defer close(chanA)
        a := &blah{}
        rA, err := engine.doSomethingWithA()
        chanA

Re: Ruby methods are colorless

#106

Post by CGamesPlay »

throw10920 wrote: post #95
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

> Knowing ahead of time which functions are async is a feature. "Expensive" is subjective and should be up to the programmer to decide. And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. > This is a good thing for programmers to easily see and know at the call site. Yes, and the IDE can show you that informati…

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.

I'm afraid I don't follow. It's impossible for you to have two identical functions (one sync and one async), since then they would both be sync. What did you mean?

Re: Ruby methods are colorless

#107

Post by throw10920 »

mattigames wrote: post #100
throw10920 wrote: post #95

Earlier quoted context omitted.

> Knowing ahead of time which functions are async is a feature. "Expensive" is subjective and should be up to the programmer to decide. And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. > This is a good thing for programmers to easily see and know at the call site. Yes, and the IDE can show you that informati…

Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us, why have underscore at the beginning of private variables? We can let the IDE do that, we even have long named functions instead of single letter ones? Most IDEs can read the jsdocs and give us a long description of what every function does, and I could go on and on. At the end it's…

> Why have Json? We can always use binary to save a lot of space and bandwidth and the IDE will always compile it into plain text for us

Yes, this is a great idea, and people would do it if there was widespread support for a binary structured format.

The difference between this incredibly ignorant sarcasm and my point is that IDEs already support the thing that I'm suggesting. You can already hover over a method and it'll give you information about the types of the arguments and return values that are specific to the call site.

> At the end it's a balance and subjective preferences

...and you completely missed the main point of my comment, which was not about what information to show, but avoiding duplication due to function coloring:

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem

Re: Ruby methods are colorless

#108

Post by throw10920 »

CGamesPlay wrote: post #106
throw10920 wrote: post #95

Earlier quoted context omitted.

> Knowing ahead of time which functions are async is a feature. "Expensive" is subjective and should be up to the programmer to decide. And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. > This is a good thing for programmers to easily see and know at the call site. Yes, and the IDE can show you that informati…

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. I'm afraid I don't follow. It's impossible for you to have two identical functions (one sync and one async), since then they would both be sync. What did you mean?

Two functions that are identical up to one of them being async and using "await" to call another function foo_async, and the other that is sync and calling foo_sync (a synchronous version of foo_async) without await?

Re: Ruby methods are colorless

#109

Post by throw10920 »

BiteCode_dev wrote: post #26
throw10920 wrote: post #20

Earlier quoted context omitted.

> fully colorless for async means you don't know when things are async or not The IDE can tell you.

Given Ruby culture of monkey patching, not always. Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.

If you monkey patch, you get what you paid for - and an annotation at the call site or definition wouldn't help anyway!

If not, then we should be able to use the type annotations that are being added to also indicate async-ness.

If people decide to code Ruby "blind" (without a smart IDE), then that's their choice. There's no reason why someone using an IDE should have to pay for their decisions. We don't force people to manually and redundantly add names and types of parameters to call sites - it makes equally little sense to do the same for async. If someone decides to use a dumb IDE, then they can read the docs, exactly the same as they do for function parameters.

Re: Ruby methods are colorless

#110

Post by t-writescode »

goatlover wrote: post #91
stephen wrote: post #53

Maybe its Stockholm syndrome after ~4-5 years of TypeScript, but I like knowing "this method call is going to do I/O somewhere" (that its red). To the point where I consider "colorless functions" to be a leaky abstraction; i.e. I do a lot of ORM stuff, and "I'll just call author.getBooks().get(0) b/c that is a cheap, in-memory, synchronous collection access ... oh wait its actually a colorless SQL call that blocks (s…

Don't you generally know when you're making an I/O call?

Not when I'm using some library function that's "helpful"
Post reply on HN