When I started an enterprise data project with a small team where Python was the familar workhorse we stopped for moment initially to think of ways to improve performance. Cython was the familiar route with Python but we started building small prototyes in Rust, Go, and Nim. Beyond the basics our progress slowed down with Rust and Go (yes, I know Go is very easy for some) but Nim allowed us to put together a fully fairly complex application in short time. Just one book, 'Nim in Action', gave us all the ropes, every example in it worked (thanks Dominic), and some of our key integrations such as Postgresl Client drivers, built-in web UI (Jester) framework, Json processin, Nim's build/packaging support, generics, fast static typechecking, etc were exceptionally robust (for this young a language) and worked in an intutive way for us ... we reached production rather smoothly.

I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.

I heartily wish that you continue learning Rust, another significant contribution to open source languages. What has been already commented, things such as borrow/checker are humps you work through and it will work out for you eventually. The other challenges are some of your enterprise 3rd party integrations with the outside world, some of which may again demand your time if they are still in beta, etc.

Also, the organization has no desire to invest in training or experimenting. The project is funded by the "business" and they want to see a business result in return for their money ... so you basically you sneak in a bit of time as you try/test something new. Nim won out by somehow getting a team with python expertise learn and deploy their product fast enough.

Is there a site(s) where there is specified how to represent more complex data structures while making the borrow checker happy?

When you've internalized its rules, the borrow checker isn't too complicated to keep happy (you may need to use stuff like RefCell and Rc though). It takes some time though, and this tutorial helped me a lot in the beginning: https://rust-unofficial.github.io/too-many-lists/

This does not answer op question on why Rust was dropped ?

just keep at it, eventually you run into data structures hard to represent with a borrow checker and it will slow you down, at least at first

At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there.

You could also describe it as being competitive with Rust, but with more compromises for the sake of developer ergonomics. Garbage collection, for example.

For my part, I'm finding it attractive as a potential Java-killer. It isn't write-once-run-everywhere, but, now that x86 and Linux have eaten the world, that's not quite such a compelling feature anymore. And Nim smooths things over a bit by making cross compiling dead easy. In return, I get better type safety, better performance, a much better C FFI, and less verbose, easier-to-understand code.

I disagree in quite a few respects.

I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong.

Aside from significant whitespace, I don't find that many similarities with Python syntax.

Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional elements, just like Python.

"Firmly statically typed" is misleading. It's actually strongly-typed with great capabilities around type-inference so that, at times, you start to forget that it's typed in the first place and gives you a similar feel to a dynamically-typed language like Python.

Nim can run with garbage collection disabled. As a matter of fact, I seem to recall that the authors postulated that as a basic requirement that the language should be able to run in a low-level systems programming mode with garbage collection disabled (where it would be able to compete with Rust), and in a more high-level mode where it would rather compete on developer ergonomics/productivity.

I find Java-killer a potentially misleading analogy. I do think that it captures the kind of platform-independence that matters nowadays. And that is no longer Intel vs Sparc and Windows versus Linux, but rather the native ecosystem versus the JavaScript ecosystem.

Not agreeing or disagreeing with either of you just wanted to add some details to the garbage collector thing.

Nims GC is able to either be controlled in terms of when and how long it runs, and it can be completely disabled in favour of manual memory management. In fact people have gotten it to run on really low-powered microcontrollers like the Attiny85, as well of course as various Arduino boards. The benefit of Nim in these systems is that since it compiles and has such a rich macro system your are able to write abstractions that the compiler will turn into highly efficient code. So you can still write business logic level readable and maintainable code, while the compiler spits out super-optimised versions. This of course requires you to first write these macros, but often times a little goes a long way.

In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

<subjective>

Well: Nim is similar to Python in many respects, it's just not "C-flavored Python".

It has significant whitespace like Python. But since it has a lot of language constructs that are different from Python, it's a bit tedious to try to otherwise compare the syntax a great deal, and it has many elements to its syntax that are quite unique.

