Putting aside the "web scale" jokes (http://www.mongodb-is-web-scale.com/), this statement is still absurd.
Every major language, or at least the ones that matter for backend development, has support for thread multiplexing / coroutines / fibers, whatever. Perhaps not in the core language syntax or standard library. But it's easy to implement with native code, and so SOMEONE has implemented it in a library if the language has an FFI.
Java, and all of the other JVM-based languages in turn, have Quasar (http://docs.paralleluniverse.co/quasar/).
Ruby has support for primitive fibers baked into the standard language (https://ruby-doc.org/core-2.1.1/Fiber.html), and likewise community gems with more robust functionality like Quasar.
Python 3 likewise has this out of the box (https://www.python.org/dev/peps/pep-0492/).
The list goes on and on: https://en.wikipedia.org/wiki/Coroutine#Programming_language....
M:N threading is not, from a developer perspective, the same thing as coroutines/fibers. Coroutines are lower-level; it's possible to build something like M:N threading on top of coroutines, but it means doing a lot of work that's already done for you in a language that provides M:N threading out of the box, and if you have to do it yourself, that also means code you use from others isn't going to integrate well with it generally.
Not sure I understand what you're trying to say here, this sounds exactly backwards to my reading. A green threading library can be written in assembly language with no reference to anything but the hardware ISA specification and the ABI that defines the relevant calling convention. It's as "low level" as a software construct can be. The only lower level implementation I can think of are hardware-assisted context switching features like you see on some embedded architectures.
Coroutines, on the other hand, are artifacts of the language runtime and depend in sensitive ways on that whole stack. Much higher level.
If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.
I much prefer the go/erlang version of this. Playing the "what color is your function" game or "will it block" is no fun.
https://github.com/ruby-concurrency/concurrent-ruby for those wondering. Rails uses it as of version 5.
Now, I preferred correction to downvoting, but I can easily see why others would choose downvoting.
It's probably just my age, as I started out online when most discussion forums lacked explicit voting mechanisms. Before social media came along, and "gamified" human conversation. Maybe it helps police trolls, but at the cost of encouraging group-think and excessive meme-referencing, and just making a lot of people more neurotic and insecure in general. Overall, I think that online discussion is worse than it was 15 years ago, due to the psychological effects of all the imaginary Internet points.
But anyhoo, at the time I saw this (45 minutes after my original comment), my comment had 25 votes and was the top-most thing on this page. More often than not, if you wait an hour, the crowd straightens out the impact of any early outliers.
Like dragonwriter said, having coroutines in your language or a fiber library is not close to the same thing as the language having a scheduler that maps those fibers onto native threads for you. Some of the languages mentioned can't even execute multiple threads on multiple cores in parallel.
Because for some people, it's not enough to think of others as misinformed, or not so well-spoken.
They need to be thought of as blundering idiots, and castigated accordingly.
But it has been a decade and I am truly impressed with what it has turned into. Unfortunately, it has to re-gain mindshare as if it was starting from scratch. It might be a little bit harder actually, because there are a variety of scripting languages these days that are easy to learn, and there are still more than a few people who actively don't like Perl.
I really liked this slideshow: http://tpm2016.zoffix.com/#/
It gives a good review of Perl6 from early 2016. The video is an hour and a half, but it only takes a few minutes to scan through the slides and find the interesting pieces. (left and right arrow to navigate the slides)
Learn You A Haskell for great good (http://learnyouahaskell.com) is an excellent introductory book to read to get started with Haskell.
A drier but more in-depth read is http://book.realworldhaskell.org/
Also, when you hit monads again, the best advice I can give you to understanding them (99% of Haskell guides out there seem to be about monads) is to take this path:
Functors -> Applicatives -> Monads
And check out this link: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
I'm not sure those resources were around when last you tried haskell, but they're worth giving a read.
Haskell has M:N threading, and a strictness about types and semantics that's very refreshing to me. Yes, I could have written my most recent web project in some other language that would have been quicker (because it would have been simpler and likely more imperative), but I trust my codebase so much more with Haskell. Ironically it's my own understanding and clarity of thinking that I sometimes doubt now, but that's a good problem as far as I'm concerned, makes me think clearer.
[EDIT] - Can't believe I forgot, but Erik Meijer's series on Haskell is actually one of the first resources that actually got me really into it, it is absolutely fantastic, I actually watched the whole series before I read learn you a Haskell.
https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun...
tl;dr: 1) If you want to buy a book, http://haskellbook.com/ is supposed to be good
2) If you instead want to learn from free online sources, a) cis194 spring 2013 followed by b) The data61 course (links in the github link above).
Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC (parrot byte code).
Rakudo Perl 6 developers took the route of developing Perl 6 through an intermediary language NQP, which is a language aimed at making it easy to implement interpreted languages.
Rakudo (the implementation of Perl 6 that run on MoarVM) is implemented in NQP, and started out on Parrot through an implemention of NQP for Parrot.
NQP[1] stands for Not Quite Perl, and shares various features with Perl, but is much more constrained in features as capabilities, making it easier to implement in a VM.
Because it's mostly implemented in NQP, it's fairly easy to port to a new VM, as all you have to do is get NQP running on that VM, and Perl 6 is mostly ported. For example, this is how the Java port happened within a few months of announcement. NQP was implemented, and then 95% of Perl 6 was already working.
When a new VM instead of Parrot was desired, MoarVM was conceived of as a VM to natively run NQP (rather than NQP on top of the native VM bytecode). Porting Rakudo to it was relatively easy, since Rakudo targets NQP, not a specific VM.
Pugs, conversely, was an interpreter/VM for Perl back in the days of Parrot, and ran its own Perl 6 implementation directly (no intermediary language, and it wasn't Rakudo). It was writtem in Haskell.
Niecza was another direct implementation of Perl 6, but implemented in C# for .Net. I don't believe it used NQP.
Truly an interesting feature
Here is a working grammar for INI config files: https://github.com/tadzik/perl6-Config-INI/blob/master/lib/C...
I could not even find in the standard documentation which kind of parsers it supports, is it LR(k)? LL(k)? Any CFG? What parsing method does it use: recursive descent, shift-reduce, something more general like CYK/Earley algorithms? How does it handle ambiguities?
It turns out that `grammar` keyword generates recursive descent parsers and anything even a bit fancier still requires a dedicated parsing library.
Disclaimer: I do not hate Haskell, I just don't "get it". If you love the language, fine, have as much fun with it as you possibly can. I for one have given up, at least for now. Maybe I'll try again next year.
[1] NB that the word "stubbornness" has three pairs of double consonants. How fun is that?
If you feel like trying a pure language again someday you could consider PureScript (which just has the first 2 things above) or Elm (which just has the 1st). If you do try I'd like to hear how it goes, email in profile.
I understand the tutorials and have read though the books available, but when I try to use the language on a small real project, say a 2d barcode generator, I have trouble getting off the ground. Its not even clear to me which set of features are recommended for the language. It seems like different users program in different, incompatible, languages! Here is a list of optional language extensions supported by GHC:
Cpp
OverlappingInstances
UndecidableInstances
IncoherentInstances
UndecidableSuperClasses
MonomorphismRestriction
MonoPatBinds
MonoLocalBinds
RelaxedPolyRec
ExtendedDefaultRules
ForeignFunctionInterface
UnliftedFFITypes
InterruptibleFFI
CApiFFI
GHCForeignImportPrim
JavaScriptFFI
ParallelArrays
Arrows
TemplateHaskell
TemplateHaskellQuotes
QuasiQuotes
ImplicitParams
ImplicitPrelude
ScopedTypeVariables
AllowAmbiguousTypes
UnboxedTuples
UnboxedSums
BangPatterns
TypeFamilies
TypeFamilyDependencies
TypeInType
OverloadedStrings
OverloadedLists
NumDecimals
DisambiguateRecordFields
RecordWildCards
RecordPuns
ViewPatterns
GADTs
GADTSyntax
NPlusKPatterns
DoAndIfThenElse
RebindableSyntax
ConstraintKinds
PolyKinds
DataKinds
InstanceSigs
ApplicativeDo
StandaloneDeriving
DeriveDataTypeable
AutoDeriveTypeable
DeriveFunctor
DeriveTraversable
DeriveFoldable
DeriveGeneric
DefaultSignatures
DeriveAnyClass
DeriveLift
DerivingStrategies
TypeSynonymInstances
FlexibleContexts
FlexibleInstances
ConstrainedClassMethods
MultiParamTypeClasses
NullaryTypeClasses
FunctionalDependencies
UnicodeSyntax
ExistentialQuantification
MagicHash
EmptyDataDecls
KindSignatures
RoleAnnotations
ParallelListComp
TransformListComp
MonadComprehensions
GeneralizedNewtypeDeriving
RecursiveDo
PostfixOperators
TupleSections
PatternGuards
LiberalTypeSynonyms
RankNTypes
ImpredicativeTypes
TypeOperators
ExplicitNamespaces
PackageImports
ExplicitForAll
AlternativeLayoutRule
AlternativeLayoutRuleTransitional
DatatypeContexts
NondecreasingIndentation
RelaxedLayout
TraditionalRecordSyntax
LambdaCase
MultiWayIf
BinaryLiterals
NegativeLiterals
DuplicateRecordFields
OverloadedLabels
EmptyCase
PatternSynonyms
PartialTypeSignatures
NamedWildCards
StaticPointers
TypeApplications
Strict
StrictData
MonadFailDesugaring
I've seen different subsets of these extensions recommended. Is there some canonical subset recommended by anyone doing real work in Haskell?
Even more off topic: in reference to your note about the word "stubbornness", the word "bookkeeping" has three consecutive doubled letters. I believe that there are no examples of four consecutive doubled letters in any ordinary English dictionary, but I ought to grep the longer lexicons I've got at home.
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)
How would your friends label "brainfuck" ? Too simple because it has very limited number of identifiers or Too hard because accomplishing anything is nightmare ?
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.
I can understand other people's complaints about the language though.
Go to me feels like Java did back in the 90s (in the sense that Java only offered some of the power of a language like Smalltalk while making you jump through hoops, and thus having to write more boiler plate).
no generics
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 schedule workloads, it has decades of development in doing this, and has all the system-wide information needed to schedule tasks well across the CPUs. why re-implement the wheel in your programming language?
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.
More or less. I would say that manually threading continuations through async calls doesn't count as M:N. Not even when done via semi-automatically via the stack-less coroutines which are popular on recent languages as they are a very leaky abstraction.
I would even argue that a proper M:N system should have, if not full preemption, at least a best effort attempt at guaranteeing forward progress by implicit insertion of yields.
> For others, application level threads don't achieve the parallelism requires to efficiently use the hardware available.
You've got this backwards: OS-level threads execute in parallel (or, rather, may be executed in parallel), while green threads spawned within the same OS-level thread execute sequentially on a single processor core (but in no predetermined order).
It's at the purported 'web scale' in the article (I'm guessing this means lots of tasks, or lots of work) that green threads least useful, because you know there that the workload will be big enough to keep all CPU cores busy, and multi-threading/multi-process is always going to be a win. Adding green threading to an already maxed out computer is just extra overhead for no benefit.
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.
A universal M:N threading system with coroutines underlying everything means that both styles of code can happily coexist.
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 blocking behind the scenes. One of the coolest things about go (imo) is it's scheduling of many go routines onto relatively few machine threads (and processes) for blocking IO. I'm not clear if Perl 6 has such a facility.
Windows does apparently offer the necessary building blocks; this is the most relevant HN sub-discussion: https://news.ycombinator.com/item?id=9584269
jnthn (one of the primary contributors to MoarVM) has a write up about recent work done to improve the system here: https://6guts.wordpress.com/2017/06/08/sorting-out-synchrono...
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.
Right now I feel the major reason that keeps me from investing time in Perl 6 - besides adoption by distros - is the lack of a good book, like the Lama and the Camel book for Perl 5. It's kind of frustrating after having waited so long.
Looking at the Perl 6 website, there are a few more coming along as well. https://perl6.org/resources/
This has improved, and I think most distros now ship Rakudo (Perl6 on MoarVM). At least: Debian, Ubuntu, Fedora, and Arch do.
Rakudo is the only currently supported implementation (ignoring several specialized partial implementations), it is also open-source.
As far as web development in perl..well have fun convincing everyone on the node.js and python bandwagons to move 'back' to perl. Glad it works for you.
Python comes with a C module for interacting with an embedded Tcl interpreter (Meaning Tcl and Python interpreters are running within the same process). It's mainly used for GUI programming from Python but the interface is generic enough to be able to write some nice iterop code.
For example, I have a library that seamlessly lets you use Python classes and objects from Tcl and vice versa.
From there we merged the Tcl and Qt event loops so that we could have PyQt widgets playing nicely with Tcl/Tk widgets.
This was all part of an effort to migrate from a Tcl/Tk codebase to Python/PyQt.
I wish I could share the code because it's kind of neat. Only around 600 lines of Python code to do all that magic.
TCL has an interesting history, it's creator is also known for Ousthout's Dichotomy[2] which is useful when disambiguating between "scripting" and "other" languages (an argument that occurs frequently on the internet).
Antirez has written about TCL, if you're an admirer of him or his work (redis) you may find his take on it interesting[3].
[1] https://en.wikipedia.org/wiki/Tcl#Uplevel
One of its great strengths was being extensible. It's pretty easy to bake some functionality into Tcl and provide a new shell with it. This is what expect (http://expect.sourceforge.net/) is, for instance.
Another early advantage of Tcl was Tk, which provided Tcl extended with GUI stuff. Tk was cross-platform and established very early on, so if you wanted to provide one GUI for Unix, Mac and Windows, it was a good choice. It was very ugly for a long time; I hear it has gotten better lately but I don't know that myself. Tk is still built-in to Python as Tkinter. This is another specialty shell provided by Tcl, wish ("window shell").
Tcl was supposed to be good for embedding. The original author was supposedly using it for robotics. I haven't seen much energy there; I think Tcl's lunch probably got eaten by Lua some time ago. Lua is smaller, more like a modern programming language and easier to embed, but Tcl is more like shell scripting, so I guess there might be style reasons why you might prefer Tcl despite Lua's advantages.
Tcl is easy to disparage, but there's a lot of misinformation out there. At one time, it really only had one data type (strings). Quotation is a big topic in Tcl, but like Lisp, you can supply your own control structures. Everything is a command and commands have a lot of freedom about how to interpret their arguments. It is rather Lispy, unlike Lua. Tcl does have modern data structures and it does pretty snazzy things behind the scenes to optimize access to them while making things still seem to be strings for the cases where that matters.
Tcl is still around in some surprising places. I wouldn't expect there being a lot of new development starting with Tcl but it's kind of a fun language to know about. I got the newest edition of the book and it's a neat book, but I confess I haven't found ideal use cases for it.
Some of the things I've written are: a simple standby order input app, a Forms/Reports compiler (sends file to server, waits for response and informs user), and a Ghostscript wrapper for merging lots of PDFs into one file.
I don't want to go back.
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 ask it to generate JS for your frontend.
I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#, java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't quite enough because haskell and idris kept on talking about complicated type theory stuff. So I also learned lambda calculus, type theory, set theory, domain theory, topology, category theory, information theory, sub-structural logic.
What I'm trying to say is that I'm not afraid of learning new things. Even if they seem hard or esoteric.
When I heard that perl6 was ready, I took a look. I like the idea of a lot of what is present in the language (hey look, a grammar engine, that's neat). But ultimately, I decided that it was too much stuff that I would have to learn. Maybe that's just a perception problem on my part, but I have to think that they have some sort of problem if someone like me feels overwhelmed by all of the things that you have to grok in order to understand the language.
So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6. Write something that works and solves your problem. Later on you may learn that there are multiple other ways to express the same ideas you wrote already. Maybe one of them better expresses the heart of your algorithm, then you update your code.
Now, you may think, how the heck am I going to maintain code written by a bunch of people at different phases of learning Perl6?
The Perl community has responded to this challenge by putting a huge amount of work into writing excellent documentation. Perl6 docs are readily searchable and carefully indexed. It's a big, new language with lots to write about, so the docs are not yet complete, but they are already fantastic and keep getting better.
So, please, just pick a problem to solve and jump on in. The water's fine.
As a result, a language like Perl is very nice and maybe even artistic but in many situations downright "dangerous".
In a way that's correct, because ultimately Perl6 is designed as the ultimate "kitchen sink" language; it has all the little features you could think of already baked in, which will include a lot of features you won't use.
The main reason for this stems from the overarching design philosophy; "There is more than one way to do something". The language ultimately tries to be as flexible as possible, going so far as to support modification the the core grammar, the object system, etc.
This is meant to make the developer as comfortable as possible, but it can lead the common case of perl-itis, also known as "write-once, read-nonce" code.
Conversely, whereas the P5 motto was TIMTOWTDI, the P6 motto is closer to TIMTOWTDIBSCINABTE, so there's usually relatively few idiomatic ways to do something.
With all due respect, you didn't "learn" these languages. You got a superficial understanding of these languages. It's like someone who learns to say "hello, name is John, what is your name" in 17 human languages saying they learned 17 languages.
Being able to write "hello world" in all these languages doesn't mean you "learned" it.
Perl gives the programmer a lot of rope to work with. Whether one ties that rope into a drawbridge or a noose is the programmer's choice.
Also, CPAN is fantastic and widely supported. I really wish more languages would follow its example, especially when it comes to package namespaces.
In Python I can expect the standard library to be consistent and be maintained as part of the core language. Now I don't mean that everything has to be in the standard library (I'm fine with the database access libraries being third-party for example), but in Perl even the most basic stuff like exceptions is only on CPAN and there are again multiple packages to choose from..
Mostly an urban myth. Where it isn't, at least 8 of those ways are actually important.
Exercise: write a python program that prints Python's quoting documentation, without external files, without editing the documentation. Spoiler alert: it's impossible.
sub add1 {
my ($arg1, $arg2) = @_;
$arg1 + $arg2;
}
sub add2 {
my $arg1 = shift;
# possibly two screens of dense code here, then
my $arg2 = shift;
$arg1 + $arg2;
}
sub add3 {
$_[0] + $_[1]
}
# There may be some other ways to extract arguments
# that I am not aware of.
# It's possible to combine any of the methods!
No other reason, that's all. Just the syntax.
I haven't looked at Perl 6 yet, don't know if that's better or worse. Too many other things to do, and I don't think I'll ever work with Perl professionally again, that ship has probably sailed.
Larry Wall came and made a language inspired by awk that doesn't give feedback on when you're out of the comfort zone. This lets you make a mess before you know what you've done (aka technical debt). The same problem 'that killed Smalltalk and could have killed ruby' too (thanks, Bob Martin).
> or Nginx or Node.js without the callback cacciatore.
What's a cacciatore in this context? It means hunter in Italian. Probably something messy if it means the same as callback hell.
Kinda like "gabagool" which is effectively an american only name for an italian product we call "capocollo".
pmontra is italian, hence the confusion.
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 make a great study in how the ROI was completely overshadowed by risk considerations not considered at the outset.
Of course, saving memory was a huge issue in the days when 1GB RAM was considered gigantic. So maybe the cost was worth it.
[1] https://scalability.org/2017/03/what-is-old-is-new-again/
The Perl community has spent a couple decades "enjoying" taking (or being forced to take) a long hard look at that.
One result in P6 is :auth (authority), :api (api version) and :ver (package version) qualifiers, eg:
use Some::Module:ver<1.2>:api<3.4>;
Aiui this aspect of the language and tooling needs work but shows promise.
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.
And security updates for your deployment become...what?
Perl tries to be everything at once, still mysteriously lacking interactive REPL out of the box. Yes, Python is more heavyweight for scripting, but it pays in the long term with better maintenance and tooling for big scripts.
It sounds like you are justifying an emotional attachment rather than making consistent arguments.
Now, there is nothing wrong with having an emotional attachment to a language or other tool, as long as you know it for what it is.
Python is a great language and has some really nice features, it's C extension system is miles better than Perl 5's horrible mess called XS. But to me, using it feels like wearing my shoes on the wrong feet, I really prefer Perl 5.
From my experience and from listening to colleagues, Python has one edge on Perl 5. Perl 5 and Python have very similar tooling abilities. Long term maintenance of large systems is pretty much the same. Python has the edge in ability to find and hire qualified people because the community has done a better job articulating Python's strengths and recruiting new people.
In fact there are two flip-flop operators that exist in Perl 5, one which works like the one in awk `..` , and the other like the one in sed `...`. Perl 6 renames them to `ff` and `fff`.
I remember hearing/reading that the release of Perl was delayed until a2p and s2p were written, specifically for people who used awk and sed to be able to get going quickly in Perl.
Last year I attended a conference and saw Larry Wall speak. It was an overview of Perl 6 and I was completely underwhelmed. Larry spent about half the time talking about unicode support. It wasn't a boring talk, but I never felt a moment when I said, "Awesome! This is a pain point in some other languages and I would pick up perl6 if this ever happened again."
I don't want to write perl6 completely off, but I have found that perl6 advocates have not done a great job on why you would actually want to use it. It's hard to justify learning "different" syntax just because someone says, "hey, it's fun!".
From what I've seen perl6 makes some operations more convenient. Cool, I guess, but not a great reason to reach for perl6.
Grammars are really cool, and one reason I might reach for perl6, but you also have really great special-purpose tools like Antlr. I suppose I don't feel the need grammars that often to need them reified in my language of choice, but next time I need to do some parsing, however, I will probably play around with perl6.
Some people (such as me), prefer designating variable scope and easily identifying where a variable was defined. By the way, that isn't required by Perl 5. It was decided by the community that it was beneficial in that it solved far more problems debugging than the small bit of extra effort required, so the common refrain to "use strict;" was adopted because with that pragma it then is required.
> Why can't an advanced language like Perl 6 scope variables without littering "my" everywhere?
It could, but the community has decided it's not really beneficial. Have you actually examined why you think it's better?
> obligatory "use v6;" at the top of every script
That's not obligatory. You can omit at your leisure. If you do in include it and your script is accidentally called from a Perl 5 interpreter, you will either get an error, or if supported it will try to load a Perl 6 interpreter to parse the code.
I strongly disagree: From a languge design perspective, block-level lexical scoping with explicit declarations is superior to all alternatives I'm aware of.
var creates variables that are function scoped. my creates variables that are block scoped.
let in JavaScript would be pretty much the same as my.
Both are good things as they prevent typos from being new variables.
EDIT: as seen in other responses, options abound: Python 3, Elixir, D, Dart and more all have built-in concurrency primitives, not to mention that discarding nodejs because of "callback hell" is at this point laughable.
[0]: http://vibed.org/features
Note: Vibe.d is a web frameworks as well as a networking stack for D. If you're even remotely curious about D or do any web development I recommend you check out Vibe.d it is quite impressive (at the very least to me).
Edit:
There's apparently jin.go / Go.d:
It is of course possible to gain slowly over time, but with numerous languages competing, that path may be a dead-end.
But such gems tend to be unique, also in completely different fields. And it probably wouldn't have been possible if the original developer hadn't been involved and gained experience through Catalyst, which is roughly Perl's take on Ruby on Rails.
If it got a bit more press in its early days, outside of the Perl community I think the world of web development could look very different today.
As I said I am not a Perl developer anymore (and don't focus on the web part anymore either), and I am sure there is a bit of nostalgia in those lines, but even though there are great frameworks in other languages, no doubt, there is impressive projects, I still didn't get something that allowed such a kind of rapid development and transitioning prototype applications into production services in such a seamless manner.
I think it's also a great example of Perl being very readable despite all the ugly scripts you find out there - of course also because a big bunch of it being written by non perl developers who just needed to get a script going. Just like with JavaScript and PHP.
It's funny though how the presence of a well done web application framework nowadays is considered the killer application in a pretty consistent way. I've seen that in various languages that weren't really made for web application programming as well. There is obvious reason, as it's the agreed upon API for most applications, however I wonder if this might not bring stagnation and kind of a cycle that only allows a certain way of thinking and developing to succeed, as standards and programming languages/frameworks co-evolve.
Here's an example where a naive Perl 6 version is going to beat the pants off of the naive version in another language:
Find the sum of all integers from 10 to 1000000 inclusive.
In Perl 6:
say [+] 10 .. 1000000
This finishes almost immediately. (It also does so if the endpoint is 10¹⁰⁰⁰ or more)
The reason is if you use the built in version of the &infix:«+» operator, it calls the sum method on the Range object. That particular method knows how to calculate the sum on the Range without iterating through the values. If you modify the &infix:«+» operator lexically it won't take that shortcut.
This also works the same if you wrote it like this:
say Range.new(10,1000000).reduce(&[+])
There are plenty of areas where Rakudo Perl 6 is slower than I would like, but for many uses it is fast enough.
It's remarkably slow right now.. It takes 1.5 minutes to generate an image. I tried to do the same thing in Julia and it takes 1.5 seconds. So I guess I must be doing something wrong!
But imagine how cool it would have been - write a class in Python, sub-class it from Ruby, use that subclass in a function written in Perl, call that function from Lua code...
Okay, I see it now. It was just too awesome for its time. Maybe in a hundred years or so...
But regardless, having fun with P6, which is specifically designed to be readable, maintainable, composable, refactorable, etc. is fundamentally different from having fun with a language like P5.
In #devops is turtle all way down but at bottom is perl script. - @devopsborat
Why mention .NET here? Async code in .NET works with a dispatcher thread (-pool) under the hood, which is nothing like the greenish threads that the other systems offer. Am I missing something?
>There’s no GIL, so unlike Those Other Languages
There is no GIL in EVM as well, but playing with the words you make it look like "all are the same". This does not deserve top HN and just stupid.
If your Perl6 VM is _so_ great, why didn't you mention anything about what's really important like preemptive scheduling which has been Erlang's unbeatable feature since the beginning? Less hype and more details, please.
Perl: Good at regular expressions, and proper per-processor core threading, Bad because what you wrote will be indecipherable to future you
Python: Very expressive (without being too much), lots of library support, good drop-to-c/do-stuff-fast support, sensible support for object and functional programming paradigms that evolved over time, super useful stdlib. Bad because GIL
Ruby: ???? at least it's beautiful? seems to only be used in codebases that are rails-based which is basically a red flag for me now due to personal preference
It looks like Perl just got another killer feature
Ruby has been referred to as Perl 5 with a better object system.
Perl 5 also has Moose an object system based on Perl 6's which has been ported to Python and to Ruby twice.
The way to allow calling into C with NativeCall is almost seamless most of the time. It has also been used to make using modules/libraries from other languages even more seamless. (usually the only way you know the module is from a different language is the :from<Python> in the use directive.)
Well, as a matter of fact I really got no output at all :(
http://blogs.perl.org/users/zoffix_znet/2017/07/the-hot-new-...
https://github.com/perl6/marketing/blob/master/TablePosters/...
M:N is what you do when you don't have real kernel thread support. You hacked N user space threads per process (N:1) but then 1990 rolled in and cheap SMP with M processors started to spread across the land, so you needed N:M to take a bit of advantage of that.
I'm enjoying using it for command-line tools and web applications - it's expressive and scales with the problem space.
1. https://perl6advent.wordpress.com/2015/12/20/perl-6-christma...
