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

231–240 of 242 posts

Re: Ruby methods are colorless

#231

Post by moralestapia »

anonymoushn wrote: post #223
moralestapia wrote: post #173

Earlier quoted context omitted.

Can you give an example?

An example of a language or of a program? You could try Lua, Python with greenlet, Zig 0.10.0 or Zig master with zigcoro, dozens of libraries that add this sort of capability to C, or becoming a the kind of person who uses search engines when they have questions. BulletML is not even Turing complete and still has a wait function that does the exact thing mentioned.

>or becoming a the kind of person who uses search engines when they have questions

Just FYI, please become familiar with this site's guidelines before posting [1]; try to make @dang's work a bit easier.

>An example of a language or of a program?

A small code snippet would suffice, any language of your choice that gets the point across more meaningfully. Something like:

  function() {
    // code that shows feature
  }
"... and this is the functionality that you're missing on Javascript".

1: https://news.ycombinator.com/newsguidelines.html

Re: Ruby methods are colorless

#232

Post by anonymoushn »

moralestapia wrote: post #231
anonymoushn wrote: post #223

Earlier quoted context omitted.

An example of a language or of a program? You could try Lua, Python with greenlet, Zig 0.10.0 or Zig master with zigcoro, dozens of libraries that add this sort of capability to C, or becoming a the kind of person who uses search engines when they have questions. BulletML is not even Turing complete and still has a wait function that does the exact thing mentioned.

