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

181–190 of 242 posts

Re: Ruby methods are colorless

#181

Post by dragonwriter »

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.

> It's a big neon sign that says "hey, this function call is expensive"

Async and expensive aren't the same thing.

> Also, a nitpick - you can call async functions from sync ones, you just can't access the return value.

That's a quirk of the particular async/await implementation in JS and not generally true of colored-function implementations. (Actually, since async/await is sugar for promises, you can actually, I’m pretty sure, both call and use syntactically async functions from ones which are syntactically not-async if you really want to, the code is just ugly.

Re: Ruby methods are colorless

#182

Post by klysm »

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…

nit: I don't think _expensive_ is quite the right way to think about it. I view it as "hey, this function does IO". The actual cost of doing that IO varies immensely.

Re: Ruby methods are colorless

#183

Post by dragonwriter »

spankalee wrote: post #121
slibhb wrote: post #101

Earlier quoted context omitted.

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 colo…

Using promises is basically no different than using async functions, and definitely doesn't "uncolor" your functions. Any function that calls another that returns a Promise will have to return a Promise to represent completion correctly. That's the color.

> Any function that calls another that returns a Promise will have to return a Promise to represent completion correctly

No, it doesn't, closures let you update values in the wcope of the parent in .then() callbacks and then you can loop in the function and wait for completion and return a non-Promise value.

Re: Ruby methods are colorless

#184

Post by dragonwriter »

wiseowise wrote: post #143
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. Where do you see insanity like this?

Everywhere that hard function coloring exists where the language also supports synchronous calls that do the same thing (JS doesn't support sunchronous calls for lots of things and has only soft function coloring since async is sugar for Promises, so it has two reasons why that doesn't need to happen.)

Re: Ruby methods are colorless

#185

Post by masklinn »

anonymoushn wrote: post #148
masklinn wrote: post #137

Earlier quoted context omitted.

> I think what happened what that JavaScript absolutely necessitated the addition of async/await to avoid callback hell (due to its single-threaded mandate)... just to create a new kind of hell all of its own. It’s not really “a new kind of hell”, there’s a logical progression from callbacks to reified callback (promises) to coroutines, and each step makes concurrency more manageable so you do more of it until you hi…

The alternative isn't preemptive threads, it's coroutines with subroutines that can yield.

Yes, cooperative threading, the worst of all worlds.

Re: Ruby methods are colorless

#186

Post by munificent »

zanellato19 wrote: post #159
munificent wrote: post #82

Earlier quoted context omitted.

It fills me with delight that apparently my lasting contribution to computer science is a piece of writing that also contains the phase "Spidermouth the Night Clown".

Do you still maintain more or less the same opinion from the post?

Yeah, I do, actually.

Dart, which I work on, is still a colored language. And it's like, fine. But I do wish it was colorless. It would make library design a lot easier. There is real friction all the time when doing API design to decide which things should and shouldn't be async.

Re: Ruby methods are colorless

#187

Post by neonsunset »

vips7L wrote: post #169
wiseowise wrote: post #143

Earlier quoted context omitted.

> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible. Where do you see insanity like this?

Everywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().

Because Read and ReadAsync are usually meaningfully different. There is nothing wrong with that.

See https://news.ycombinator.com/item?id=41055328

This bifurcation is mostly a concern for the standard library. It’s not something you do this way in your regular application code.

Re: Ruby methods are colorless

#188

Post by dmux » 

    def log_then_get(url, context)
      puts "Requesting #{url}..."
      get(url, context)
    end
 
    def get(uri, context)
      response = Net::HTTP.get(uri)
      puts caller(0).join("\n")
      response
    end
 
    def get_http_thread(url)
      Thread.new do
        log_then_get(URI(url), Thread.current)
      end
    end
Good example of the downsides of dynamic typing:

1) get_http_thread takes a url (String) and converts it to a URI object

2) log_then_get defines its parameter as `url`, but really its expecting a URI object

3) get defines its parameter as `uri`, but we're passing it an argument called `url` from within log_then_get.

Lots of traps readily awaiting an unsuspecting programmer or newcomer to a project that contains code like this.

Re: Ruby methods are colorless

#189

Post by Glyptodon »

kubectl_h wrote: post #42
thechao wrote: post #15

I've implemented coroutines in C and C++; my preferred multitasking environment is message-passing between processes. I'm not quite sure what the async/await stuff is buying us (I'm thinking C++, here). Like, I get multi-shot stackless coroutines, i.e., function objects, but I don't get why you'd want to orchestrate some sort of temporal Turing pit of async functions bleeding across your code base. I dunno. Maybe I'm…

I work on a large multi-threaded ruby code base and it's always a pain to deal with engineers introducing the async usage in it. Most of the time these engineers don't have a grasp on what fibers are good for and we have to painstakingly review their code and provide feedback that no, it's not magical concurrency, we have a limited number of fix sized connection pools for postgres, redis, memcache, etc available in t…

I wish there were limited forms of true parallelism available with fibers instead of it just being another concurrency construct limited by an interpreter lock. I feel like there should be an in-language construct for stuff that's safely parallel and narrow, and not just Ractors. But I do get that it'd be a footgun for many.

Re: Ruby methods are colorless

#190

Post by RHSeeger »

lmm wrote: post #114
lta wrote: post #98

Earlier quoted context omitted.

> 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…

> The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o). No, source code is where you hide the information, documentation is where you hide misinformation (or accurate information about how the function worked 3 versions ago, which is much the same thing).

The code tells you what the code _does_. The documentation (which can include comments in the code) tell you what the code is intended to do. Either one of those can be wrong. If the code doesn't match the documentation, then there is a bug in the system.

Not having documentation just removes the ability to determine if what the code _does_ is what the code is _intended to do_.

Post reply on HN