I really with more people used NIM for web development. It really seems like the best of all worlds (e.g. perf, developer ergonomics, productivity, etc).
But the more the merrier, so I look forward to its bright future.
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.
Also: available to hire if anyone is looking to work with Nim.
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.
You could certainly write an expressive web framework in nim, but a django/rails sort of paradigm is not the way.
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.)
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.)
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.)
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.
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.
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.
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.
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.
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.
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.
> nimble install docopt
> echo "import docopt" > test.nim
> nim c test.nim
> nimble init
> echo 'require "docopt"' >> projectname.nimble
> echo "import docopt" > src/projectname.nim
> nimble build
That's it! Now you know everything there is to know about Nim package management. (Not quite, but close enough)
I myself am hoping that either kotlin or Scala can finish their native compilers or Graal can make compiling jvm bytecode trivial.
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.