7 ms·

Sighs. I wish Nimrod were more popular. It seems like a better version of D. But there can only be so many languages with a fully functioning ecosystem, and

• rsaarelm 12y ago
  This. I'm on the lookout for expressive, statically typed, native code compiling languages for game development. Currently poking around with Rust, since Go seems to pretty much be settled on not doing the custom expressibility thing. Nimrod looks like something I'd really want to like, the game stuff I do doesn't really need Rust's hardcore garbage collection avoidance, but the ecosystem sparsity just scares me off. Meanwhile, Rust has both reasonably heavy institutional support and an impressive swarm of adventurous game developers with a C++ background working on stuff for it. I'm banking on Rust mostly for the potential ecosystem strength in being the only alternative to C++ for a high level of abstraction don't pay for what you don't use language.
  • def- 12y ago
    The standard library is pretty nice though: http://nimrod-lang.org/lib.html http://nimrod-lang.org/lib.html I spent a few days solving Rosetta Code tasks and was surprised how easy most were using the existing libraries: http://rosettacode.org/wiki/Category:Nimrod http://rosettacode.org/wiki/Category:Nimrod
    • dom96 12y ago
      We also already have a pretty functional package manager (https://github.com/nimrod-code/babel https://github.com/nimrod-code/babel) and many packages already make use of it: http://nimrod-lang.org/lib.html#babel http://nimrod-lang.org/lib.html#babel
      • fineline 12y ago
        I see the Babel doco has now been changed (10 hrs ago - any relation to this HN post?) to say I can run Babel against Nimrod 0.9.4 stable instead of needing to build Nimrod from source. This is great news, I was put off by the language's package manager not working against the stable release version. I look forward to giving this a try.
        • girvo 12y ago
          I will say building Nimrod from source is quite literally the easiest language that I've compiled before, aside from Node.js! Super easy :)
        • dom96 12y ago
          It's great news indeed. It seems I underestimated how many people will be having trouble building babel due to this. Next time I will do my best to make sure that it works with the latest Nimrod release.
  • tdees40 12y ago
    There really are only three ways to create a usable language, honestly: 1) Huge institutional support. See: C#, Java, Go. 2) Give it 20 years. See: Python, Haskell. 3) Weird, idiosyncratic factors. See: Javascript, mostly. So it's hard for me to get excited about these sorts of things. Edit: fair point, Javascript is really a case of #1, with Netscape as the institution.
    • zabcik 12y ago
      I think it's only the first two. Javascript happened because of Netscape (1).
    • skrebbel 12y ago
      You're missing 4) piggybacking on existing ecosystems. E.g. Scala, Clojure, F#.
      • def- 12y ago
        In Nimrod it's easy to piggyback on C, which has the most extensive ecosystem of all languages.
        • sanderjd 12y ago
          But C's ecosystem is so extensive that everybody can piggyback on it (with varying levels of ceremony).
          • tdees40 12y ago
            See CPython, Haskell, C++....
        • sitkack 12y ago
          This might already exist, but if Nimrod could piggy back on Javascript (Node), Python and Ruby for libraries this would be huge. Native glue.
          • 12y ago
  • stewbrew 12y ago
    It you're in game development, you might want to take a look at haxe. It seems many users use it successfully for games.
  • runT1ME 12y ago
    OCaml?
    • deleted 12y ago
      [deleted]
• progman 12y ago
  I am always amazed how quickly I get things done with Nimrod. It's like writing Python, having the full power of C (see below), and some of the power of Lisp (macros!), and getting the performance of C++. Nimrod actually is what I wanted Python to be. For instance, I just need to add two lines to import C's printf and fprintf: proc printf(frmt: CString) {.importc: "printf", nodecl, varargs, tags: [FWriteIO].} proc fprintf(f: TFile, frmt: CString) {.importc: "fprintf", nodecl, varargs, tags: [FWriteIO].} Now I can use these C functions seamlessly (even without parentheses): printf "Hello %s!\n", "world" fprintf stderr, "Error in line %d\n", $nr
  • Hello71 12y ago
    from ctypes import * libc = CDLL("libc.so.6") libc.printf("Hello %s!\n", "world") from sys import stderr libc.fprintf(stderr.fileno(), "Error in line %d\n", nr) although I don't know why in the world you would want to use printf instead of native string formatting
    • eric_bullington 12y ago
      I presume the printf was just to show Nimrod's easy C interop.
