Hacker Newsnew | past | comments | ask | show | jobs | submit | more lactobacillis's commentslogin

People complain about lack of generics and proper try/except/finally in Go. Nim has both.


And no native concurrency.


Nim has thread support natively. And an async implementation in it's standard library which is made entirely as a library, so you're free to write your own, in fact there exists alternative implementations of async/await in Nim. Just the fact that a feature like this _can_ be implemented as a library is a testament to how powerful of a language Nim is.


It's not my area but, surely concurrency can be added, and why does it need to be native? Surely a library is fine.

(I chose not to learn go because of it's lack of generics and exceptions. It seemed like a huge step backwards)



Why do you say that?

It's far from perfect but it does work (and has for a few years), and it helps you by requiring proof that actions are disjoint. There is work now on including Z3 which would work this much smarter.

https://nim-lang.org/docs/manual_experimental.html#parallel-...


Then let's ask instead, why use Nim over Pascal?


Actually type safe, with support for various kinds of automatic memory management.

Pascal dialects, while much safer than C, suffer from use-after-free and possible memory leaks, also you don't need to mark unsafe code as such.

This includes any modern Pascal variant.


Why use nim over Kotlin with AOT?


I'm not familiar enough with Kotlin to give a real answer, but from what I do know the following might be relevant:

* Backends: Nim compiles to JS both directly, and indirectly (emscripten) with various trade-offs (e.g. 64 bit ints require emscripten). It also compiles to C, C++ and Objective C giving you the simplest most efficient FFI to those languages one can hope for (including e.g. exception handling) while at the same time addressing the largest set of platforms (got a C compiler? you can use Nim). And you also have (almost but not yet quite production quality) native code compiler NLVM. What's the platform range of Kotlin's AOT?

* Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], I think, and only because Lisp has reader-macros (whereas you can't ignore Nim's syntax with macros, as flexible as it is). For example, Nim's async support (comparable to Python and C#) is a user-level library. So is, for example, pattern matching. Can Kotlin do that?

* Size: Nim compilation through C produces standalone and (relatively) tiny executables; it matters for embedded platforms. How does Kotlin fair in this respect?

[0] Lisp, scheme and other Lisp derived languages, of course.


>> Metaprogramming: Nim's metaprogramming ability is second only to Lisp[0], ...

There are some other languages that have metaprogramming abilities equal to Lisp. For eg. Rebol, Red & Forth.

I think some people would also consider Prolog and Smalltalk to be in the same ballpark.

And there are languages that would also claim to be second only to Lisp, for eg. Julia, Elixir, Raku/Perl6 and probably some others to!


Nim compiles to JS both directly, and indirectly (emscripten) with various trade-offs (e.g. 64 bit ints require emscripten) Kotlin can also compile to js directly and can autogenerate typescript definitions for the generated code.

It also compiles to C, C++ and Objective C giving you the simplest most efficient FFI to those languages one can hope for (including e.g. exception handling) while at the same time addressing the largest set of platforms (got a C compiler? you can use Nim). Wow, nim has implemented that much transpilers? This is kinda impressive but I would rather want a language that compile to Binary instead of compiling to another language, AND that offer nice FFI interop Kotlin has state of the art language interop through graalvm but here it does not qualify as native. For native interop it can be done but is subpar. But openjdk is working on a new API luckily.

Metaprogramming Interesting topic for sure! I've never learnt a LISP. I did use macros when I was doing C/C++ and honestly I don't get their advantages vs @Decorators() (pre compile time codegen) and they have a reputation of breaking IDEs Kotlin like Java can generate code/classes at runtime and has full support for reflection. Tangeant: Kotlin can mark any function as in/postfix which allows to easily create DSLs. Due to this Kotlin community has created a lot of elegant, declarative DSLs such as for testing.

Nim's async support (comparable to Python and C#) is a user-level library. Kotlinx.coroutines is the official library the language simply has to expose the keyword suspend.

So is, for example, pattern matching. Can Kotlin do that? Kotlin has some pattern matching features in its when keyword,but no it cannot currently destructure in when. But the subject is active and it should come in a following release, especially since Java is getting pattern matching. https://github.com/Kotlin/KEEP/pull/213

But if your point was that macros allows to modify the abstract syntax tree, Kotlin compiler plugin API offer much more power (you can modify anything anytime (the AST, the IR, the bytecode) It is arguably far harder to use than powerful macro but it does not prevent experimented guys from scalaifying Kotlin through https://github.com/arrow-kt/arrow-meta/issues They are bringing for example union types as an unofficial extension to the language. They could bring pattern matching earlier in theory.

Size: Nim compilation through C produces standalone and (relatively) tiny executables; it matters for embedded platforms. How does Kotlin fair in this respect?* I'm afraid kotlin is not made for such a use case but today even embedded platforms should have a few dozens of free MBs


Kotlins stdlib is seriously lacking, at least the last time I looked at it, you couldn't even read a file without java.io.


You can and you should use Java libs where appropriate. It's always nice to have pure idiomatic Kotlin but calling Java from Kotlin is already idiomatic.

As for multi platform io they are working on it https://github.com/Kotlin/kotlinx-io


But the discussion was about Kotlin AOT. Not kotlin JVM.


Right but using graal native instead of kotlin native you can have kotlin calling Java code and compiling to a binary


I'm hopeful that Kotlin/Native will improve in these areas (excepting the last one) but:

* Faster compilation.

* Tooling is less memory-hungry.

* C++ interop.

* Macros.


Tooling as in intellij/gradle? I doubt they'll ever use less memory.


Actually intellij since 2020.1 release is kinda fast :0


Why macros vs decorators?


I think you basically covered it in your other comment. Macros are much quicker and easier to write than compiler plugins or annotation processors, but they are difficult for the IDE to understand. So it's a trade-off where Nim and Kotlin both make reasonable, but quite different, choices.


Not if he outsourced the reading of said book to a foreign company. He would would have to check if their reading was the same as his every hour for 18 months that would have taken him 3 days to read it himself. Slowly.


Identify companies you want/can potentially work for. Find out their skill requirements. Contact them directly - it is worth a shot.

Generally though, and in my neck of the woods - Java is very widely used. So is .Net (mostly C#), Python and JavaScript.

If I had to start again like you, I would go hard on Python first. It is relatively easier, and there is also the great potential to build your own apps with it. Potential employers are easily impressed with personal projects.


That begs the question of course: What are normal healthy eating habits?

Our eating habits have been formed by mass marketing for many decades so I would not call them normal. Even the fresh fruit and vegetables I see in the supermarkets (Coles and Woolworths in Australia) do not look normal.


Greens - spinach, kale, swiss chard, beet greens, parsley, watercress, mustard, turnip, cress, dandelion

Seeds - sunflower, pumpkin, *

Seafood - Salmon, sardines, mussels

Reds - Tomato, red peppers

Insects - Crickets

Everyone can debate the merits of livestock, cereals, roots, legumes, extracted seed oils, saturated fat, cholesterol, refined sugar, top feeding fish, alliums, brassicaceae. But the other things listed above are about as universally and unequivocally considered healthy with the understanding of food we have, with regard to commonly available foods in a western diet.

* almond, peanut, walnut, pistachio, pecan, cashew, macadamia too if fodmap issues arent a concern. Same with alliums, brassicaceae, legumes.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: