in reply to Re: Camel vs. Gopher
in thread Camel vs. Gopher

Being faster then perl is only a bonus.

Hey now. My direct, pure Perl answer was four times faster than the original Perl presented and not even twice as slow as the go; 70% slower on my box.

vr's answer, with a well-known Perl module, is two times faster than the go and kschwab's answer is ten times faster than the go and still shorter by several lines a few dozen chars. Being faster is a matter of tuning and knowing the problem space. With the evidence presented, Perl is the clear speed, space, and cognitive load winner if you know how to match it with the problem.

Replies are listed 'Best First'.
Re^3: Camel vs. Gopher
by morgon (Priest) on Dec 12, 2018 at 21:56 UTC
    Sure :-)

    In this particular case where you don't even think about doing part of the work in concurrently a perl solution maybe can be optimized to even beat Go.

    But I can see that you're not being too serious...

    For me Go is the new Perl - a language with a rich ecosystem, that is fun to use and that makes things easy that where very difficult before...

[reply]

      …I am having fun but I'm being a bit serious. The Perl (plus inline C but that's there because it's easy in Perl) is TEN times faster. It leaves Go in the dust and, to me, it's easier to read. Go reads more like the new Java than the new Perl; which I might call Scala but I still like Perl better.

[reply]
        Go has a way to call C as well.

        So if you bring in Inline::C for perl I bring in the unsafe-package for Go and we end up comparing C with C which is silly.

        This is a very artificial test-case and has really nothing to do with real applications.

        I would assume Go to beat Perl in performance in every real-world scenario but again - that's just the bonus.

        goroutines and channels are the killer-features for me.

        Give it a try - you'll like it.

[reply]

In Section Meditations