• Lots of people questioning what Pike brings to the table. Be aware that Pike has been around for over 31 years[1]. It's kind of dead now and a lot of people have moved over to Lua[2] (which is over 32 years old!).

    So long ago, that it took me a minute to recall having programmed a lot of CGI code with it, back in the Roxen web server[3] days.

    1. https://en.wikipedia.org/wiki/Pike_(programming_language)#Hi...

    2. https://en.wikipedia.org/wiki/Lua

    3. https://en.wikipedia.org/wiki/Roxen_(web_server)

    • pike and lua are nothing alike. it is more somewhere between python and java (kind of like a typed python). it may be comparable to go in some respects.

      pike is suitable for large high performance standalone applications. basically everything that you would use python for as well but faster.

      pike is also still under active development and maintenance, so far from dead.

    • It was great for certain niche applications, like:

      * The Roxen web server

      * The Opera Mini backend service (150k CPU cores, 5k servers, 150k pageloads/s, 3 million inline fetches per second, 100+ Gbit/s - 15 years ago)

      I worked on both of those projects. Now I mostly program in Python. It's perhaps like 10x slower to run on average but since it won there's a module or three for anything so building stuff is faster.

      Yay progress.

      • > since it won there's a module or three for anything.

        I was just browsing the "Module tree reference" for Pike. There seems to be a crazy amount of modules for the language. Weirdly enough for web there's only CGI (and WebSockets for some reason), and the CGI module isn't really documented. Under protocols there seems to be everything I ever need.

        • We kind of went crazy with protocol support, starting early on. It was a good way to learn the protocols in depth. The late 90s was an exciting time. It eventually became a defining feature of the language's library.

          But we were too busy having fun building the language to "market" it. This became a pattern.

      • Python won because of its C interface was easy, so it's got Numpy, Scipy, Pytorch, OpenCV bindings, etc. For these use cases, the speed of the interpreter is mostly irrelevant.

        On the web dev front, Python was lucky to get easy bolted-on async I/O (via greenlets), so it was more performant than Ruby (which was really slow 10 years ago), and Django was less magical than RoR.

        • No, python had already won by the time django and numpy started.

          Pike's C interface is better in most ways, but of course that might depend on tastes.

          Python's easy syntax, accessible documentation, books and tutorials make the learning experience completely different. It's an excellent choice for low-effort small scripts and short-lived projects. It became widespread. At some point it started to be the chosen language in schools. Numpy and django (etc) followed from that.

          Pike with modernised syntax (something like Swift?) could have been a contender web-language maybe 2005-2006 at the latest.

          Pike's learning experience was always less welcoming. The module tree reference is great though.

        • pike's C interface also looks very good. pike had built-in async I/O from the very beginning. the roxen webserver is built on async I/O. it doesn't fork, and on an overloaded system it is one of the last services standing because of that.

          python likely caught up and overtook pike because it had better community support. one downside of pike is that it is slow to start, making it less convenient for quick scripts, which python was a lot better at, so python was more likely to replace perl in sysadmin work where short scripts matter more further helping its popularity.

    • Why is it likely currently receiving traction on HN? Is there an effort to revive it amongst developers, or has something changed that would make it more relevant now?
      • Once every 2 or so years it's posted and upvoted due to appearing interesting ("dynamic language with C syntax", and perhaps other characteristics/features). Not really receiving traction. That said the language is mature enough, still gets updates, and there're meet ups so can assume there're developers using it.
  • Brings back some memories of the webserver Roxen that had a GUI, if I remember correctly. It still seems to be semi-alive, although the download page looks broken.

    https://en.wikipedia.org/wiki/Roxen_(web_server)

    EDIT: Github repo https://github.com/pikelang/Roxen

    • the problem is that the owners of the roxen company are not interested in the community. that was a change that happened more than 20 years ago, and some believe that it was the downfall of roxen and pike as FOSS products.
  • what does pike look like

    https://pike.lysator.liu.se/docs/tut/introduction/first_glan...

    (saving you some clicks...)

  • More information in this earlier comment, linked from the wikipedia article

    https://news.ycombinator.com/item?id=31453477

    https://en.wikipedia.org/wiki/Pike_(programming_language)

  • It claims to be one of the fastest “scripting” languages, where can I see the numbers? Does it perform close to DaScript?

    Also, is it only an interpreted language or can I compile it too if I want?

    Is it like Ruby in the sense that I have to share the whole runtime with the ruby script or can I somehow share a standalone cross-platform executable?

    I’ll be honest, the design decision at first hand sight did not look that exciting

    string name = Stdio.stdin->gets();

    • The proper sales pitch would be: "A fast dynamic scripting language with a sane module system, hot reloading, and easy C interop". The fact that the syntax is similar to C should be mentioned without the pomp somewhere in the chapter about syntax; this is nothing to be excited about, but understandable, given the intended audience.
    • "string name = Stdio.stdin->gets();"

      It did say it was like C so the design decision you don't like is C

      • I don't think it goes both ways in this case. I wasn't a fan of their inspiration from C, it doesn't mean I don't like C.

        I'm fine with C. Keep the focus on Pike.

  • What's the itch this language is trying to scratch? For which use cases is it best suited?
    • Have you ever built games in LPC? It's kind of like that, but more cleanly general purpose. First class modules, hot updates, simple and familiar to those who know some algolians, things like that.
  • I remember coming across Pike about two decades ago (or more), as a young amateur developer... I couldn't understand why anyone would choose Pike.

    And today I still can't.

    Legacy projects?

    • It always seemed like a MUD language project that tried to recycle its efforts by taking on Python, Ruby, etc.

      There’s literally no reason to use this language unless you want to make MUD games or are just purely curious about the project.

      • That's a bit anachronistic. Pike was released in 1994, the same year as Perl 5.0 and Python 1.0. Ruby did not exist yet!

        Being an offshoot of an existing MUD language it was quite usable even a young language, comparably good performance and a compelling C embedding. History could very well have been different. The 90s was a really good decade for dynamic languages.

      • I mean let's be fair: back then MUD nerds were using LambdaMOO's "moo" language and LPmud's "LPC" before things like Python were mainstream or serious, Perl pre-5.0 was terrifying and limited, and Ruby wasn't even on the radar.

        So when we went to go do "serious" work we kinda missed them.

        Your options in 1991, 92, 93 were earlier perls, shell + awk/sed, or maybe tcl or a lisp/scheme if you were lucky.

        The languages inside those MUDs actually were ahead of their time, and their programming model -- in the case of MOO [and its offshoots CoolMUD and ColdMUD] at least -- was more similar to advanced systems like Smalltalk or Self which were hot interesting topics at the time.

        Being "confined" to being "game" languages made them not get taken seriously (unlike "JavaScript" which arrived with all sorts of weird warts but had Netscape's brand on it), so the LPC people tried to make it into a "serious" language in the form of Pike, and it's not half bad?

        By the late 90s, obviously things had changed. If somebody in a successful "serious" company had adopted Pike/LPC it could easily have had an alternative history where they became commonly used instead of perl5 or php on the early web. (It took Python a decade to get serious headspace there.)

        (Gratuitous plug for my LambdaMOO defibrilation: http://github.com/rdaum/moor)

        • LambdaMOO was ahead of its time in many ways: lists are immutable, but there was a handy splice operator. Verbs could have aliases and wildcards or both, allowing for some interesting namespace-like behavior. Would have been nice if they could have completely decoupled the built in parser before development died off, but it should be a pretty simple task nowadays, and some places like E_MOO managed to soft-code some pretty decent parsers regardless.
          • LambdaMOO versions from sometime in the mid-90s and up (and offshoots like ToastStunt and also my rewrite, mooR) let you override the builtin parser with $do_command.

            And the builtin one I wrote in mooR is built to be pluggable (Rust trait) so should be possible to swap it out.

            • Ah yes I forgot about $do_command, that’s what we used. For some reason I remember doing it with raw network read commands but that was a different MOO project now that I think about it. Nice to know some people are still doing MUD server dev, it’s a scene I haven’t been back to in a while.
              • Your name may be familiar.
                • Never went by my real name on MOOs, but I was on a bunch of them going originally by Phaedrus then Kirlan. I think on E_MOO I was going by Iluvatar. Prisoner #74469 on LambdaMOO, I still remember that. Probably still there, I can't imagine they do any more reaping in this current age when the whole thing can fit comfortably on a raspberry pi.
  • Pike is described as a "dynamic" language, so I was expecting purely dynamic typing, yet the language uses Java/C-style variable declarations with explicit types.

    It seems that these are (unsound) type hints, years before TypeScript made them cool:

    > "If your program tries to put one type of value in a variable which was designed to hold another type of value, Pike may detect this" [emphasis mine]

    https://pike.lysator.liu.se/docs/tut/fundamentals/index.md#t...

    • The compiler will complain about incorrect types and (?) infer types where possible. "Mixed" types are resolved at runtime.

      There is a strict_types mode that will increase warnings/errors.

      One of the problems with Pike is that the mechanics of this and other things are effectively undocumented so you have to learn by experimenting and reading the source.

    • Not sure what they are referring to, but it may be that you can declare things as having one of several types (e.g. int|string|void) or even that something can be any type at all (i.e. turn off static type-checking for that thing)? I do not think the type-checker will ever randomly decide to just not check a type given that you have provided types for it to check, but it was a long time ago since I had to read or write any Pike code.
      • Looks like there’s a `mixed` type, variables of which can hold values of any type. But at least that’s something you can `grep` for.

        A more subtle issue with type hints (as in TypeScript/Python, not sure if this applies to Pike) is that there are ways to work around the type system. You can get, for example, a variable of type `int` that actually holds a `list`:

        https://news.ycombinator.com/item?id=43508152

      • I can turn off static type checking for a thing in C by using `void*`
    • Groovy has that too and it's quite the anti-feature. Pretend static typing is worse than useless, it's the MAC-10 of footguns.
      • > it's the MAC-10 of footguns

        At least it might be shooting Nulls.

      • Sounds like Julia, too.

        Also you'd think having the type signature would help with performance, but in some cases it can cause the VM to enforce a runtime type check where it wouldn't have before, imposing worse performance.

  • If you ever wrote LPC on an LPMUD back in the day, you were writing proto-Pike :)
  • I am old. I remember when it came out.
  • the question i always ask: WHY anther language.
    • Well, I mean you'd have to ask that regarding: Java, C#, Rust, Go, and so many other languages, they are all younger. Why create those when Pike, C and Perl was already around?
    • What were you doing in 1994?

      These guys were deep in the MUD.

      • I think it's important to point out that MUDs were probably the first complicated interactive synchronous "Internet applications", even though they were (primarily) textually driven and not "serious" (they were to us). So things like Pike (née-LPC) & moo were on the forefront here on how to author those kind of dynamic systems.

        Early web sites, gopher, etc were just request/response mostly static content (sometimes with a dash of a database). They weren't synchronous or "live" in any real way. Things like IRC were synchronous but did not do programmable/dynamic content.

        I cut my teeth on moo, and was bored & annoyed to tears writing cgi scripts in Python & Perl and the web didn't catch up to produce really interactive stuff until well over 10 years later ("web 2.0")

    • "Keep at it partner, you'll get there."
    • .
      • In 1994 there was very little competition in scripting and LPC/Pike/moo and the like cribbed ideas that are still not mainstream or became mainstream much later. It's the same year Python got to 1.0 and they didn't get real traction until 2005-2010 sometime.

        At the time the alternatives were stuff like Tcl and Awk and Perl 5, which were relatively clunky, incompetent or slower. Perl won for web, though Pike had Roxen and could have, and if that had happened we would likely have gotten a more Smalltalk-like Internet than the PHP Internet we got.

        Pike is fun, it will likely compile just fine on your odd computers if you have any and it has some characteristics that are uncommon like easy hot upgrades for long lived systems and modules as data.

      • You realize that you're on a site that is mainly for programmers, right? Programmers are often interested in languages, for the same reason that woodworkers are often interested in wood - even a kind of wood that they may never use.
  • hmry
    Of all the strengths that Java and C have, I would not call syntax one of them. :) So this title seems quite strange. Not the sales pitch I would make.

    It is understandable though, considering this language is 30+ years old. Probably not the decision you would make if you were to design it today: Switch statement with labels+fallthrough instead of a switch/match expression (even Java replaced that one with a switch expression nowadays), ?: ternary operator instead of if expression (the Pike docs even call that one ugly and recommend not using it)...

    • I think they point they're making is the syntax is familiar to what you probably already know.
    • pike is based on LPC which stands for "Lars Pensjö C" which was developed in 1989. at the time C dominated the language landscape. sufficiently popular alternatives were BASIC, pascal, lisp, smalltalk, TCL and perl. i don't think there was much else. at least in the unix world. lars probably was familiar with C and that's what he based the language on. i think python was really the first non-C-like language that became very popular.

      i am not a fan of the C syntax myself, but at the time, i was mostly familiar with it, and i wasn't even considering the idea that there could be a better syntax.

      later though i did develop a preparser that would allow me to write pike in a python like syntax. it was a hack made as an april fools joke. but it was actually working. it was called nessie.

      • I guess the other well-known syntax form at the time was the one in the Algol/Pascal/Ada/Modula-2 tradition with keywords (begin/end, if/endif, etc) for structuring blocks and that's what MOO cribbed from, while LPC (and later JavaScript, Java, etc.) did the braces thing.

        At the time I liked braces a lot more but since then have come around to preferring the more Wirth-ish style. I think Julia has shown that a dynamic lisp-ish language can do this very elegantly.

  • Taking the worst aspect of statically typed languages and mixing it with the worst part of dynamic schemes. I'll keep my Ruby, thanks.
    • Might be helpful to expand on what you mean specifically by the worst parts in your view and how Ruby's decisions provide better trade offs.
      • Worst part of static compiled languages is the ugly syntax. Worst part of dynamic systems is they aren't machine-understandable. It's a direct tradeoff that results from formal language theory. Ruby isn't an answer to this, in fact it lies so far on the dynamic side of the fence that the one IDE targeted at it is more of an impediment than a help. There is no answer to the tradeoff, though there are a few current attempts, like Zest.

        I personally don't need or want a computer to help me to understand the code I work on. It would be nice but not worth the need for a compile step. Pike looks like a compiled language, but doesn't even try to give you any of the advantages of machine understandability. It's purely cosmetic, why in the world would anyone want Python to look like C? If you want a dynamic language and don't want to deal with Ruby's... eccentricities, just use Python like everyone else.

        https://github.com/jamii/zest

    • Why not Crystal?
      • Ruby has static type system if I ever want to use it.
        • Crystal has static type-checking though. It is built into the language, unlike Ruby. Ruby is a dynamically typed language unlike Crystal. What am I misunderstanding here?
          • Ruby's static type checker is built into the language, since 3.0.

            https://github.com/ruby/rbs

            You can use others if you like. I have used Crystal before, pretty quickly realized that it was never going to catch up with Ruby and the compile step isn't really all that much of an advantage. The few scripts that I want speed for, I just use mruby. Embed Ruby in C, runs super fast. Don't get all the cool Ruby libs or runtime reflection. But a way better tradeoff.

            https://mruby.org/

  • [flagged]