Live data from Hacker News

Nim 1.6

nim-lang.org

171–179 of 179 posts

Re: Nim 1.6

#171
post #169

Earlier quoted context omitted.

So what? You are not comparing the same thing.

Of course not. But what else would you want to compare?

Lines of code per second for compiling the compiler. Or a standardized set of programs like language benchmark game. Not to say that they are not susceptible to problems, but they have much more information than the compiler compilation speed.

Re: Nim 1.6

#172

Maybe a year and a half ago I put myself towards learning Nim. My learning project was a basic REST API backend written using the standard library. I found the lack of IDE support very painful. On top of that, I ran into places where the documentation was out of date or just incorrect. After a few weeks of painful, slow going, I turned my attention to GO instead and haven't looked back.

i think that is over 2-3 years ago , Since nim 1.x documentation is fine , and vscode plugins are out. It your time to look back now , a lot more stable and complete.

Re: Nim 1.6

#173
To all those wondering about IDE support , the actively maintained VSCode extension is :

https://github.com/saem/vscode-nim

The default extension suggested by VSCode which have over 43k downloads in un-maintained for Eons and it won't work.

Here is the link : https://marketplace.visualstudio.com/items?itemName=nimsaem....

This extension works properly , go-to definations too.

Nim need contributors on VSCode and other extensions part , and the language server which is in active development :

https://github.com/PMunch/nimlsp

@dom96 can you pin this somewhere on the forum or website ?

Re: Nim 1.6

#174
post #58

What's the state on: - web frameworks / servers ? (ie. is there something like Sanic that is actively maintained ?) I imagine it's too early for a consensus. - database drivers ? (postgresql is important here. I can live without an ORM)

Why use an ORM when you can just not turn everything into objects?

Re: Nim 1.6

#175
For anyone put off by nim's copious use of camelCase and PascalCase, I recently learned that nim treats identifiers as the same if after removing all underscores the identifiers compare equal case-insensitively (except for the first character which is case sensitive). This means you can completely ignore NEP 1 (just like you can ignore PEP 8) and write your code with snake_case identifiers and Upper_snake_case types including any calls to external code.

This means that for people like me who find camelCase horribly ugly and refuse to casually use any language which uses it in its standard libraries or syntax (I'm looking at you haskell and zig) you can write code in a more aesthetically pleasing way while everyone else around you can continue using the horrific camelCase names (even when referring to your snake_case code).

Also, I highly recommend switching to at least 3 space indents so that unlike regex your code stops being write-only.

Re: Nim 1.6

#176
post #135

Earlier quoted context omitted.

I use it to parse crappy (non-standard) RSS feeds offline for an internal app I use. chrome-scraping would just be more of a pain (although I've done it before).

Have you tried htmlparser? Its fairly tolerant of "wild" html. It could use some tweaks to match the html5 spec that defines a lot more tags that don't require end tags. Also the library isnt to bad to grok and tweak yourself. There's also Nimquery that looks nice, though I haven't used it yet. Still looks to replace a lot of beautifulsoup.

No, but I use feedparser in the same script.

Basically I'm scraping SEC data, but the script has been around for awhile untouched, so there are probably better solutions today.

Re: Nim 1.6

#177

Earlier quoted context omitted.

why use tiobe when it is so clearly a bad metric? Pypl or the ieee index are much more reliable.

Not sure why you say these are much better when all these surveys pretty much give you the same result, if you look at these rankings in terms of brackets. Basically, they pretty much all agree which languages are the top 3, top 5, top 10, etc...

Tiobe ranks based on search results rather than visits, so languages can be ranked highly due to old computer generated docs that no one has ever read. Furthermore, tiobe only searches "x programming" which biases towards some languages and against others (Go and Julia come to mind as ones that are refereed to as Golang and Julialang frequently). Also, although the general results TIOBE gives look roughly accurate there are some entries that are wrong enough that you should question the validity of the ranking as a whole. For example, TIOBE ranks "Classic Visual Basic" as the 11th most popular language and claims that it has climbed 8 ranks in 2020. Given that the language hasn't been supported since 2008, and I have never heard of anyone using it for anything, that is rather surprising. Similarly, Tiobe appears to believe that Visual Basic is more popular than Javascipt which is frankly not credible (for refferrence, PYPL and IEEE place it at a much more believable 18th and 22nd).

Re: Nim 1.6

#178

Earlier quoted context omitted.

You're both just making the case that you shouldn't use vim to write code. More modern editors (e.g. VS Code) and modern IDE's (e.g. IDEA, CLion, Visual Studio) make either indenting absolutely trivial.

I think you may have misunderstood? My main editor is IDEA, followed by vscode and emacs. But all three are set to vim mode. Vim itself has actually never been my primary editor; I generally only use it when I'm sshed into servers. The thing that vim mode gets me is twofold: It (mostly) unifies the editing interface among all of those editors, and it allows me to edit code more quickly. The thing I was talking about…

I think that by installing vim on all your editors, you are missing out on a lot of productivity.

You are basically giving precedence to text edition over code edition. When you use an IDE, you are editing code, not text, and that IDE's key bindings are optimized for that purpose.

I suggest you take the time to learn native key bindings to whatever tool you picked and see where that gets you, you'll be surprised after a few weeks.

Re: Nim 1.6

#179
post #172

Maybe a year and a half ago I put myself towards learning Nim. My learning project was a basic REST API backend written using the standard library. I found the lack of IDE support very painful. On top of that, I ran into places where the documentation was out of date or just incorrect. After a few weeks of painful, slow going, I turned my attention to GO instead and haven't looked back.

i think that is over 2-3 years ago , Since nim 1.x documentation is fine , and vscode plugins are out. It your time to look back now , a lot more stable and complete.

Cool, I'll give it another shot.
Post reply on HN