Saying that Nim is statically typed whereas Python is dynamically typed is exactly a feature that's a slightly unfortunate pick for trying to contrast the two, because type inference is trying to bridge the gap and give you something that's a bit in-between in terms of how it feels to the programmer.

Nim is similar to Python in that (a) It's very cleaned-up and allows you to do a lot of stuff and complex stuff with little code, without sacrificing clarity and readability. (b) It puts the programmer in a cognitive mode where he can think first and foremost about the problem at hand and not have to concentrate on the programming language so much. (c) It gently guides the programmer towards good programming practice without being patronizing. (d) It has a fast learning curve,...

Essentially all the things that make Python great are found here as well. But nim gets there on its own, not by replicating elements found in Python a lot. It's very unique in a way that makes nim a great choice of language in situations where Python isn't (like systems programming or writing code for the Browser ecosystem).

</subjective>

I'm not sure I should be getting involved, here, but I haven't had my morning tea yet, so what the hey --

It seems like you're hyper-focused on a rather skewed interpretation of my first sentence, to the point that you largely ignore the second sentence. Or at least you seem to ignore everything after the word "but", which, given what the word "but" is often used for, is a rhetorical move that has a way of enabling interpretations that tend to be close to the opposite of whatever was originally intended.

Parent poster has it right. I picked that initial comparison to Python by way of introducing one of the more popular summarizations of Nim, so that I could say why I don't think it's a good summary. If I didn't put it emphatically enough to satisfy you, I apologize. I apparently don't have anywhere near as strong of feelings on the subject; Nim's just a language I like to program in sometimes.

> In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.

Probably because most people are more familiar with Python than Ada and Modula (combined) ;)

I guess it depends on your previous experience. Some people will only see Python, others might think of Nim and its syntax as "Pascal for 21st century" (fun fact: the original Nim compiler was written in Pascal).

We already got a Java-killer: Kotlin

Don't get me wrong; Kotlin is a great language and, if I have to work on the JVM, it's one of my top two picks.

But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are characteristics of the JVM's run-time environment, not the language you're using to target it.

Most of those Java shortcomings are in the process of being fixed, while still enjoying one of the best language eco-systems currently available, with libraries for almost any kind of problem domain.

Kotlin is no Java killer.

The only KVM in town is Android.

Nim's syntax is very similar to Python simply because both are expressive, lean and have no braces. Naturally Python is dynamically typed and this, unfortunately, affects performance and maintainability.

To me Nim is a faster python that prevents typos. It can also compile to javascript.

I used it where I would use python - backend of web apps. But now instead running a cluster of servers I can just run 1 because nim is fast.

I also used to write frontend in CoffeeScript, but switched to nim because I can share code between backend and frontend. I don't have typos. I don't inherit any JS or OOP legacy like TypeScript.

> faster python that prevents typos

This was sort of my use-case and experience as well. I also find it can do what I needed JavaScript-based CLI tools to do with less dependencies/ecosystem bloat, and the resulting code is a lot nicer to work with. People have told me that's because I was using JS wrong, but I felt like Nim was such a huge step up for my use cases.

It's also just a pleasure to learn something new occasionally.

Do you use any JS libraries in the front end?

