Perl is pretty much dead, I don't anyone still using that beside legacy code.
Nobody's using P6 for legacy code.
Why I’m Learning Perl 6
121–130 of 380 posts
Re: Why I’m Learning Perl 6
#122Can Perl6 merge all of its generated VM code into one "package"? One of my favourite things about Go is that you can statically compile everything and then deployment basically becomes scp.
I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. This would m…
> Way ... way back in the day, the argument was it would save memory ... it also gave rise to dynamic library hell.
Could you expand a bit on how static linking would cause either of those things? It seems to me that they are both consequences of dynamic linking.
Re: Why I’m Learning Perl 6
#123Earlier quoted context omitted.
Ok, but ZipPy, Jython and IronPython do not.
Have Jython and IronPython reached compatibility with Python 3 yet? Last I checked they hadn't, or it was still in alpha.
I don't know, but Python 3 still isn't relevant to many people.
For example, I have to explicitly install 2.7 to be able to use Cocos2d-x build scripts.
Re: Why I’m Learning Perl 6
#124Earlier quoted context omitted.
For me, other than the fact that I don't need yet another Algol reimplementation in my life, I'm also not interested in code littered with error handling. Also strongly prefer FP.
I don't understand how some other language would not need to handle all the errors ? I have written code in go/java/php/python/js and error handling has been a majority chunk of lines in most if not all cases(in other cases the errors are just not handled). The best ideal case flow is always easiest to build.
You've not yet tried Erlang.
Re: Why I’m Learning Perl 6
#125Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. The OS is designed to sche…
M:N threads exist because the operating system threads are too expensive (despite decades of development, OS threads operated at the wrong abstraction layer). If operating system threads scaled reasonably well, there would be (virtually) no need for M:N threads.
I agree that they can be too heavyweight for short-lived work. e.g. a program needs to sort a small(ish) amount of data, it would be great if the language could make the sort utilise all the available cores on the machine, without the base program needing to do any kind of multi-process or multi-threading. Spinning up threads to do this kind of thing could be too slow to be of any benefit, but you could use thread pools to save on the startup costs. This is the kind of problem that OpenMP tries to solve.
But for long-lived workloads, or lots & lots of tiny requests, (the OP talks about 'web-scale', whatever that is), you would be creating the processes and threads once, at startup, and then they just all keep busy with little overhead.
Re: Why I’m Learning Perl 6
#126Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. The OS is designed to sche…
> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. One might suppose this to be the case, but to my knowledge only network IO is truly non blocking, although there are async io api's in some languages for disk reads/writes, they're still bloc…
Yeah, non-blocking disk I/O is painful. I've never had to write code that did enough disk reading/writing to try to parallelise it, so I've never researched the solutions that much. What I don't understand is why disk I/O should require a different API to be non-blocking. After all, network I/O can be blocking or non-blocking with the same read() and write() calls that disk I/O uses.
There must be some reason why no OS offers non-blocking disk I/O in this way, but I don't know what it is.
Re: Why I’m Learning Perl 6
#127Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. The OS is designed to sche…
> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores.
That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") threads, and schedule them on N actual threads.
> why re-implement the wheel in your programming language?
Because for some things, OS level threads are far too heavy. For others, application level threads don't achieve the parallelism required to efficiently use the hardware available. Combining them should allow scaling well across multiple cores, as you noted yourself. The difference here is that they are part of the language, which means they can be easily and efficiently used without setup by everyone using the language.
Re: Why I’m Learning Perl 6
#128> Why is this important? Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. I guess the author doesn't know about Haskell? The concurrency story for Haskell is great, and using the right library, you can literally just define types for the routes for your backend and then…
Does Haskell have thread multiplexing?
Yep. “forkIO” creates a lightweight thread. There are also things like “forkOS” to create a heavyweight thread and “forkOn” to pin a lightweight thread to a particular capability (core, more or less).
Re: Why I’m Learning Perl 6
#129Earlier quoted context omitted.
Tongue-in-cheek answer: lol no generics :) To be serious, in my circle of developer-friends, we feel that it tries to be TOO simple, and disagree with some of the decisions of how the language works (ex. seemingly endless `if err != nil { return nil, err }` type things)
I always find it a bit funny when dev's try to put a label of "too simple" on a language. How would your friends label "brainfuck" ? Too simple because it has very limited number of identifiers or Too hard because accomplishing anything is nightmare ?
Simple is not the opposite of hard. The opposites are complex and easy.
Re: Why I’m Learning Perl 6
#130Earlier quoted context omitted.
M:N threads exist because the operating system threads are too expensive (despite decades of development, OS threads operated at the wrong abstraction layer). If operating system threads scaled reasonably well, there would be (virtually) no need for M:N threads.
I agree that they can be too heavyweight for short-lived work. e.g. a program needs to sort a small(ish) amount of data, it would be great if the language could make the sort utilise all the available cores on the machine, without the base program needing to do any kind of multi-process or multi-threading. Spinning up threads to do this kind of thing could be too slow to be of any benefit, but you could use thread po…
You just described M:N threading, and what's being touted in this article as good about Perl 6.