>or becoming a the kind of person who uses search engines when they have questions Just FYI, please become familiar with this site's guidelines before posting [1]; try to make @dang's work a bit easier. >An example of a language or of a program? A small code snippet would suffice, any language of your choice that gets the point across more meaningfully. Something like: function() { // code that shows feature } "... a…

I think there's a reasonable motivating example at https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html, but not a reasonable implementation. A reasonable implementation for C is at https://github.com/creationix/libco and for Zig at https://github.com/rsepassi/zigcoro.

For a real world example, https://github.com/alexnask/iguanaTLS is a TLS library written in terms of the stdlib's reader and writer interfaces. If the read and write methods of the provided reader and writer are normal, non-async functions, then the library's functions are too, and they can be used in a program that does not have an async runtime. If they are async functions, then the library's functions inherit this property, and they can be used in a program that uses async I/O. They could also be used in both modes in the same program, though I can't think of a good reason to do this. Normally in Javascript the consumers of your library would all be imprisoned within an event loop provided by node or the browser, so there would be no point exposing a synchronous variant, but for example see https://nullderef.com/blog/rust-async-sync/ for someone's experience trying to write a library that exposes the same functionality both ways in some other language.

Re: Ruby methods are colorless

#233

Post by explaininjs »

jerf wrote: post #229
ackfoobar wrote: post #193

Earlier quoted context omitted.

I don't like that the return values of the tasks has to be communicated with side effects, but I'll concede that it's quite painless. I guess I'm just still salty when someone commented (in another post a long time ago) that golang only has `go` (compared to `launch`, `async`, and `coroutineScope` in Kotlin) and is simpler. > All the languages in question are perfectly capable of abstractions. I don't think async fun…

"I don't like that the return values of the tasks has to be communicated with side effects, but I'll concede that it's quite painless." Me neither, however, it is generally the most flexible approach and I can see why a library takes it. If you want to communicate it via the return, you also have to impose a restriction that the tasks all return the same type. I think it makes sense for a library to work this way bec…

If you’re fine with manually checking a standard interface to see if you should abort, JS’s answer is the AbortController. This is supported by features like the “fetch” function for making cancellable http requests.

https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

Re: Ruby methods are colorless

#234

Post by goatlover »

igouy wrote: post #200
goatlover wrote: post #89

Earlier quoted context omitted.

Bit of a strong claim when the Erlang/OTP was designed to handle massive concurrency without colorful methods. Given that both Erlang and Ruby are inspired by the message passing semantics of Smalltalk.

> … Erlang … inspired by the message passing semantics of Smalltalk. What makes you think that?

The Wikipedia entry says Smalltalk was one of it's influences and Joe Armstrong, co-developer of Erlang, mentions message passing as the fundamental aspect of OOP that Erlang gets right.

Re: Ruby methods are colorless

#235

Post by moralestapia »

anonymoushn wrote: post #232
moralestapia wrote: post #231

Earlier quoted context omitted.

>or becoming a the kind of person who uses search engines when they have questions Just FYI, please become familiar with this site's guidelines before posting [1]; try to make @dang's work a bit easier. >An example of a language or of a program? A small code snippet would suffice, any language of your choice that gets the point across more meaningfully. Something like: function() { // code that shows feature } "... a…

I think there's a reasonable motivating example at https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html , but not a reasonable implementation. A reasonable implementation for C is at https://github.com/creationix/libco and for Zig at https://github.com/rsepassi/zigcoro . For a real world example, https://github.com/alexnask/iguanaTLS is a TLS library written in terms of the stdlib's reader and writer interfac…

I see your point.

What I would do on JS is ...

... on the lib. side, code a single function that behaves the same when meant to run sync or async.

... on the client side, just await the function every time is called; if the sync version is running you don't return a Promise and await-ing on primitives is free, the program will lock automatically if needed.

Obviously, the trivial solution would be two different methods that do the same thing (as is the case now with things like readFile and readFileSync) but I agree that's not elegant.

Re: Ruby methods are colorless

#236

Post by igouy »

goatlover wrote: post #234
igouy wrote: post #200

Earlier quoted context omitted.

> … Erlang … inspired by the message passing semantics of Smalltalk. What makes you think that?

The Wikipedia entry says Smalltalk was one of it's influences and Joe Armstrong, co-developer of Erlang, mentions message passing as the fundamental aspect of OOP that Erlang gets right.

The Wikipedia "Influenced by Lisp, PLEX,[2] Prolog, Smalltalk" seems to be un-sourced !

> … Joe Armstrong … mentions message passing …

Where?

Re: Ruby methods are colorless

#237

Post by asp_hornet »

explaininjs wrote: post #80
asp_hornet wrote: post #73

Earlier quoted context omitted.

Only if those doSomething methods were written as asynchronous to begin with.in your original example, doSomethingA was simple, why would it be an async method. If your answer is write every method async for a rainy day, then whats the point.

No… that’s the whole point. If you change them to be async, the language forces you to go and rethink what implications that has for the callers. This is a good thing, dumbly sequenced operations are terrible UX. And UX is far more important than whatever it is they call “DX”.

I’d rather just stick to languages that don’t have colored functions. You don’t need to be forced to think about this. Your tools manufactured this issue.

Re: Ruby methods are colorless

#238

Post by vips7L »

wiseowise wrote: post #224
vips7L wrote: post #203

Earlier quoted context omitted.

Right that solves the problem if you can block. But in applications that are async everywhere, like a web app, you end up having to mark everything as suspend all the way up the chain.

Which is fine?

Not really, but we can agree to disagree.

Re: Ruby methods are colorless

#239

Post by igouy »

goatlover wrote: post #234
igouy wrote: post #200

Earlier quoted context omitted.

> … Erlang … inspired by the message passing semantics of Smalltalk. What makes you think that?

The Wikipedia entry says Smalltalk was one of it's influences and Joe Armstrong, co-developer of Erlang, mentions message passing as the fundamental aspect of OOP that Erlang gets right.

Here's something Joe Armstrong's PhD thesis does reference in the context of message passing:

"4.5 Programming Notations Based on Message Passing" p33

"Concepts and Notations for Concurrent Programming", Gregory R. Andrews and Fred B. Scheider, Computing Surveys 15(1) March 1983, pp 3 - 43

[pdf] https://www.cs.cornell.edu/fbs/publications/LangSurv.pdf

Re: Ruby methods are colorless

#240

Post by Kamq »

dumbo-octopus wrote: post #119
Kamq wrote: post #105

Earlier quoted context omitted.

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

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?

You can, but I didn't want to introduce any extra constructs from the original example.

And this is a bit of a weird case, at least where I am. I tend to have a bunch of things to process and have one goroutine sending keys/indices/etc to a channel that multiple workers are processing off of.

We did have an abstraction for that at one point, but there were enough edge cases in our domain that we either had to develop a config system or rip it out and go back to writing each one (we went with the latter after an attempt at the former went really bad).

Post reply on HN