I stumbled onto nim because a sequencing-data (DNA/RNA/etc) library was written for it (https://github.com/brentp/hts-nim). In addition to Go, it's been a great way to learn a compiled language. It's fast, easy to use, and has a friendly community.

How good is nim performance with sequencing-data in comparision with other programming languages you used for it before?

Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.

I think it depends on the nature of the code.

For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of implementation, it runs quick. Sorry I can't provide more details on nature of the code (it has IP that belongs to another person).

Here are the top 10 best execution times (all run on same hardware). Times obtained by 'time' utility (e.g., "time ./run.sh"). Some of these were run on Ubuntu 16.04 and a few were run on FreeBSD 11.2. Where the compiler has optimization flags, I used it.

1. C++ 0.04 (gcc version 5.4.0) 2. Rust 0.11 (version 1.37.0) 3. Go 0.13 (version 1.12.7) 4. D 0.16 (tied with Pascal) (DMD64 D Compiler v2.073.2-devel) 5. Pascal 0.16 (tied with D) (fpc 3.0.2) 6. C# 0.25 (mono 4.8.1) 7. Nim 0.50 (1.0.0) 8. Kotlin 0.81 (Kotlin version 1.3.50-release-112, JRE 1.8.0_222) 9. Java 0.95 (openjdk version "1.8.0_131") 10. Scala 1.79 (version 2.12.2, running on 1.8 openjdk)

Replying to my own post to provide better formatting of execution times.

  1. C++     0.04  (gcc version 5.4.0)
  2. Rust    0.11  (version 1.37.0)
  3. Go      0.13  (version 1.12.7)
  4. D       0.16  (tied with Pascal) (DMD64 D Compiler v2.073.2-devel)
  5. Pascal  0.16  (tied with D) (fpc 3.0.2)
  6. C#      0.25  (mono 4.8.1)
  7. Nim     0.50  (1.0.0)
  8. Kotlin  0.81  (Kotlin version 1.3.50-release-112, JRE 1.8.0_222)
  9. Java    0.95  (openjdk version "1.8.0_131")
  10. Scala  1.79  (version 2.12.2, running on 1.8 openjdk)

I am pretty sure it should be very close to or the same as C++. Ask around on the Nim forum.

And the x2 difference between C++ and Rust looks suspicious too.

Obviously, if you measure cold starts, JVM-based languages will be slower...

Agreed. I include them in the list as a matter of completeness.

Surprised to see Nim that slow, typically it ranks much higher in benchmarks. But without looking at the code and compiler options its hard to tell if it is simply the problem or the implementation that's to blame.

There are many other benchmarks around where Nim is usually quite close to C. Perhaps Nim was not compiled in release mode.

or possibly was a line-to-line translation of the original test without using any peculiarities of Nim.

I'm very surprised to see rust that slow. Could you share at east parts of your code?

I have only used python (check out cyvcf2 by brentp!), R, and bash previously - so nothing else really compiled (its faster than these in general). But my guess is that you will have an easier time writing nim than the alternatives, and after that it is easy to optimize once you have basic functionality.

That's exactly how I found it as well. Brent has some really high quality bioinformatics libraries written in Nim, and supports them well.

For me, personally, the biggest points for Nim are:

- "Transpiled" to C, with some options regarding runtime library, which means you can target any uController out there

- Good metaprogramming support

- Static and _strong_ typing

- Consequently, precise type aware function dispatch

- Type inference

- Good generics

Also, more stuff like covariants and contravariants and... maybe you just have a look-see? ;-)

I'm already quite invested in Kotlin, and having a look at Elixir... on top of my regular work. Time is a limiting factor :-)

There are "concepts" which are like generics but still experimental. Are there any other generic programming facilities in nim?

https://nim-lang.org/docs/manual_experimental.html#concepts

> Are there any other generic programming facilities in nim?

https://nim-lang.org/docs/manual.html#generics

What I wanted to write was something like type restricted generics, apparently I ended my comment prematurely. Without concepts (interfaces), I find it hard to call this system "good generics" but there might be something I'm missing.

Nim occupies an interesting place between Rust and Go. It has an easier learning curve than Rust. I picked up the basics in a weekend, and some of the more advanced functionality over a month. The optional GC is ideal for the application space, and I also don't find myself fighting the compiler very frequently. When compared to Go, Nim provides a lot more functionality. Object variants, a working implementation of generics, not to mention a great macro system.

Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?

Sometime people troll by sealioning: http://wondermark.com/c/2014-09-19-1062sea.png

