Nim vs. Crystal

Maybe I'm misreading but to me this implies that the TechEmpower JSON benchmark doesn't use the `json` module. Just to be clear that is not the case, it uses the `json` module. Parsing performance is not benchmarked there, just serialization.

Julia. It’s fast, JIT compiled (static compilation is possible but it’s quite rough around the edges), has a fantastic type system, uses multiple dispatch to achieve some very cool stuff, has quite powerful lispy macros, and a really great community / library ecosystem, especially in scientific computing.

It also meets all of your other requirements, including the "isn't strictly functional" part (which is somewhat rare).

Scala has most of these qualities, but people say it's extremely complicated and supports too many different paradigms in a single language. I've never used it.

Nim? :)

I know, and it's unfortunate that there's not been time to work on this. I don't think people understand how small a language like Crystal is though. There's just one person working full-time on it currently!

If you'd like Windows support, one thing you could do to help is donate time or money to the Crystal project [1].

[1] https://salt.bountysource.com/teams/crystal-lang and https://opencollective.com/crystal-lang

Crystal looks like a great language, and clearly the developers aren't prioritizing Windows support - that's not a bad thing. But that does mean people who need to be able to use it on Windows have to look elsewhere.

- Cygwin (POSIX)

- Native Windows API support

Though I wonder if targeting .NET would be something to consider. It would not save much effort, compared to Windows API, but in principle, .NET is a portable platform (like POSIX).

Also I wonder why the LLVM project doesn't make it relatively easier to support multiple platforms (including Windows). The whole promise of LLVM is that your prog-lang just targets LLVM (so to speak) and doesn't have to worry about specific platforms.

[1] https://github.com/crystal-lang/crystal/issues/2569

Spin up a Linux VM and get developing?

I do .NET for my $DAYJOB and we use Windows for development. It works, but I wouldn't constrain myself only to Windows for development. I have an Ubuntu VM at home that I do dev in for other stuff.

Agree that performance comparisons between Nim and Crystal are going to be largely moot. They're both "fast enough" for their target audiences.

Once, a CSV-parsing and string-wrangling data batch job in python indicated it would take 27 hours to finish. I got annoyed and wrote a line-by-line translation in crystal. Writing it took about 40 minutes. It took a total of 2.5 minutes to run, that's two, almost three orders of magnitude.

As I said, this was a line-by-line translation, so whatever mistakes the python version had, the crystal version would have also had them. There are, however, a bunch of specialised python libraries (numpy et al) that weren't used, and I guess you could achieve some significant performance increases that way. Coming from ruby, I just happen to be quite productive in Crystal, to the point where I stumbled over the article's description as a "systems language".

For example, the JSON test was compiled with:

    $ nim c -o:json_test_nim -d:danger --cc:gcc --verbosity:0 json_test.nim

Stuff that is there might not be optimized yet. I hope as more people comb over the libraries we all get a boost here and there.

I like this description. Others said Ruby allows you to shoot yourself in the foot, I often think may be there should be gun control in the first place.

Edit: This list is a little old, The proliferation of programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you’re currently using. This handy reference, although not authored by me, is offered as a public service to help programmers who find themselves in such a dilemma.

TASK: Shoot yourself in the foot.

C: You shoot yourself in the foot.

C++: You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.”

Algol: You shoot yourself in the foot with a musket. The musket is esthetically fascinating, and the wound baffles the adolescent medic in the emergency room.

Perl: There are so many ways to shoot yourself in the foot that you post a query to comp.lang.perl.misc to determine the optimal approach.

After sifting through 500 replies (which you accomplish with a short perl script), not to mention the cross-posts to the perl5-porters mailing list (for which you upgraded your first sifter into a package, which of course you uploaded to CPAN for others who might have a similar problem, which, of course, is the problem of sorting out email and news, not the problem of shooting yourself in the foot), you set to the task of simply and elegantly shooting yourself in the foot, until you discover that, while it works fine in most cases, NT, VMS, and various flavors of Linux, AIX, and Irix all shoot you in the foot sooner than your perl script could.

Then you decide you can do it better with the new, threaded version…

SNOBOL: You grab your foot with your hand, then rewrite your hand to be a bullet. The act of shooting the original foot then changes your hand/bullet into yet another foot (a left foot).

FORTRAN: You shoot yourself in each toe until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue with the attempts to shoot yourself anyway because you have no exception-handling capability.

Pascal: The compiler won’t let you shoot yourself in the foot.

Ada: After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover you can’t because your foot is of the wrong type.

