Oooo, wow collect looks so much cleaner. I can't wait to get home and play with it!
> I can't wait to get home and play with it A. Where are you that you are not already at home?? And B. I wonder how many people are using nim at work, and what sort of workplaces that might be?
Nim 1.2
81–90 of 130 posts
Re: Nim 1.2
#82By far my favourite feature of this release, dark mode in docs: https://nim-lang.org/docs/lib.html
I feel like dark mode is a sign that people care. I think it's a user feature that is easy to do, but not done often. Mostly done by people who care. It brings so much polish to the experience.
It's not necessarily _that_ easy to do, especially depending on how your CSS was implemented (eg; do you use variables for all your colors, and do they have a sane, consistent, reversible brightness scale?)
However, I certainly agree with your "you do this because you _care_" sentiment.
Source: implemented dark mode for an application where the "sane css colors using variables" property was true.
Re: Nim 1.2
#83Re: Nim 1.2
#84Does Nim have an ORM or querybuilder as good as SQLAlchemy yet?
Re: Nim 1.2
#85Earlier quoted context omitted.
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.
Re: Nim 1.2
#86Earlier quoted context omitted.
No JVM.
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 log…
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).
Re: Nim 1.2
#87Earlier quoted context omitted.
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.
Re: Nim 1.2
#88hope they nim developers, port a lot of python data science tools e.g pandas, numpy etc so they can increase adoption in the language. Julia is supposed to fill that space, but feel strongly nim is better positioned
Re: Nim 1.2
#89Earlier quoted context omitted.
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.
Re: Nim 1.2
#90Earlier quoted context omitted.
No JVM.
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 log…
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.)