Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.6.2

nim-lang.org

Post reply on HN
Print view View original

101–110 of 162 posts

Re: Nim 1.6.2

#101

Post by galangalalgol »

juki wrote: post #94
galangalalgol wrote: post #76

Earlier quoted context omitted.

If you already know python and JS I think you probably won't have too much trouble with Nim, but why not add something new like memory management to learn about? Rust is complicated, but it has training wheels, and its wasm support would integrate with your JS knowledge. Alternatively modern C is still used everywhere and will teach you a lot about hardware.

> but why not add something new like memory management to learn about? You can learn that with Nim too. It supports manual memory management like C. The new ARC/ORC GC also works more like modern C++ than a traditional GC. > its wasm support would integrate with your JS knowledge Nim can also compile to JS. Or you could compile it first to C and then compile that to wasm, although that's not supported out of the box.

Those are good points. I have found that languages that don't force me to use a feature don't teach aa well as ones that do. I usually don't want to use those languages later though ( java and oop or Haskell and functional) because I like having options. Nim gives you lots of options it sounds like.

Re: Nim 1.6.2

#102

Post by ajusa »

warent wrote: post #79

I've vaguely heard of Nim in the past and for some reason always thought it was some limited scripting language. But this looks like a pretty serious candidate for a nice backend language. I'm getting tired of how cumbersome Go is and have had my eye on Crystal. Anyone have any insight on how Nim stacks up to Crystal?

In case you want a quick example of a backend application in Nim, I've written a small post[1] describing how to create a room based chat using it and HTMX. In total, it's around 70 lines of code (though it doesn't cover more advanced use cases, like username collision). I too have moved from Go to Nim, the syntax and ease in which I can turn a feature into code has been much better.

[1]: https://arhamjain.com/2021/11/22/nim-simple-chat.html

Re: Nim 1.6.2

#103

Post by budafish »

cobby wrote: post #58
formerly_proven wrote: post #15

Earlier quoted context omitted.

I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

I personally still use Python because I miss list and dict comprehensions. I know there is a `collect` macro in `sugar` module but it is nowhere close to the python comprehensions. The code is too verbose and basically is just the same multiline for loop :-(

(on mobile) You could use Nimssequence iterators

[x.name for x in someList if x.age > 5]

Is the same as:

x.filterIt(it.age > 5).mapIt(it.name)

In a way it reads better.

Re: Nim 1.6.2

#104

Post by iffycan »

klibertp wrote: post #96
posharma wrote: post #3

Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?

> Genuinely curious - why should I care about Nim? You definitely shouldn't. If you need a reason to care , then Nim is simply not for you. You won't benefit from Nim, and Nim won't benefit from you. It's best to agree to disagree and walk away from each other (assuming Nim can walk). EDIT: I got downvoted a bit here, probably because the above seemed rude and/or dismissive? If so, sorry, that wasn't my intention. Wh…

Nim can walk: https://nim-lang.org/docs/os.html#walkDir.i%2Cstring

Re: Nim 1.6.2

#105

Post by klibertp »

adamrt wrote: post #93
klibertp wrote: post #90

Earlier quoted context omitted.

Implicit imports on the global namespaces? What do you mean? Case insensitivity is somewhat complex topic in Nim, as there are some places where the case actually matters, plus there are some more rules for equivalence of identifiers (related to `_` IIRC). In any case, it was never a problem for me in practice; nimsuggest works quite well.

> Implicit imports on the global namespaces? What do you mean? Not OP, but they are referring to `import std/strformat` (from homepage). That just imported things into the global namespace. Maybe that isn't required and its just for short examples, I don't know. Go and Python can both import into the global namespace too (`from thing import *` and `import . somepackage`), but they are pretty frowned upon in most proj…

> Not OP, but they are referring to `import std/strformat` (from homepage).

> That just imported things into the global namespace.

That's what tripped me up: there's definitely no such thing as importing into GLOBAL namespace. That's an import into a top-level (true) namespace of a MODULE. In Python, if you put something into the dict returned from `globals()`, you are indeed importing into global namespace, but I've never seen it actually done. Anyway, that might seem like nitpicking, but it's an important distinction. [EDIT: C `#include`s are an example of actually importing into global namespace]

With that out of the way: the wildcard imports are frowned upon for a reason. What reason? Basically, it's hard to tell a) what identifiers were imported, b) if any of them are still used in the module (ie. if it's safe to remove the import). With multiple wildcard imports in one file you also get c) hard to tell where a given identifier comes from.

Now, none of these problems apply to Nim. Nim is statically typed. The compiler and the tooling knows exactly which identifier comes from where. If you delete all the places you used identifiers from a wildcard import, the compiler and the tooling will tell you that it's safe to delete the import. Another problem with wildcard imports is that the imported modules can change, leading to disasters like silently shadowing an identifier imported from somewhere else. Again, this cannot happen in Nim - it simply won't compile.