(I'm not accusing the granparent post)

I've seen that comic before but have no idea what it's trying to express, could you explain? Is it just when you repeatedly pester someone with questions to annoy them?

Unfortunately, asking questions on the internet is often seen as "opposing" or "arguing against" the thing you're asking about. So many qualify their statements to avoid this sort of misreading.

Which just makes things worse. Having to qualify everything by default is a whole lot of foolishness.

It all depends on the tone of the question, which is hard to discern in writing, so the clarification is helpful.

Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of trolling. I am trying to express my agreement with both parent and grandparent.)

Asking a question in plain English like this shouldn't require further clarification.

Communication by writing is harder because you miss facial expressions. Because of this, a lot of it is subject to interpretation on the part of the reader. The tone can be inferred from a lengthy piece, but not so much from a small paragraph.

So, in order to avoid bias on the reader part, I preferred to explicitly tell it was not trolling.

It occupies more or less the same space as Go: it produces fast standalone binaries with garbage collection. However, unlike Go, it isn't shy to give more features to the programmer to play with.

The cons are its lack of enterprise backing, its smaller community and its syntax, if you don't like either Pascal or Python.

No: you can create system libraries in Nim, unlike Go.

You can also entirely disable the GC or replace implementation.

Nim can run without OS and on microcontrollers.

It's as easy as Python and as fast as C. That was my take when I looked at it and bought the book last year.

I read the first few chapters of that Manning book. I really enjoyed it.

> as fast as C

I mean, it actually is C, since the code is transpiled to C.

The fact that it uses C as a compilation target doesn't have much to do with whether it's as fast as C in practice. It's easy to imagine a compiler that generates C but generates terrible C that runs really slowly. (E.g., imagine it goes via some sort of stack-machine intermediate representation, and variables in the source language turn into things like stack[25] in the compiled code.)

Or consider: Every native-compiled language ends up as machine code, which is equivalent to assembly language, but for most (perhaps all) it would be grossly misleading to say "as fast as assembler".

In fact, you can transpile Python to C with Cython. That typically gets one a speed boost, but only a bit. You still have most of the memory allocation/deallocation overhead of Python objects getting created and destroyed, and all the work needed to keep attributes tracked, so a straight C version with no focus towards optimization would likely outperform it greatly.

(A neat tool in one's toolbox, of course. But just transpiling to C does not get one as fast as C.)

I’m not sure that I understand your argument. If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” … because, at the end of the day, it actually is C. Being “as fast as C” means that your resulting program will perform as fast as a C compiler [worth its salt] can get you.

Your comparison to machine code (or human readable assembly code) is less useful in that such a statement means very little until one knows how said machine code is being produced (e.g., manually, from a IR, etc.).

"As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent", not as "there is a C program with the same performance characteristics".

That a language is compiled to C does not mean that its compiler is going to be able to produce a C program that's as good as a that well-written C equivalent. (A relatively obvious example would be a compiler that introduces a heavy runtime, and doesn't give the C compiler enough information for it to get rid of the runtime)

It's the same with assembly code: that a compiler produces assembly does not mean the resulting program is fast.

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent"

That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

Remember that we're comparing languages, not programs. A language can be thought of as the space of all programs that can be interpreted by that language. In any language, any algorithm can be implemented arbitrarily slowly. So the only meaningful point of comparison between language X and language Y is the upper bound on the performance of each language's program-space.

That some particular C program exists that is at least as slow as a program in some other language is always true, trivially, and so is not a good interpretation of "as fast as C" regardless of its objectivity.

You're missing the point. The fact that a language compiles down to C doesn't mean it compiles down to efficient C. At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C. But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code. This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

> The fact that a language compiles down to C doesn't mean it compiles down to efficient C.

Where do you see me claiming otherwise?

> At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C.

Again, why are you telling me this? Please quote where I claimed otherwise.

> But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code.

