As fan of Wirthian languages and GC enabled systems languages it looks nice to me, but it is still miles away of the tooling experience available to Java and .NET developers, and yes, you can make use of AOT or JIT caches with them.

But the more the merrier, so I look forward to its bright future.

I'm planning on trying out the new Prologue framework. Seems promising from the readme! https://github.com/planety/prologue

I’ll never understand what people see in prologue

What do you recommend instead for web development with Nim?

My guess is the GP misunderstood and was speaking about the Prolog programming language, not the web framework mentioned.

To address your question, the only complete back end web framework for Nim that has significant traction (that I know of) is Jester. Karax for the front side. The Prologue framework looks interesting though.

I've been building and deploying Nim web apps for clients over the past couple years. The language is just getting better and better and the library environment is filling out nicely too (not to subtract from the stdlib, it's very complete too). It's been a really great experience.

Also: available to hire if anyone is looking to work with Nim.

Are you using Jester or another framework?

Largely building microservices with the stdlib. Generating html frontends with htmlgen. Using karax for more dynamic frontends.

How would the dynamism and expressivity of something like Django port to Nim? I love the whole declarative paradigm of the Django forms and models API. Is Nim good at this kind of DSL-ish plasticity?

Extremely well I'd say. Nim has a very powerful macro system, and DSLs are very common across various modules. Haven't used Django myself, but something like Jester (https://github.com/dom96/jester) or Karax (https://github.com/pragmagic/karax) is a good place to start if you want to do web development in Nim.

i'd say so: i think many rails/django concepts are translate-able to metaprogramming in nim, not always with the same idioms, but usually there is a way to do it, and you can typecheck some things

I feel DSL-ish ways of Nim are so much more advanced then python.

I have written UI DSLs in Nim, as well as SQL DSLs. Only LISPy languages come close to the level of DSL you can do.

What advantage does it bring that Kotlin hasn't?

Having only played a little with both (Kotlin and Nim), I enjoy Kotlin syntax but overall it feels as heavy as Java (need to setup an IDE for even getting started, choose and understand some package manager, slow compile times, etc.)

Nim feels as lightweight as Go, but with great syntax. The main thing holding me back now is the lack of libraries, but it's definitely on my radar.

Isn't an ide just a choice? You don't have to use intellij. There are vscode plugins.

Don't you also need to understand the go package manager or Nim's? I don't see how this is different than learning Gradle.

Better than having to choose an IDE, is to not have to choose an IDE.

It’s pretty liberating to put some text in a single file, pass that file to a compiler, and have a single executable binary.

A devolved workflow I know.

Devolved, but still superior in some ways.

    > nimble install docopt
    > echo "import docopt" > test.nim
    > nim c test.nim

Nim's package management isn't exactly rocket surgery. Even if you use nimble as a build tool it's still extremely straight forward:

   > nimble init
   > echo 'require "docopt"' >> projectname.nimble
   > echo "import docopt" > src/projectname.nim
   > nimble build

Notice the lack of explicitly installing docopt, nimble build takes care of unmet dependencies.

That's it! Now you know everything there is to know about Nim package management. (Not quite, but close enough)

Nim is older than Kotlin, so your question is kinda backwards. But also:

1. no JVM (Kotlin Native isn’t considered a stable thing, or is it?),

2. subjectively nicer language,

3. An optional non-GC runtime upcoming (already in there as beta), which is interesting for low-memory applications... which in the time of the Cloud is potentially any application. The more (AWS) lambda time you can get for free, the better, right?

4. Writing command line tools. Practically nobody is writing them on Kotlin. Everybody’s writing them on Rust, though, for some reason...

Disclaimer, full disclosure: I’ve only read about Kotlin, of course, not written a single line. It seems like an excellent language, and if I had to do JVM work, I’d have it as a top3 candidate for sure.

subjectively nicer language This is the real conversation I want to have. Everybody talk about indirections (jvm, build system, devtools) but the real interesting talk as PL enthusiasts is about the language features, semantics and syntax.

No JVM.

Java also compiles to native code, commercial compilers exist since around 2000, and now even the free beer versions have them.

Additionally, Nim also has its own runtime, https://nim-lang.org/araq/ownedrefs.html.

Which most likely doesn't have 25 years of optimization algorithms, and monitoring tools, invested into it.

So "No JVM" isn't necessary an advantage.

If you start on the wrong path, optimizations can only go so far. That's why Android still sucks after all those years of investments. That's why IntelliJ is stills slow as a dog, even on the most beefy modern machine. I wish Jetbrains would have written their IDE in something else.

Even code written in C or Assembly can be dog slow, it is a problem between chair and monitor, not necessary from what tooling is capable of.

IntelliJ would be still dog slow even if written in C.

Non stopping indexing files on every startup isn't something that changes with the programming language, or the slowness doing code completion on C and C++ code, despite usage from clangd.

Look up Kotlin Native. It doesn't use a JVM (and compiles to native via LLVM).

There's also Kotlin JS, which targets the JS ecosystem, and comes with tools that let you import TypeScript type definitions into Kotlin, so you can easily interact with third-party JS modules.

A pure Kotlin library could easily be used on JS, JVM, and native/LLVM seamlessly. Which is pretty impressive. All your non-platform-dependent logic could be placed in a decoupled shared pure Kotlin library. Which avoid code duplication that is so common when you need web + iOS + Android client apps. (And the Intel Multi-OS Engine could be used to write your iOS app in Kotlin.)

I have nothing against Kotlin, it is a fine language, a pleasure to work with. Nim, however, has different priorities (utmost simplicity, native compilation, near-C performance, opt-out automatic memory management, excellent FFI capabilities, best in class macros).

The tooling is still JVM based and feels very heavy compared to Nim. (And the Kotlin/Native compiler is still very slow, although they're working on it.)

I'm not sure why so many people describe JVM based software as "heavy"? Is it possible to describe what "heavy" here means in more scientific terms?

Does it mean that startup is slow (possibly due to AOT)?

Does it mean that consumes a lot more memory than the equivalent C/C++/JS/Python/etc program? (I don't think so.)

Does it mean that code execution is too slow? (This hasn't been true for over a decade or close to two; the JVM's JIT is one of best ever.)

Does it mean the GC pauses are too painfully apparent? (I don't think this is true at all.)

Does it mean that users of JVM languages have a tendency to write code that is in inefficient/slow/bloated on average? (Again, I'd say this isn't true; and I've seen code to tend heavily more on the inefficient more so with dynamically typed languages in general.)

So, what really does "heavy" mean here?

(Lastly, while the core compiler tooling for Kotlin is probably reliant on the JVM, you don't have to use a JVM-based IDE for sure - VS Code (which is written in TypeScript/JS) should work fine as well.)

In an unrelated thread, someone posted this quote from the Mithril documentation on the differences from React, which sums it up pretty well: https://news.ycombinator.com/item?id=22777320

Java and React are fast by bringing a lot of sophisticated (heavy!) machinery. Nim and Mithril are fast by being small and simple.

For example, the JIT makes Java fast – eventually. But initially it's interpreted and slow, with the additional overhead of bringing up the JIT compilation machinery in the background. AOT compiled code reaches its normal speed from the start. So Java programs take a while to get fast, which makes them feel heavy.

Startup is slow. Java 11 is slower than Java 8 which is slower than Java 6. Class-data sharing can make it faster – sometimes. You still have to load all that data, so when it's not cached in RAM and you have a slow disk it's still slow. A smaller program is always fast to load. This makes Java feel heavy.

When it comes to memory, Java does clever optimizations like escape analysis at runtime so that the programmer doesn't have to bother with deciding between allocating on the heap or the stack. This can also make it fast in certain scenarios, after warm-up, but a language with explicit value types can be made fast from the start. (Which is why Project Valhalla is coming.)

The solution to that is to cache/save a pre-compiled binary on disk/persistent storage. This is what modern Android does.

You would just essentially need an installation step, where you compile the binary (maximally optimized for the architecture that it's running on), and save that to disk. All of the problems you described disappear with that -- no startup/AOT delay nor any JIT compilation delays.

Pre-compiling stuff is a small price to pay for the benefit of better-optimized higher-performance execution.

Another thing: you could do memory safety and other static analyses and security checks during the pre-compile/install phase. There's a lot of benefits to that.

For e.g. if you are able to statically verify and guarantee (ie mathematically provably) that the code will not commit any memory violations, then you could optimize away many of the bounds and other related checks. These sorts of verification must be done on the machine that is actually executing the code, since you can't simply trust a third-party, and must yourself verify such assurances/claims.

Sure, an AOT compiler for Java would solve some of these issues, at the cost of larger binaries and loss of the dynamic runtime optimizations that make Java fast for long-running programs (which is why Android uses a combination of AOT and JIT). Some people on this site often point out that expensive commercial AOT Java compilers have been around for a long time. JetBrains even used to provide an AOT-compiled binary of the Kotlin compiler for a while.

However, you were asking why people consider Java to be heavy. When people normally use or talk about Java, Java means a JRE derived from Sun's Java implementation. If you download Java to run the Kotlin compiler or IntelliJ, you're not downloading the Android runtime or some hypothetical AOT compiler - you're using something based on OpenJDK, which suffers from the heaviness I described.

Startup is always slow (I am really sensitive to latency, and I prefer to have some immediate response from software). You either need to tell people to install JRE beforehand (which nobody will do), or pack it with your distribution, adding 100 MB or so even for simpler programs. JVM-based software is fine on the server side, but I'd prefer something else on the client side.

Instant startup time

Kotlin support AOT so moot point

Not really. Kotlin/native is still super experimental and graal isn't exactly that easy either.

And somehow Nim has more support? This is a double standard non-sens. Btw you can address the startup time (which is reasonable btw, and x2 faster since kotlin 1.4-m1) without aot with tools like http://martiansoftware.com/nailgun/

I'm just saying that currently it's not trivial to compile a kotlin/jvm project to native. Once you start using dependencies things start to get really hairy. It's not as easy as `go build`.

I myself am hoping that either kotlin or Scala can finish their native compilers or Graal can make compiling jvm bytecode trivial.