101–110 of 130 posts
Earlier quoted context omitted.
What advantage does it bring that Kotlin hasn't?
No JVM.
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.
hope 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
Earlier quoted context omitted.
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.)
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.)
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 t…
I am currently working on a tiny game in nim using Raylib. I had some initial friction with Nim, but i like using the language now. You'll do well to stop trying to use Nim as an oops language and just use it as a better C. The language syntax is clean, and the std lib has all that I need. One bit which I still hate is simply how imports work in Nim. My project pretty much has a header like file containing function a…
You mean how `import` works or are you using `include`? If the latter then I would strongly discourage you from using it.
As for the former, you can use `from module import nil` everywhere if you really want.
Java and Python are being pushed by Silicon Valley and universities, Go is being pushed by Google, Kotlin is being pushed by Google, C# is backed by Microsoft and some big companies.
Who can help Nim, or Crystal, or Rust or other new language?
I look at many of them from time to time, see interesting developments, see exciting things but I refuse to learn the languages, their ecosystem and frameworks from the fear I have I will lose lots of valuable time since I might not be able to earn my living using them.
Earlier quoted context omitted.
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 t…
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.)
hope 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
Out of curiosity, what do you feel makes Nim better positioned in this space?