It's a system language that's focused on readability and performance. It has OOP but isn't focused on it, and has some of the best AST metaprogamming out there built in as a core principle, so it's easy to extend the language. Strong static typing with type inferrence, specific type for garbage collecting (ref type) - everything else is on the stack by default, or you can manually manage memory.

Looks a bit like Python, compiles to C, C++, ObjectC, Javascript and experimentally to LLVM. Good support for Windows, Linux and Mac (and anything you can target a C compiler for). Performance matches equivilent code in C, C++, and Rust. Programs compile to stand alone exes making them easy to distribute. Compilation is very fast.

If I only have one thing to say about it, my personal experience has been that Nim makes programming more fun by being really low friction; it just gets out of your way, yet runs really fast. It's great for scripting out a prototype for something, but because of the high performance that prototype can be expanded into a full product. It also helps that you can write server and client code in the same language too.

Sadly, “Look at Nim” seems to be the new “rewrite it in Rust”…

I was responding to:

> ...great tooling and moderate performance. There are many aspects to programming languages beyond raw speed. The world has enough cookie cutter procedural and OOP languages. I'd love to see a new language from a different paradigm succeed.

Nim's paradigm is fairly open (no small thanks to metaprogramming and unified function call syntax), and drops a lot of the baggage from the usual class (ahem) of OOP languages. There's loads of mainstream languages that focus entirely on OOP and I really resonate with wanting to explore different approaches to creating solutions, as I think OOP tends to colour how a language approaches problems.

Seems a bit sudden to jump from my posting a reply to this as the same vein as "rewrite it in Rust".

In terms of languages with existing dependent type implementations, it looks like the main options would be ATS, Agda, F*, or Idris. Some of these are pretty far away from the OOP paradigm too.

Also:

> Nim doesn't have them and never will

https://github.com/nim-lang/RFCs/issues/172

This* is an OK response to the original question.

> Seems a bit sudden to jump from my posting a reply to this as the same vein as "rewrite it in Rust".

The thing is: 90% of comments talking about Nim comes from people like you, whose entire comment history is over 90% about Nim, and most of the time, it comes in context where it's borderline irrelevant to the subject.

Aggressive proselytism like this has hurt Rust a lot, and it's definitely going to hurt Nim as well if you aren't careful.

It seems like when talking about a smaller language you have to walk that fine line between putting an experience of using them out there, and being a PR ambassador. I'm really not into that, but I guess that's the reality.

Creating a new systems programming language like C++, Rust or Zig is by contrast a lot more effort and means having significantly worse support for debugging and IDEs unless you put a lot of effort in (generating good DWARF debug data for a new language is hugely complex).

Not sure I understand what you're suggesting. I was asking for a language with dependent types (or anything that isn't just another procedural/OOP language). Such a language could use any runtime, whether it be the JVM or anything else.

I’m working on a language based around the recent work of Pfenning, Reed, and Pruiksma (Adjoint Logic) and Krishnaswami’s Dependent/Linear research (both of which go back to Nick Benton’s ‘94 work). It is definitely not OOP, it is a compositional language (a lot like the concatenative language family) and is rooted in explicit parallel and sequential composition. With one of the adjoint logics being the type theory implementation of Intuitionistic Logic (Martin-Lof Dependent Type Theory).

There are people working on things all over the non-OOP and the advanced static types spectrums, don’t loss faith in progress yet. I have plans to release the 0.1 website and ‘compiler’ before July 1. Of course it is going to be a bumpy road, but I’m having a great time working this project.

I'd propose to have a look at Swift. It is very similar to Rust in many aspects (particularly the type system), with slower performance (due to some of the abstractions). The tooling on macOS is already really good, on Linux it is getting there, and on Windows the next release will add official support.

I'm of the impression that Swift is reference counted, which, while technically a kind of GC, is also appropriate for low level / systems programming (which isn't to say that Swift is a good language for low level / systems programming; only that its memory management isn't the disqualifying factor).

