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

211–220 of 242 posts

Re: Ruby methods are colorless

#211

Post by mabster »

SleepyMyroslav wrote: post #177
anonymoushn wrote: post #149

Earlier quoted context omitted.

Doesn't it mean you can meet the deadline, but you cannot guarantee that your new textures will be loaded/TLS handshake with login server will be completed/etc. before the deadline happens?

Texture loading and TLS can not meet deadline for sure because we rely on APIs that do not support deadlines. They can only be best effort/background code. The difference I believe is between updating each UI widget and doing something in case of still missing texture or yielding on the texture in some place of UI code and never touching rest of the UI in the frame.

I've always felt this is fine, just as long as there are API calls to preload. Then on one screen you start preloading the next screens while the user is navigating your menus to hide all this latency as much as possible.

Re: Ruby methods are colorless

#212

Post by lolinder »

vlucas wrote: post #202
phplovesong wrote: post #201

Earlier quoted context omitted.

Its a bad feature. The thing is it does not matter if its ”obvious” as anything that touches async needs to be async too. Its a bad paradigm, CSP is obviously a better way to do concurrency. As async is usually only IO bound, but how about CPU bound? In the node ecosystem CPU bound tasks are not something you do with async/await.

In node, you generally don't want to do anything CPU bound.

Yep. If you have CPU-bound work then you should use a different language. If you have IO-bound work then explicitly tagged async functions are actually a really nice concurrency model for the only kind of concurrency you need—it's equivalent to having the Haskell IO monad as a first-class language feature.

Re: Ruby methods are colorless

#213

Post by explaininjs »

jerf wrote: post #162
dumbo-octopus wrote: post #119

Earlier quoted context omitted.

