221–230 of 463 posts
Earlier quoted context omitted.
I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?
I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
Earlier quoted context omitted.
I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
Earlier quoted context omitted.
I guess it depends on what you're comfortable in? I myself have tons of Elixir scripts that I use to automate much of my life. It's replaced ruby as my go-to for one-off scripts.
I didn't know that Elixir had such a low-threshold for one-off programs. Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.
Earlier quoted context omitted.
I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
Earlier quoted context omitted.
How familiar are you with Perl, and how much have you used it? Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all. Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no m…
>How familiar are you with Perl, and how much have you used it? It's what my company's entire code base is written in. So every hour of every work day for the past 6 months. >To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways. It's no one thing, but a bunch of little things tha…
Julia has a really great threading model coming in v1.3, which is likely to be released this month: https://julialang.org/blog/2019/07/multithreading It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).
Is Julia getting more stable? I remember that was the big issue a few years ago, especially since it calls so many weird CUDA apis.
Earlier quoted context omitted.
It’s the Perl culture, to do even simple things in the weirdest way possible and everyone will call you a wizard. Whereas the Python community praises complex ideas expressed as simple code and frowns on tricks. That’s why all but the the most obsessive have moved on. And from what I’ve seen Perl 6 takes it to the next level.
You pretty clearly have very little familiarity with "Perl culture" and even less with Perl6/Raku. Perl 5 is in decline, no doubt. But it isn't because whomever you're visualizing when you wrote the above is an annoying nerd. People can and do disagree on the 'why'; I personally think it is the general decline of Unix-style syntax combined with the natural ebb and flow of language evolution. If "what you've seen" is…
Earlier quoted context omitted.
tldr; Using a scripting language that allows for native threads or has a strong concurrency model builtin to the core would be beneficial for any CPU bound scripting task... ----- Python's concurrency model is good for waiting on network or disk I/O because of its GIL (Global Interpreter Lock): https://realpython.com/python-gil/#the-impact-on-multi-threa... If your program is CPU bound the GIL will slow you down. I'm…
As I've posted above, I'm a bit confused by CPU-bound work being processed in a scripting language. If you're planning on doing intense CPU-bound work, maybe use a lower-level language? I'm not saying abandon Python: you can extend Python with C or just use IPC to transfer data between a Python front-end and a computation back-end.
I'm personally with you. I also don't tend to think object boxing is really the performance bottleneck for most applications, and if/when it is, likely the other requirements should've already ruled out using one (a scripting language).
It's like writing Nifs for Elixir, yeah sure you _can_, they have their purpose, but you could also just write another application to do that one thing and like you said, use IPC.
So in summary, we agree with each other, here's to:
the right tool for the job!
Earlier quoted context omitted.
And other people love chasing new shiny things. I'm yet to see another language ecosystem that solves 99.99% of the problems one might have the way CPAN does. Would I write an API in perl? Nope. Would I write something that massages the data that APIs spit out and processes it, drops into a queues, generates jobs, etc? Absolutely. Mostly because I will write a few hundred lines of code for existing CPAN modules to so…
I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl. Yes, Perl's threading support is terrible, and I do wish it was as effortl…
Because there have not been million people with different levels of skills poking and prodding Mojolicious into good, bad, ridiculous, disgusting, ugly and beautiful uses, posting on Stackoverflow, getting answers, getting smacked down, or getting those things marked as known bugs. I use code to achieve a business objective, not to create a beautiful code or use a wonderful framework.
Just framework itself is not enough - it needs to have skeletons for services that would handle common edge cases -- database failures with automated switch to standby, internal request queues with retries, configurable. Clean interface to external configurations that should be changeable in-flight without a restart; patterns for interfacing with other systems, etc.
> Yes, Perl's threading support is terrible,
Some of the basic crypto modules and modules that use those basic crypto modules are not thread safe. In 2019. Modules that were written a decade ago. I'm not interested in figuring out those bugs in production.
I wrote a pretty complex API using Dancer. I'm not going there again.
Earlier quoted context omitted.
Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.
Heh, escript isn't so bad once you get used to it. Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support. I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.