Earlier quoted context omitted.
So what? You are not comparing the same thing.
Of course not. But what else would you want to compare?
Nim 1.6
171–179 of 179 posts
Re: Nim 1.6
#172Maybe 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.
Re: Nim 1.6
#173https://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
#174What'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)
Re: Nim 1.6
#175This 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
#176Earlier 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.
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
#177Earlier 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...
Re: Nim 1.6
#178Earlier 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…
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
#179Maybe 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.