One could theoretically pull out the shared boilerplate to a utility function like: func runTask[T any](task func() (T, error)) chan result[T] { ch := make(chan result[T]) go func() { defer close(ch) res, err := task() ch Does that sort of thing happen much in practice?

Yes, it does, and Go is perfectly capable of it, and many libraries exist for you to choose which exact method suits your problem and temperment. One of the common pasttimes in the threaded versus async debate is to present code in which one side uses all sorts of helpers and patterns and libraries and the other side is presented through writing it "raw". The great-grandparent of my post here is guilty of this. While…

No… I fear you’ve missed the entire point of the matter, which is that async/await requires that you must go all the way up the call stack explicitly “await”ing things when you have introduced an “async” call (or similar wide spread changes to that effect). There’s no special magic utility function you can call you hide it away. That’s the whole point – and a very good thing, this thread argues.

Re: Ruby methods are colorless

#214

Post by lmm »

mmaniac wrote: post #147
lmm wrote: post #117

Earlier quoted context omitted.

So use a language that knows how to be polymorphic over async. Just like you don't want to have to write one version of sort() for each possible array element type, but the solution isn't to make all array elements untyped, the solution is to have a language that can abstract over that.

Can you give an example of a language which is polymorphic in this way and how that looks?

Haskell or Scala are the immediate examples. The idiomatic way to write async-style functions in those languages tends to be do notation or for/yield style. E.g.

    transformFile = do {
      x
is the equivalent of something like:

    async transformFile = {
      x = await readFile(...)
      y = process(x)
      z = await writeFile(...)
    }
In Haskell you write exactly the same code when readFile and writeFile are async, or when they're polymorphically async-or-not, your function will just implicitly be as polymorphic as it possibly can be based on the functions it's calling.

In Scala you need an explicit type parameter if you want to be polymorphic:

    def transformFile = for {
      x
The first example is always async, the second example is polymorphic (it's calling readFile[F] and writeFile[F], but those get inferred).

Re: Ruby methods are colorless

#215

Post by lmm »

throw10920 wrote: post #168
lmm wrote: post #117

Earlier quoted context omitted.

So use a language that knows how to be polymorphic over async. Just like you don't want to have to write one version of sort() for each possible array element type, but the solution isn't to make all array elements untyped, the solution is to have a language that can abstract over that.

Yeah, that's the correct solution. I'm not arguing for the solution, I'm arguing for the problem, because a lot of people seem to think that the problem isn't real.

Sure, but if you put it that way it tends to come across as wanting to not track the distinction at all. Like if you said it's good that values are untyped in Ruby because to write a collection type in C you have to reimplement it for every different type of collection you want: yes, but that doesn't mean values having types is bad, it just means you need polymorphism.

Re: Ruby methods are colorless

#216

Post by lmm »

pmontra wrote: post #136
lmm wrote: post #116

Earlier quoted context omitted.

Unicoloured languages are great as long as your code doesn't have to actually do anything (which is lots of modern code, to be fair). Try writing a physics simulator or 3D renderer in Erlang and see how that goes.

Erlang is not great at math performance, also because it uses arbitrary length integers. There is a nice comparison between several languages, including Erlang at https://stackoverflow.com/questions/6964392/speed-comparison... It all depends on how the code is written. Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your po…

> Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your point. However, how is that related to using sync/async vs message passing?

If you want to write high-performance code then you need to be able to write synchronous code and have control over what your yield points are. If you take the "all calls are potentially async, runtime does what it wants" approach (i.e. "no function colouring") then you just will not be able to do that.

Re: Ruby methods are colorless

#217

Post by kubectl_h »

Glyptodon wrote: post #189
kubectl_h wrote: post #42

Earlier quoted context omitted.

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.

I agree. I've thought about POCing some ractor usage for actual CPU bound workloads but ultimately it would be an academic exercise and most of our engineers aren't even thinking about the code performance on that level.

My beef, if you will, with async (and I realize now I was a little loose in making the distinction between async and fibers) is that engineers reach for async because they are intimidated by threaded code. Instead they are used to the ergonomics of async/await in the browser and think it's basically the same with the async library in ruby and is somehow immune to the considerations you have to make when spawning a thread. This just isn't true. The dragons are mostly the same, or at least they are in our code base.

Re: Ruby methods are colorless

#218

Post by throw10920 »

spankalee wrote: post #198
throw10920 wrote: post #166

Earlier quoted context omitted.

> This unnecessarily trivializes the technical problems at hand. Making a language that automatically generates two versions of a function, one that is async and returns a Promise-wrapped object, and another that is sync, is not hard. > This is exactly what JavaScript did. No, it isn't. JavaScript requires you to declare functions as async at the function definition , and you can't call async functions from sync ones…

If it wasn't hard, it would have been done. I suppose we should all await your backwards compatible proposal? > No, it isn't. Yes, actually, it is. Async functions are a concept that only affects the internal structure of a function - to generate the state machine that allows yielding at `await` keywords and resuming after they resolve. Externally they are no different from "sync" Promise-returning functions. So they…

> If it wasn't hard, it would have been done.

This comment shows a true departure from reality. Computing is filled to the brim with ideas that are easy but are not implemented for reasons other than difficulty.

> I suppose we should all await your backwards compatible proposal?

Your sarcasm merely helps to further demonstrate that you're not interested in a serious discussion.

> Yes, actually, it is.

Then it should be trivial for you to show me an instance of a sync function calling an async one, synchronously waiting for it, then getting back the return value, without clever hacks.

Re: Ruby methods are colorless

#219

Post by anonymoushn »

masklinn wrote: post #185
anonymoushn wrote: post #148

Earlier quoted context omitted.

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

Yes, cooperative threading, the worst of all worlds.

imo we should reify more capabilities in the type system. you shouldn't be able to call Math.random without all of your transitive callers declaring at the call site that you plan to do that.

Re: Ruby methods are colorless

#220

Post by moralestapia »

moralestapia wrote: post #173
anonymoushn wrote: post #79

Earlier quoted context omitted.

If you program with promises and without async/await, then your language is still missing something compared to languages that have coroutines in which functions that suspend and do not suspend may be composed (used by higher-order functions, etc.) in the same ways as each other. You've moved from the situation where both types of functions were present and must be handled differently to the situation where one type…

Can you give an example?

Nope.

  - anonymoushn
Post reply on HN