The more that I read your response, the more that it seems that you’re debating yourself, because I’m not sure why you’re telling me this. You started your response by telling me that I’m “missing the point” when, in reality, you seem to have not even read my point. My main point was the following:

> If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” […] your resulting program will perform as fast as a C compiler [worth its salt] can get you.

This is true. I made no claims re efficiency; “as fast as C” and “as fast as efficient hand-written C” aren’t interchangeable claims. Forgive me for not assuming efficiency, because I’ve seen a good amount of inefficient hand-written C code in my years.

> This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

Says who though? I’m professionally experienced in C, and as is very clear by this discussion, it’s down to individual interpretations.

But that's not at all a useful way to describe a language. Why would someone ever describe a language as "as fast as C" and not mean "as fast as typical hand-written C"? What would be the purpose of that? With your interpretation, CPython is "as fast as C", since it's written in C, and yet that's not a claim anyone would actually make.

Suppose I claim that some programming language achieves performance "as fast as C". Then, unless I very clearly and explicitly say otherwise, it will be assumed that if I write kinda-C-like code in that language I will get performance similar to comparable code actually written in C.

But that doesn't at all follow from compiling to C. I gave one example above; here's another. Perhaps my programming language has arbitrary-length integers and the C code it produces for a simple loop looks something like this:

    bignum_t i = bignum_from_int(0);
    bignum_t x = bignum_from_int(0);
    while (i < bignum_from_int(1000000)) {  
      bignum_add_in_place(x, bignum_bitand(i, bignum_from_int(1)));  
    }

Corresponding code in "normal" C would use machine integers and the compiler might well be able to understand the loop well enough to eliminate it altogether. Code like the above would run much, much slower, despite being technically in C.

JVM, CLR, Python bytecode or Lua JIT code are ultimately all transformed into machine code but those are not as fast as assembler.

Being as fast as C is not about using C as an intermediate language but having data structures and control flow that resemble what C compiler have been optimized for.

Case in point, Haskell GHC is capable of outputting C code but the algorithm will not get C performance (or Haskell performance without this intermediate C representation).

Nitpick, but it actually compiles down to C. Nim works at a higher abstraction and the compilation is a one-way street. But what is more important is that it generates efficient C code, it looks ugly, and it's not something you would ever dream of writing yourself, but it's been optimised to give fast run-times. Often times in benchmarks the Nim code with optimisations comes out as fast as the C code with optimisations, even in some cases beating it.

Since you seem to know how this works -- I hope you won't mind if I ask you a slightly on-topic question about this...

I've been trying to find out if I can take the generated C code that nim produces and, for example, compile it on some exotic architecture (say an ancient solaris/sparc system or some aix/power thing, or some mips microcontroller with linux) however I can't find any examples of people doing this...

Is it possible? Or should I abandon hope and continue writing C for these platforms? :}

Are you sure your OS/CPU is not on this list? :) https://github.com/nim-lang/Nim/blob/devel/lib/system/platfo... And yes, compiler works on almost all of them (you can see which ones are precompiled in csources - https://github.com/nim-lang/csources/blob/master/build.sh#L7... )

And for CPUs - https://github.com/nim-lang/csources/blob/master/build.sh#L1...

Yeah you can get to the generated C. See this SO question.[0]

Give it a try :)

[0]https://stackoverflow.com/questions/29956898/how-do-i-get-th...

As the others have said it should be possible. Nim is already pretty good at cross-compiling, but it is also able to just spit out the C files it generates and allow you to play with those.

Yes, Nim can run on all sorts of architectures including AVR microcontrollers, MIPS, RISC-V.

What you said here was literally my point. Maybe you misunderstood me?

I think the point is the terminology, Nim doesn't transpile it compiles to C.

"Transpile" is such a nonsense term that I don't think it's useful to split hairs here.

I'm from Status, Nim's main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim.

Nim had the following appeal for us:

- Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story).

