8 ms·
Consider the Nimrod Programming Language
- joehillen 13y agoWhat is Scala doing in the same list with Rust, Julia, Nimrod, and C++? You do realize there is a JVM preventing it from being a systems level language, right? Also, you should need no more reason to avoid Scala than this: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg If you're interested in Scala, learn Haskell. It's faster, its design is re-enforced with proven mathematical concepts, and it doesn't have the worst syntax ever.
- dom96 13y agoPerhaps his intention is not to just compare system level languages.
- pjmlp 13y ago> You do realize there is a JVM preventing it from being a systems level language, right? You do realize there are quite a few commercial JVMs that generate native code AOT like any of the referenced languages, right?
- joehillen 13y agoThat's too terrifying to imagine.
- pjmlp 13y agoI fail to see why.
- sixbrx 13y agoI presume they still have a largish runtime attached with complicates FFI especially if callbacks are involved. I've found Java FFI to generally be a pain. Also, I think a lot of organizations would never approve using these in production, too likely that behavior will differ vs Oracle's or the OpenJDK VM's, the company won't be around in a few years, etc., and the gcj is very out of date from what I gather.
- pjmlp 13y agoI did not mention gcj, it is a dead project since 2009. I don't know, but I guess enterprises do trust Aicas, Aonix, IBM, Excelsior and quite a few others.
- stormbrew 13y agoHoly crap the music in that video's intro makes me feel like I'm about to watch the Hunger Games. And then it's just a guy talking.
- kasey_junk 13y agoThere are lots of reasons to choose Haskell over Scala, but a blanket statement that it is "faster" is idiotic.
- joehillen 13y agoBut it is faster. It's both faster to compiler and faster to run. I think it's a valid reason to prefer Haskell.
- nomad42184 13y agoExcept that it isn't faster at runtime (http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=ghc&lang2=scala&data=u32q http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...).
- Pacabel 13y agoIf you want to prove your point, using totally unrealistic micro-"benchmarks" such as those is by far the worst way about doing so. You're better off giving no evidence whatsoever than you are referring to those.
- yen223 13y agoAre there any more realistic benchmarks that we can refer to? Because I've read a lot about how Haskell supposedly runs faster because of its purity, but I've not seen a lot of evidence actually supporting that notion.
- igouy 13y ago"[B]etter off giving no evidence" than pointing to measurements that provide a known context -- source code, implementation version, command lines, measurement scripts... Nonsense.
- nomad42184 13y agoEveryone knows, of course, that these benchmarks don't tell the whole story. However, it's ludicrous to assert that providing no evidence is better than providing a array of microbenchmarks across a variety of different languages, machines and implementations. Further, the assertion that Haskell is "faster" (in some blanket sense) than Scala is completely evidence-free.
- barchar 13y agoNimrod's syntax is quite similar to scala (and Pascal!). Haskell can be really fast but fast Haskell and easy/safe Haskell tend not to overlap as much as one would like
- joehillen 13y ago> Nimrod's syntax is quite similar to scala What are you talking about!? Have you even looked at either? Nimrod: for i in 1..100: if i mod 15 == 0: echo("FizzBuzz") elif i mod 3 == 0: echo("Fizz") elif i mod 5 == 0: echo("Buzz") else: echo(i) Scala: for (x <- 1 to 100) println( (x % 3, x % 5) match { case (0, 0) => "FizzBuzz" case (0, _) => "Fizz" case (_, 0) => "Buzz" case _ => x }) In nimrod you'll notice a lot less parens, curly braces, and '=>'. > fast Haskell and easy/safe Haskell tend not to overlap as much as one would like Not even remotely true. Where did you even get that idea?
- dom96 13y agoIt really depends on what part of Nimrod and Scala you look at. The similarities are perhaps more apparent when looking at the function declaration syntax, generics and/or the variable declaration syntax.
- codygman 13y ago"fast Haskell and easy/safe Haskell tend not to overlap" I'm sorry, but the only people I've heard say this are those who are slightly open-minded about Haskell but truly believe it usually can't be remotely as efficient as imperative alternatives. None of the people I've heard make these statements have had even a few months experience writing Haskell. If you can qualify this, I'd be pretty interested. Or if you've had an experience with Haskell that led you to believe this, I'd like to see if there is another solution. I'm very interested in these limitations people always talk about with Haskell, but none of them have held up so far. I've been evaluating Haskell for a while and am very interested in testing any limitations you've faced.
- bsaul 13y agoThis video you've linked shows many general and philosophical statements but really not that many concrete examples... I stopped before the end because i got a bit fed up with general sentences like "complexity is the ennemy". From what i've read about the astonishing number of scala features, i am more than ready to believe him, but i would really need more examples...
- nomad42184 13y agoExcept that Paul Phillips has stated many times that he still programs routinely in Scala and, despite its flaws, considers it to currently be the best option. His arguments about what's wrong with Scala are compelling, but his continued use of it and desire to create his own collections library also speaks volumes.
- nomad42184 13y agoAlso, Julia has no business as a systems language either. I think it's a more general language comparison.
- andrewflnr 13y agoIt's a language that "attempts a speed-elegance unification", as the author specified before that list. It's not as if Julia is a systems language at all, but it also definitely belongs there.
- frowaway001 13y agoIf your plan was to make Haskell users look like douches, you are doing a pretty good job around here.
- chrismorgan 13y agoI must confess I got rather distracted by the number of spaces between sentences; I found everything from one space to six.
- geetduggal 13y agoYou have successfully spawned my OCD thread. I have attempted to fix a number of them, but it's more difficult in Wordpress.com land than I thought it would be.
- jmgrosen 13y agoI think the reason I don't like Nimrod is the same as the reason I don't like C++(11): it has too many features. Rust's (relative) simplicity and memory safety make it much more attractive to me.
- andreasvc 13y agoI think Rust is very interesting, but a language with a "periodic table of types" is definitely not one of the simpler languages out there. Just like the zero-cost abstractions of C++, the memory safety in Rust comes at a price of increased complexity.
- andolanra 13y agoI'd assert that the "periodic table of types"[^1] radically overstates the complexity of the Rust type system, largely because of the rampant misuse of the "periodic table" as a means of presenting groups of things. A "periodic table" of (for example) food items or Perl operators tends to have a bunch of distinct elements in its cells arranged by loose groupings[^2], whereas the Rust periodic table (like the periodic table of elements, but unlike other pop-culture periodic tables) has cells whose contents are for the most part[^3] a function of their row and column. Tabular nomenclature aside: Rust has values and two kinds of pointers, and a handful of built-in types, and you can have pointers to those types. While the semantics of the pointers are unusual, I don't think that makes it that much more complicated. It should also be noted that many of the proposed language changes make said table even more regular (e.g. replacing the [T] syntactic sugar for vectors with a more conventional Vec<T>.) Rust is in some ways complicated, and I'll grant that a beginner to the language will likely curse the borrow-checker more than a few times. But I don't think Rust is nearly as complicated as it is sometimes reputed to be. [^1]: http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/ http://cosmic.mearie.org/2014/01/periodic-table-of-rust-type... [^2]: http://www.ozonehouse.com/mark/periodic/ http://www.ozonehouse.com/mark/periodic/ is an egregious example. [^3]: There are exceptions (e.g. the closure types) but they are few and easily memorized.
- burntsushi 13y ago
- CyberShadow 13y agoSeeing as how both Nimrod and D have invested into metaprogramming (and also "attempt a speed-elegance unification"), I think a comparison with D would be interesting. D doesn't have AST manipulation, though; the "parallel for" idiom is instead accomplished rather mundanely, using a custom iterator (http://dlang.org/phobos/std_parallelism.html#.TaskPool.parallel http://dlang.org/phobos/std_parallelism.html#.TaskPool.paral...). Another similarity is uniform call syntax (which D calls uniform function call syntax, UFCS for short).
- TylerE 13y agoI'd say Nimrod feels like Python, D feels more like about what Java 9 or 10 will be.
- geetduggal 13y agoThanks for the suggestion, CyberShadow!
- barchar 13y agoNimrod is indeed pretty similar to D, although I think it is a bit more uniform because of the way the object model works. Also "death to mustache braces"
- charlieflowers 13y agoNimrod is pretty awesome for metaprogramming. If you can dig around on the Nimrod website and find docs about the html-producing language (same general goal as haml), that's a decent quick glimpse into the possibilities.
- lobster_johnson 13y agoNimrod is very interesting. As a former Delphi hand, Nimrod looks very much like a modern upgraded version of ObjectPascal, with some heavy influence from Python and possibly Ruby. The language is actually pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking something like Python/Ruby/Lua), and it's just amazingly fast, but not at the expense of ease of use. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right. As I wrote in a different thread, I and a colleague have been looking a little bit at using Nimrod as a game-logic language, as a replacement for Lua. Lua is pretty fast, but Nimrod is considerably faster; I'm personally also not a fan of Lua with its very weak table-based OO and rather idiosynchratic syntax, although I know it gets a lot of love on HN. What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In other words: If you write your core engine in C, scripting the game with Nimrod is (from what I can tell) as easy as with Lua. Very exciting.
- sergiotapia 13y ago>Go's performance has been too disappointing How so? Everything I've read online has been roses and unicorns in terms of it's speed and build times.
- lobster_johnson 13y agoBuild times are fantastic. Performance is still quite a bit worse than Java, actually. It has its own compiler, and so it doesn't benefit from the huge amount of work put into optimization in GCC and LLVM. Definitely not roses and unicorns.
- burntsushi 13y agoWhat is "quite a bit worse"? Is that 2-3x slower? Or 20-30x slower? It's my understanding that it's the former. And then there's memory consumption...
- ilaksh 13y agoI have used quite a few different languages and systems over the years, from SQL to C/C++ to OCaml, C#, D and more recently JavaScript and then CoffeeScript/ToffeeScript. And some others I better not mention. Last few years I have mostly been enjoying dynamic languages and the fact that I don't have to declare types. I have been doing programming mainly with ToffeeScript in Node.js recently. I was worried that I might find dealing with some types and an actual compiler for a static language to be burdensome. With Nimrod I have a syntax that's even cleaner than ToffeeScript and Python, which includes types inference to make type declarations minimal, and I actually find it easier to program with the type checking at compile time. Also my code is being compiled to C and then to native so it is very fast. And it has very powerful standard library. So what I have found is that not only does my Nimrod code execute vastly faster with much less memory than Node.js code, it builds much more quickly, and it is easier to read and maintain the code. One aspect of this is the fact that you don't have to use namespace qualifiers when you use module calls. Initially I was worried about that, since it is such a significant characteristic of Node.js code and point of pride for some. However, I think Nimrod has proven that this is the way to go. I can easily create my own DSLs with modules and extend the base programming system. This is something I tried to do with CoffeeScript because DSLs are powerful, but it was impossible to do it elegantly. I have not yet attempted to learn the metaprogramming features, but from what I can see, few, if any, other languages with such high performance and clean syntax can compare with Nimrod in terms of metaprogramming. I am quite glad that I found out about Nimrod before I got too caught up in Go or Rust. The syntax is much cleaner than Go, and the performance is better. The syntax is _much_ much cleaner than Rust, and overall its a much more practical language. What I am doing now and plan to continue doing as much as possible, is moving my web programming into Nimrod code. Basically I am doing this because I need less memory usage in an agent I am going to install for a service. I briefly considered using C or something like that, quickly decided to take advantage of a newer language, started looking at Go, briefly got excited about Rust, saw Nimrod and fell in love. This is the language that is going to make it most practical to achieve my goals, as well as allow me to stay engaged by learning its more in-depth features as time goes on. The only reason that Nimrod doesn't have instant uptake and popularity is that people don't evaluate things logically. Most people aren't capable of it, but even among the ones that are, peer pressure generally takes over. Humans are herd animals. They follow the crowd. If most people are driving cars that are four times as large as needed every day to work when they could just sign on to the internet and save gas, time, and the planet, then most people will do that, no matter how horrible it is. If most people choose a particular programming language even though it is inferior, then most other people are going to do that as well. But you can still be like the smart guy who was driving the small, efficient, fast electric vehicle before electric vehicles were cool.
- progman 13y agoI have used Nimrod daily for several months now, and I fully agree. It is actually one of the most productive languages that I have encountered so far. Perhaps you should add two more things to your feature list: 1.) Native Perl syntax 2.) C imports for seemless use of C functions: const txt = "x" const x = 123 printf "%s is %d\n", txt, x // or printf "%s is %s\n", txt, $x