You can make RC quite nice (I've written cycle collecting implementations before) but there's reasons why C++ programmers are encouraged generally to avoid shared_ptr and use unique_ptr whenever possible: harder to reason about or trace object lifetimes, and performance implications.

Now if the garbage collection was optional, and one could still freely heap or stack allocate and free, then, yes, I could see it. But I don't think that's the case w/ Swift, at least not last time I looked at it. It's also why Go is imho not a 'systems' programming language.

Swift has what you would call an ‘indecent’ RC design, then, because it doesn’t.

> and it usually plays havoc on L1 cache (by touching counts).

Swift (like Objective-C) can store the refcounts either inline or in supplementary structures, for performance.

> Now if the garbage collection was optional

In the common case, it practically is, as (most) value types will only ever live on the stack, or inline in another data structure.

Glad to hear that value types are optimized well.

I think they've done an incredible job with their ObjC interop, given said mismatch.

But you're right — the person above who said that

> The world has enough cookie cutter procedural and OOP languages.

definitely isn't looking for Swift.

Which is to say, the Swift devs have done an incredible job of solving the wrong problem.

Apple needed a modern language for faster, easier Cocoa development. What they got was one that actually devalues Apple’s 30-year Cocoa investment by treating it as a second-class citizen. Gobsmacking hubris!

Swift was a pet project of Lattner’s while he was working on LLVM that got picked up by Apple management and repurposed to do a job it wasn’t designed for.

Swift should’ve stayed as Lattner’s pet project, and the team directed to build an “Objective-C 3.0”, with the total freedom to break traditional C compatibility in favor of compile-time safety, type inference, decent error handling, and eliminating C’s various baked-in syntactic and semantic mistakes. Leave C compatibility entirely to ObjC 2.0, and half the usability problems Swift has immediately go away. The result—a modern dynamic language that feels like a scripting language while running like a compiled one, which treats Cocoa as a first-class citizen, not as a strap-on.

(Bonus if it also acts as an easy upgrade path for existing C code. “Safe-C” has been tried before with the likes of Cyclone and Fortress, but Apple might’ve actually made it work.)

Tony Hoare called NULL a billion-dollar mistake. Swift is easily a 10-million-man-hour mistake and counting. For a company that once prided itself for its perfectly-polished cutting-edge products, #SwiftLang is so very staid and awkward-fitting.

Objective C already had Smalltalk-style message dispatch syntax, and something fairly close to Smalltalk blocks/lambdas. So it's not like existing Cocoa programmers would have been frustrated or confused.

Clearly the original NeXT engineers were inspired by Smalltalk and wanted something like it, but had performance concerns etc, perhaps there would have been performance concerns with moving to a VM based environment for mobile devices, but I think with a modern JIT these problems could be alleviated. As we've seen with V8, etc..

So I think it was actually a missed opportunity for Smalltalk to finally have its day in the sun :-)

Alas, I think decades of C has trained programmers to expect and accept lots and lots of manual drudgework and unhelpful flakiness; worse, it’s selected for the type of programmer who actively enjoys that sort of mindless makework and brittleness. Busyness vs productivity; minutiae vs expressivity. Casual complexity vs rigorous parsimony.

Call me awkward, but I firmly believe good language design means good UI/UX design. Languages exist for humans, not hardware, after all. Yet the UX of mainstream languages today is less than stellar.

(Me, I came into programming through automation so unreasonably expect the machines to do crapwork for me.)

Re. JIT, I’m absolutely fine with baking down to machine code when you already know what hardware you’re targeting. (x86 is just another level of interpretation.) So I don’t think that was it; it was just that Lattner &co were C++ fans and users, so shaped the language to please themselves. Add right time, right place, and riding high on (deserved) reputation for LLVM work. Had they been Smalltalk or Lisp fans we might’ve gotten something more like Dylan instead. While I can use Swift just fine (and certainly prefer it over C++), that I would have enjoyed. Ah well.

I agree Dylan (or something like it) would have been a good choice, except that it wouldn't mate well with the Smalltalk style keyword/selector arguments in Cocoa, also it has the taint of being associated with the non-Jobs years and so maybe there would have been ... political... arguments against it.

They just needed a Smalltalk dialect with Algolish/Cish syntactic sugar to calm people down, and optional or mandatory static typing to making tooling work better.

Or, to borrow another Tony Hoare quote:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

..

Alas, big complex codebases facilitate fiddling with the details over substantive changes; and that’s even before considering if the Swift language’s already-set syntax and semantics are amenable to expressing concepts they weren’t originally designed for. Stuff like Swift evo’s current thrash over trailing block[s] syntax reminds me of Python’s growth problems (e.g. its famously frustrating statement vs expression distinction that’s given rise to all its `lambda…`, `…if…else…`, etc nonsense).

It’s hard to scale after you’ve painted yourself into a corner; alas, the temptation is to start digging instead. I really wish Alan Kay had pursued his Nile/Gezira work further. That looked like a really promising approach to scalability. We really need better languages to write our languages in.