- Nim allows us to use a single language for research and production: the Python syntax, and the fast compilation speed are very helpful. In particular researchers found the Nim codebase easy to debug as the overhead vs the Python spec was quite low (and the Python spec is using types with mypy)

- Nim has a easy C FFI and is one of the rare languages that can directly use C++ libraries, including header-only template heavy libraries.

- Nim allows tight control over memory allocation, stack vs heap objects, has support for Android and iOS and very low-memory devices as well.

- Nim also can be very high-level

- Nim is as fast as C and can resort to inline C, inline C++ or inline assembly when needed. (inline javascript or Objective C are possible as well)

- You can produce WASM code via clang, emscripten, binaryen, there is even a Nes emulator demo from 2015 running in Nim compiled to WASM here: https://hookrace.net/nimes/

- Nim has a strong type-system, including generics and type-level integers, boolean and enums.

- Nim has probably the best compile-time capabilities of all languages. I'm writing a deep-learning compiler in Nim macros. Someone wrote a Cuda code generator in Nim macros, and the code generation is extremely nice to write a VM, an emulator or any kind of assemblers as you don't need to use an intermediate step to generate your opcode tables or generate your functions from that table.

Now on a personal note, I use Nim to write a deep learning framework similar to PyTorch or Tensorflow.

I think it's the best language to solve the 2-language problem, i.e. write research in Python, R or Matlab and production in C, C++ or Fortran.

The operator overloading or even operator creation is very useful. The macros allow me to have a slicing syntax similar to Numpy, something impossible in C++. Compilation speed is very nice as a developer, I don't know how people deal with waiting for C++ CI.

I reimplemented a matrix multiplication with performance similar to handwritten assembly BLAS from OpenBLAS and MKL in pure Nim so I'm not worried about performance as well.

Now I'm onto refactoring the backend with a proper compiler (similar to Halide but since it will be macro-based, there won't be the 2-stage compilation issue)

I like Nim very much, however I do not think it will solve the 2 language problem. One of the things I lean on heavily in Python when experimenting and researching is the dynamic nature of the language. I believe this is also a strong factor for others.

For me, Julia completely addresses the 2 language problem. In practice I think it now simply needs a stronger ecosystem, better static analysis, and bug fixes, but I am very happy with the language design.

Some good arguments, but the "main sponsor is blockchain-y" was a bad start for me. That totally killed my interest in RED... Is this as in "biggest patreon donor" or "company that employs main developer(s)"?

Well the Nim team at Status is a separate team working on an open source Ethereum 2.0 implementation, rather than any blockchain 'product' (unless you count a working 2.0 client as a product).

Their goal is to get Eth2.0 (and 1.0) running on very low resource environments such as raspberry pi and turnstiles.

What this should tell you is that:

* Nim is close to the metal enough to run with high performance and low resources.

* In a cutting edge research arena, where the math is still being decided, Nim allows such rapid prototyping that the team is on par with much larger teams in much more established languages.

* All the tools required to build an ethereum platform are present and running, such as security, encryption, and networking such as devp2p. Here's their eth library docs for some of the contributions: https://nimbus-libs.status.im/lib/nim-eth/

Status is pretty dedicated to open source, and whilst they're the biggest patreon donor, the Nim team is completely autonomous.

It's as in "biggest patreon donor".

> ...something impossible in C++

    vec[3_s & 4] 

is very much possible in C++. It's only two characters longer.

(C++ doesn't have a ':' operator, you'll need to use some other symbol.)

I've used it to develop command-line based utilities. The binaries tend to be small and fast.

Are any of these open source? Would love to check them out.

These are both works in progress! But here is the first one for working with sequencing data:

https://github.com/danielecook/seq-collection

And the second:

https://github.com/danielecook/tut

The second one has a really useful utility called "stack" that you can use to concatenate datasets where one might lack some columns or the columns come in a different order. It glues it all together and has an option to include the filename. It's useful for data analysis.

Both of these lack 'polish' at this point but a few of the subcommands work quite well.