• fuzzythinker 12y ago
  It is getting there, as can be seen by the Contributions graph in that link. Aside from the fact it's mostly from Araq, the graph looks very healthy and encouraging. I actually just started using it for my next biggest project, after a week or so of looking into haskell, Ocaml, and Lua.
• audunw 12y ago
  I do think Nimrod will catch on in a little while. It has amazing potential. But things like type classes aren't done yet. Personally I believe Nimrod will be perfect as a Hardware Description Language. There's a couple of features missing, but they're currently being worked on. This is an area where Nimrod could really shine, and where it could start to gain massive commercial support.
  • def- 12y ago
    At least in the devel branch type classes seem to be working: type Comparable = generic x, y (x < y) is bool This creates a Comparable typeclass, which can then be instantiated: type Foo = tuple[a, b: int] proc `<`(x, y: Foo): bool = if x.a < y.a: true elif x.a > y.a: false else: x.b < y.b var c: Foo = (12, 13) var d: Foo = (14, 15) echo c < d # true And used elsewhere in generic code: proc min[T: Comparable](xs: openarray[T]): T = assert xs.len > 0 result = xs[0] for x in xs: if x < result: result = x echo min([c,d]) # (a: 12, b: 13)
  • peaton 12y ago
    Could you elaborate on why you think it would be a good HDL?
    • audunw 12y ago
      Three reasons: dependent typing (limited support, but enough to represent statically sized vectors), powerful macro system (functions doesn't work to well as an abstraction in HDL.. this allows us to create new kinds of abstractions, like state-machines and pipelines), and generics/type classes. The only other language I know that has similar amount of power is Idris(but in a very different way). But Nimrod has another advantage: friendly syntax and semantics. HDL programmers are not generally good at programming, so I don't think Haskell or Idri based languages will catch on.
      • aninhumer 12y ago
        I worked on a HDL based in Haskell as an undergraduate project[1], and I'm about to start a PhD exploring the design of HDLs. >dependent typing I definitely agree with this. When you're writing a program to generate code, the distinction between compile time and runtime is essentially meaningless, so the boundary between types and values in Haskell ends up being a huge hassle for no good reason. It's also hard to explain the difference between numeric values and numeric types, when there doesn't need to be one in the first place. I didn't realise Nimrod had this feature, so I might need to take another look at it. >functions doesn't work to well as an abstraction in HDL I'm not sure why you'd say that? Functions work great for abstracting chunks of combinational logic. Arguably one would prefer a more constrained abstraction though. > friendly syntax and semantics ... I don't think Haskell or Idri based languages will catch on. Bluespec took the approach of modifying Haskell syntax to look like Verilog. It's mostly quite effective, but I think they went slightly too far in throwing out some useful syntax features. Most notably, there are no lambda expressions in Bluespec, even though it could support them trivially. >HDL programmers are not generally good at programming I think this is a chicken and egg problem. HDLs suck, so there's not really any good practice to learn. Also competent programmers who can see the deficiencies tend to avoid the field. I'm working with Bluespec in a team of mixed EE and CS backgrounds, and the EEs are learning much better programming practices as a result. [1] https://github.com/aninhumer/mantle https://github.com/aninhumer/mantle
• spyder 12y ago
  Why does it seems better than D for you?
• fineline 12y ago
  I use NodeJS quite a bit, which has massive ecosystem, but recently (and especially After TJ Hollowaychuk's announcement about moving to Go) I've been taking a fresh look at these new-fangled systems languages, including Go, Rust and Nimrod, plus Apple Swift. If I'm going to tool and skill up in a new systems language, I want not just performance and nice syntax but also reach. Of the three, Nimrod is the only one with a convincing story for running on the main consumer platforms (iOS, Android, Windows), server platforms (Linux, *NIX) and embedded systems - because it compiles to C or Objective C (or JS for that matter!). That strikes me as a neat approach. Whilst there are attempts to get Rust and Go compiling for iOS, they don't seem very advanced. The small ecosystem is definitely a concern, but could also be an opportunity for a mid-sized IT corp to step into the ring with the big hitters and all their shiny new systems languages by backing this project.