Re: Pike in the News
On Mon, 23 May 2022 at 05:28, wrote:
> b) Where's the source code?
>
> Here, I actually sort of agree that there's a discoverability problem.
Yeah, more than sort-of for me; I can't really just link someone to
the landing page and assume that they'll be able to find everything.
Not sure that it counts as low-hanging fruit, but it's certainly fruit
if someone wants to put in some effort.
> Some things I found really interesting:
>
> a) Concurrency, ie the GIL
>
> What are the ways for improving concurrency, and how big of a problem is
> it? I'm sure it can be a real problem, just wondering if anyone has any
> experience probing what they are? Aside from unlocking in c-language
> modules, seems like the solutions for single-process improvements are
> pretty invasive. Is there an opportunity to provide some tooling to
> allow tasks to be spread across a number of pike processes in order to
> get around the GIL? I did some work with zeromq, which positions itself
> as a way to improve concurrency without the risks of multi-threading.
> Perhaps some sort of pike clustering module/etc could provide
> performance improvements?
Removing the GIL? I think that that's likely to be a major issue,
given how hard it is to do it in CPython. Or rather, given that every
attempt to remove the GIL from CPython has resulted in enough of a
performance hit for single-core work that it's simply not worth the
cost.
There was some work being done a while ago on memory arenas, where
different threads could have their own address spaces, and thus their
own independent locks; the GIL would then only be needed for guarding
access to global/shared objects. Did that go anywhere?
Another thing that I'd love to see, in terms of concurrency, is some
enhancements to asynchronous I/O. Pike currently *far* outstrips
Python in the convenience of going to a back-end event loop (just
return -1 from main(), where in Python you have to play around with
the asyncio module); but on the flip side, Python has actual native
support for async functions, and Pike only recently gained the
underlying structure of continue functions. If I could just dream for
a bit, here's what I'd love to see in Pike:
1) Asynchronous functions are declared to return their "ultimate"
return value, but can always yield a Concurrent.Future without needing
to declare this. Currently, I use declarations like this:
continue mapping|Concurrent.Future some_function(...) { ... }
which is just noise - in reality, it will only ever "return ([...])"
and only ever "yield some_future".
2) A built-in function that tells you whether something is a continue
function, a continuation function, or a regular function. I currently
use this hack to recognize when it's the special function returned
from a continue function, but there's no way to know about the other
two:
int(0..1) is_genstate(mixed x) {return functionp(x) &&
has_value(sprintf("%O", x), "\\u");}
Even better if it can indicate that a continuation function has
finished. (Or maybe that's a separate function.) That would, with no
ambiguity, tell you whether the last thing it did was "yield" or
"return". Currently, the only way to tell is to call the function
again and see if you get back a 0, which is not guaranteed anyway,
since it could yield 0.
3) Minor, but an easier way to raise an exception into a continue
function. Currently, the way to do that is:
resp = gen(0) {throw(err);};
and I don't think that's very obvious. A direct way to throw something
into the continue function like "raise_in(gen, err)" would make that
clearer, and hopefully more efficient (the convenient shorthand that I
used there, since it's implicit-lambda, is probably quite
inefficient).
4) A function (probably in the Concurrent module) that takes all of
the above and wraps up the logic of repeatedly calling a generator
function with the results of a promise. The way I've implemented it is
the spawn_task class here:
https://github.com/Rosuav/StilleBot/blob/master/globals.pike#L150
(Line number might be wrong in the future, as that's a live project
and does see changes on a regular basis.)
With all of those features, the language itself would have great
concurrency support, and you could simply call
Concurrent.spawn(some_func()) to set an asynchronous operation going.
> b) Embedded/embedding
>
> 2 possible meanings here;
>
> a) embedding a pike interpreter in another program, which is possible
> and I've shipped several projects that use this. Don't think this would
> be of interest to most people, but could be made a lot nicer with just a
> little effort.
>
> b) running some variant of a pike interpreter on microcontroller scale
> devices (Ala micropython, etc). Potentially huge audience, but seems
> like the pike interpreter isn't really suited to being scaled down to
> fit/run: a pretty hefty controller would be necessary and without a real
> os and limited ram, you'd probably give up a lot of the things that pike
> excels at: networki
Re: Pike in the News
I always enjoy reading through discussions like this to see if there's anything to be learned. Obviously, a lot of the comments are familiar and center around: a) I already have a preferred language, why would I ever learn something that isn't already in use by a large percentage of the programming population? b) (probably a corollary) the community is so small, I would need to actually do some learning and write some code rather than swipe answers from google and pip/npm a module! I don't really think there will ever be a satisfactory answer for these folks, and that's fine. I will note the sometimes comical complexity invoked by people using node, for example. Developing a simple application can easily pull in 700 external modules from npm. I also have to wonder what leads a language community to have a very popular module with one method, that returns the lower case version of a string... did the language not provide such a feature out of the box? Did someone publish that as a means for learning about the module ecosystem (reasonable, even laudable!) and no one noticed it wasn't necessary? Was it a huge joke? Who knows? For better or worse, if you choose to use pike, you will be somewhat forced (and rewarded) if you do your homework... the vast majority of potential users will be eliminated right there. There were some questions about "tooling" which are potentially interesting: a) We like mod_php! We like web development frameworks! Where is any of this? I've tried to keep lists of these sorts of solutions but because they're not linked to from the main pike site, it's almost impossible to find them. mod_php like functionality via FCGI/SCGI/Relaying exists, as does the ability to embed Pike code in pages just like b) Where's the source code? Here, I actually sort of agree that there's a discoverability problem. Even now, after decades of experience with the website, I always have to stop and think about where the read-only link is. Most of the links on the sub ribbons seem almost invisible to me. Could something be done to make it easier to find? Seems pretty common for that to be on the front page, or at worst the top of the development page. I imagine the project pays a price for not being GitHub-first, but making the repository location, etc easier to find would be useful for everyone, I think. c) No discussion forum? No chat room? A mailing list, how retro! Aside from people not reading text that's very clearly present, I do note that the dev mailing list link is broken. Would it also be reasonable to include a link to the mailing list archive at mail-archive.org? It seems that the back-messages never got loaded, but current messages seem to be present. I assembled a fairly complete archive of the messages back in time, if anyone has an idea for how that could be made available (and googlable)? Some things I found really interesting: a) Concurrency, ie the GIL What are the ways for improving concurrency, and how big of a problem is it? I'm sure it can be a real problem, just wondering if anyone has any experience probing what they are? Aside from unlocking in c-language modules, seems like the solutions for single-process improvements are pretty invasive. Is there an opportunity to provide some tooling to allow tasks to be spread across a number of pike processes in order to get around the GIL? I did some work with zeromq, which positions itself as a way to improve concurrency without the risks of multi-threading. Perhaps some sort of pike clustering module/etc could provide performance improvements? b) Embedded/embedding 2 possible meanings here; a) embedding a pike interpreter in another program, which is possible and I've shipped several projects that use this. Don't think this would be of interest to most people, but could be made a lot nicer with just a little effort. b) running some variant of a pike interpreter on microcontroller scale devices (Ala micropython, etc). Potentially huge audience, but seems like the pike interpreter isn't really suited to being scaled down to fit/run: a pretty hefty controller would be necessary and without a real os and limited ram, you'd probably give up a lot of the things that pike excels at: networking, file I/0, etc. Could be really interesting to see what the smallest device you could run a real OS and pike on and tailor that to embedded development. Ie, can you do it with a device you can get for 10 currency units reliably? I'd certainly be willing to put some cycles toward that if there's interest. c) Runtimes: JVM, WASM, etc Probably not ever going to happen, but wouldn't it be nice if it did? I feel like there is some low hanging fruit that could at the very least make life easier for the random person who ends up on the Pike website: a) fixing broken links b) making the repository easier to find c) how about a faq? all of these things come up from time to time, a
Re: Pike in the News
On 5/20/22 7:54 PM, Duke Normandin wrote: > https://news.ycombinator.com/item?id=31453255 > > Pure coincidence? :) > -- > Duke Only the purest coincidence. :) I'd been thinking about a project I'd done with Pike about 15 years ago, and that prompted me to look in my email folder for this list for the first time in 6 months or so. By an amazing coincidence (see?), that happened to be the same day you made your comment. Which prompted me to do a search, revealing that indeed Pike is rarely mentioned there, and hadn't been for over 3 years. Having seen a few too many rehashes of the usual debates there recently I thought, hey, let's see what people have to say... It turns out to have been one of my most successful posts there, not dropping off the front page until an hour ago. Though that probably says more about how boring I am than how interesting Pike is. Dave
