6 ms·
Nim is great. It is fast and it works everywhere that C works or JavaScript works since it transpiles to either (and then compiles if transpiling to C). It is s
by 3pt14159 11y ago
Nim is great. It is fast and it works everywhere that C works or JavaScript works since it transpiles to either (and then compiles if transpiling to C). It is super fucking fast (usually faster than C) and it feels like it has none of the limitations that you normally find out there.
That being said, there are a couple of issues.
1. Like Crystal, Nim still doesn't have HTTPS for its webserver, and with both, the default instructions are insecure. (Download this thing and run it in your shell, pay no attention to any MITM that can trivially root your machine).
2. The community is really pro, but the arguments are too tiring. We had a huge argument over the equivalent of Ruby's chomp. Everyone is so afraid of bloat in the standard lib (which I don't really understand, since I've never found myself wanting less string methods).
3. While the syntax is way better than Rust, Go, et al. It borrows some annoyingness from Python where it could have looked to Ruby for better guidance. For example, sort vs sorted. Sorted is the safer operation in Python. It returns a new sorted list. Now what normally happens in the real world is that programmers make the safe version first and later make the fast version. But imagine that the first version was called "sort" and it returned a new array, how are you to transition to a fast sort and a safe sorted? Error prone patching. Ruby's array.sort vs array.sort! is much better during transition, more legible, just all around better. It means less mangling around and it means that 99.9% of the time you know the method you're calling is safe if it doesn't have the bang after it.
4. There is still some instability here and there when you try to do cute things. I can't remember exactly what it was, but something along the lines of passing channels over channels segfaulted. This leaves you a little concerned about just how much abstraction you build up.
That being said, I fucking love Nim. It's so fun to write, it's super fast, it's quite legible, and you can do literally anything. It's had shared objects (dlls) since I started using it, so Ruby <-> Nim is possible and fun. It's very debugable and once it hits 1.0 and gets more mainstream use I'm sure it's going to be a really popular language.
- scardine 11y agoThe deal breaker for me is the variable name normalization: userName == user_name == username == uS_eR_aN_mE It used to be totally case insensitive now it is case sensitive for the first letter. Underscores are ignored: two identifiers are considered equal if the following algorithm returns true: proc sameIdentifier(a, b: string): bool = a[0] == b[0] and a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower For me it is a capital violation of the "principle of least astonishment".
- Mikeb85 11y agoBecause it's such a deal breaker that you can't have "userName" and "user_name" in the same scope. This was brought up in the other thread, and it's just as silly now. Rejecting an absurd naming scheme is a feature.
- dom96 11y agoFor those who would like to read the previous thread: https://news.ycombinator.com/item?id=10931800 https://news.ycombinator.com/item?id=10931800
- 3pt14159 11y agoI actually love this. It makes it easy to write code in either a JS context (where you want camel case) or Ruby(ish) context. I really don't see how this is a deal breaker. It's one of the first things you learn when you start with Nim and I've never had a problem with it. To me this is kinda akin to the people that complain about the magic in Rails or that Ruby includes so many things by default (like rand or sleep) without working on a couple of projects first. Those really aren't the problems that slow you down in Ruby and this isn't really something that is an issue in practice.
- lqdc13 11y agoit's a huge problem because in many cases you have no idea that you are reusing a variable, because in every other language you wouldn't be reusing a variable. This plus the crazy global name space pollution. If you import something, everything is imported from that module. I have no idea what to name things because everything collides with everything else. In Python, things are simple. Classes are 'CapitalCase' and functions are 'lower_case'. If I did the same thing in nim, they would collide. Also, in Python it is considered a terrible idea to do from some_module import * in Nim, it is the way things are done. Although, they are alternative methods that don't do this. also, the weird var a, b = 0 Perhaps you get used to it with time. But still namespace collision is always a problem for me especially when working with others' libs. However, it is currently the most painless way to write fast code and integrate with Python, which says a lot. Edit: Looks like first letter matters now, so ignore that part of the comment.
- krupan 11y agoHow does the garbage collection work when transpiling to c?
- PeCaN 11y agoProbably just has a conservative Boehm-ish GC. Their website is a bit sparse on the GC details from what I can tell, but anything else would be rather surprising.
- tonyg 11y agoThe garbage collector looks to be written in Nim: https://github.com/nim-lang/Nim/blob/devel/lib/system/gc.nim https://github.com/nim-lang/Nim/blob/devel/lib/system/gc.nim
- nickpsecurity 11y agoA bit more interesting: "The basic algorithm is Deferred Reference Counting with cycle detection. # This is achieved by combining a Deutsch-Bobrow garbage collector # together with Christoper's partial mark-sweep garbage collector. # # Special care has been taken to avoid recursion as far as possible to avoid # stack overflows when traversing deep datastructures. It is well-suited # for soft real time applications (like games)."
- gokr 11y agoIn fact, there are five (!) different GCs you can try: --gc:refc|v2|markAndSweep|boehm|go|none