COBOL: Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be re-tied.

LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds…

Scheme: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds … but none of the other appendages are aware of this happening.

FORTH: Foot in yourself shoot.

Prolog: You tell your program that you want to be shot in the foot. The program figures out how to do it, but the syntax doesn’t permit it to explain it to you.

BASIC: Shoot yourself in the foot with a water pistol. On large systems, continue until entire lower body is waterlogged.

HyperTalk: Put the first bullet of gun into foot left of leg of you. Answer the result.

Motif: You spend days writing a UIL description of your foot, the bullet, its trajectory, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.

APL: You hear a gunshot, and there’s a hole in your foot, but you don’t remember enough linear algebra to understand what happened.

APL: You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.

Unix: $ ls foot.c foot.h foot.o toe.c toe.o $ rm * .o rm:.o no such file or directory $ ls $ csh: You can’t remember the syntax for anything, so you spend five hours reading man pages before giving up. You then shoot the computer and switch to C.

Ada: If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad, and tell the soldiers, “Shoot at his feet.”

Concurrent Euclid: You shoot yourself in somebody else’s foot.

370 JCL: You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.

Assembler: You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet and the trigger. And your foot.

Assembler: Using only 7 bytes of code, you blow off your entire leg in only 2 CPU clock ticks.

Modula2: After realizing that you can’t actually accomplish anything in this language, you shoot yourself in the head.

Visual Basic: You’ll really only appear to have shot yourself in the foot, but you’ll have had so much fun doing it that you won’t care.

SNOBOL: If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.

Paradox: Not only can you shoot yourself in the foot, your users can, too.

Access: You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.

Revelation: You’re sure you’re going to be able to shoot yourself in the foot, just as soon as you figure out what all these nifty little bullet-thingies are for.

May be this list should be updated with more modern programming languages.

    #[derive(Copy,Clone,Deserialize)]
    struct Point {
        x: f64, 
        y: f64, 
        z: f64
    }

    #[derive(Copy,Clone,Deserialize)]
    struct Schema {
        coordinates: Vector<Point>
    }

    fn main() -> Result<(), Box<dyn Error>> {
        let mut json_content = String::new(); 

        File::open("1.json")? // don't need Path 
            .read_to_string(&mut json_content)?;

        let schema = serde_json::from_str::<Schema>(&json_content)?;
 
        let len = schema.coordinates.length(); 
        let (x, y, z) = 
            schema.coordinates
                  .iter()
                  .fold((0.0, 0.0, 0.0), 
                    |(xsum, ysum, zsum), (x, y, z)|{
                        (xsym + x, ysum + y, zsum + z)
                    }); 
        println!("x: {}, y: {}, z: {}", x / len, y / len, z / len);
      Ok(())
    }

    let json_file = File::open(json_file_path).expect("file not found");
    let deserialized_camera: SomeDataType =
        serde_json::from_reader(json_file).expect("error while reading json");

The word "bias" has several meanings. One of them is an accusation that those two benchmarks were chosen specifically to produce the desired outcome. Considering the above, and that Base64 and especially JSON parsing are very common, I think it would be fair to allow for the possibility that the article's author chose them accidentally and not with any intent to deceive.

FWIW I was surprised by the article's focus on interfacing with C, something I have not done in 20 years of programming, and was wondering if it was a (possibly subconcious) choice to set up Nim to win.

    $ nim c -o:base64_test_nim -d:danger --cc:gcc --verbosity:0 base64_test.nim

    $ nim c -o:json_test_nim -d:danger --cc:gcc --verbosity:0 json_test.nim

Edit: It appears I'm incorrect, -d:danger does imply -d:release in newer Nim versions.

Also the good thing about the macro system is that you're trading off slower compilation for faster execution. A lot of the code you're using in Crystal which looks dynamic is actually just simple macros compiled to the bare minimum of code at the end.

If you have free time, or free money, it'd be a great help to the effort.

You can even use numpy in nim: https://forum.nim-lang.org/t/4102

But why use that when you can use Cuda and OpenCL accelerated vector math: https://github.com/mratsim/Arraymancer

If thats too much speed, you can just roll your own for loops. Because Nim is compiled with battle tested GCC, LLVM or VC++ it will try to SSE optimize your code if you pass the right switches. If you know what CPU your computer/server has you can compile with newest brand of high performance instructions like AVX2, or even the newest AVX512VNNI...

For a language which claims to be fast, having to use a C-based JSON parser would be a bit of a cop-out :)