Every single linguistic feature has its pros and cons, but you have to remember to only weigh those in the particular context they're used in. What I mean is that wildcard imports in Python and Nim are very, very different beasts, and shouldn't be directly compared, if at all. It would make more sense to compare Nim to Elixir or Scala in this regard.

Note: obviously, Nim also has selective imports and whole module imports, too.

Re: Nim 1.6.2

#106

Post by adamrt »

klibertp wrote: post #105
adamrt wrote: post #93

Earlier quoted context omitted.

> Implicit imports on the global namespaces? What do you mean? Not OP, but they are referring to `import std/strformat` (from homepage). That just imported things into the global namespace. Maybe that isn't required and its just for short examples, I don't know. Go and Python can both import into the global namespace too (`from thing import *` and `import . somepackage`), but they are pretty frowned upon in most proj…

> Not OP, but they are referring to `import std/strformat` (from homepage). > That just imported things into the global namespace. That's what tripped me up: there's definitely no such thing as importing into GLOBAL namespace. That's an import into a top-level (true) namespace of a MODULE. In Python, if you put something into the dict returned from `globals()`, you are indeed importing into global namespace, but I've…

Cool thanks for the info.

Nim having selective imports solves any annoyances I would have.

But you mentioned all the reasons it was ok in Nim. But the answer is always that the compiler knows. That isn’t why I personally dislike this type of import. I dislike it as a user. I find it super annoying not knowing where an identifier is coming from.

I love having ‘fmt.Printf()’ instead of ‘Printf()’. Trivial example I know. I’m sure everything becomes fine once you are familiar with the ecosystem though.

Re: Nim 1.6.2

#107

Post by goodpoint »

lifthrasiir wrote: post #41
goodpoint wrote: post #32

Earlier quoted context omitted.

This complain comes from people who haven't used the language. > Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing. On the contrary, the language prevents confusion due to mixing getAttr and get_attr in the same codebase and bugs from using the wrong one. Unsurprisingly, many safety-critical environment…

There are two kinds of case-insensitivity in identifiers. In either cases identifier cases (and in this case, also underscores) are normalized, but case-agnostic languages would allow any mix of them while case-pedantic languages would disallow any pair of identifiers normalizing into the same name (they may still give helpful errors based on that normalized name though). I don't think case-agnostic languages provide…

Nim provides the benefit of both: when interfacing with C libraries a case-agnostic language helps.

Yet, checks on function definition and types has the same benefit of case-pedantic language, without forcing a specific style on the developer.

Re: Nim 1.6.2

#108

Post by WesolyKubeczek »

k__ wrote: post #65
girvo wrote: post #10

Earlier quoted context omitted.

Why’s that?

Just the general disdain for crypto here at HN.

I still see more crypto/blockchain adoration here than disdain, although the tables might be turning slowly now.

HN users are much like magpies: once an idea shoots up, you can't swing a cat without hitting a zealot. If you are ambivalent or skeptic, you'll be furiously explained into the corner. Then, when the fad fizzes out and its inevitable drawbacks are publicized by more and more sources, the "told you so" camp starts merrily chasing the dwindling numbers of zealots around, while some former zealots get depressed from their high hopes being squandered and the resulting dopamine deficiency.

A new shiny comes in (say, "rewrite everything in Rust"), the cycle repeats.

Re: Nim 1.6.2

#109

Post by rsyring »

nerdponx wrote: post #88
BiteCode_dev wrote: post #81

Earlier quoted context omitted.

I like Nim, and probably will learn it at some point. But no, Nim is not everything "python should/want to be". The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.

IMO people really should stop comparing it to Python, it's a very different language.

I don't mind the comparison but do wish the comparison wouldn't so often be "it's a better Python."

I've been programming Python 14+ years and I've dabbled in Nim and I agree it's a very different language. Yes, there are similarities, but my expectations about it being a lot like Python from the community and docs actually led to some significant frustration and discouragement.

"Inspired by"..."borrows concepts from" are better descriptors IMO. But it would be better if an unqualified "it's like Python" disappeared.

Re: Nim 1.6.2

#110

Post by rakoo »

nerdponx wrote: post #95
rakoo wrote: post #18

Earlier quoted context omitted.

My personal blocker is that identifiers are all imported globally by convention, so when you see that there is a call to a method called "get", you have to get to the top of the file or mouse over the call to see what lib it is from. A "get" from the http lib is not the same as a "get" from the kv store lib.

Don't Haskell and Go also do this?

I have no experience in Haskell, but in Go:

- if it's a builtin or in the current package, you usie it directly

- if it's in another package the identifier is always prefixed with the package

Post reply on HN