I use
[https://github.com/FedericoCeratto/nim_project_maker](https://github.com/FedericoCeratto/nim_project_maker)
to initialize projects with some useful files
I wish the effect system could be used to implement sandboxing.
The stdlib procs that run system calls could be tagged accordingly, and the
application's "main" could then set up a sandbox at runtime to allow only the
required system calls.
I usually place HTML templates in "templates/.tmpl"
See
[https://nim-lang.org/docs/filters.html#available-filters-stdtmpl-filter](https://nim-lang.org/docs/filters.html#available-filters-stdtmpl-filter)
If popularity or quick growth becomes the main priority, aspects like
innovative features and good design become secondary.
Differently from many other languages, Nim is quite uncompromising and is
aiming very high.
> 4\. Epic Marketing: Nim is doing nothing here.
Hype-driven popularity
Parallelism/concurrency and async are some of the few pain points of the
language. ARC/ORC together with
[https://github.com/mratsim/weave](https://github.com/mratsim/weave) might be
very promising.
nimetic: when you Nim code is also valid Python and fools language detectors.
I think "optimization wall" is not always understood without a bit of context.
More importantly, languages can have a very steep climb, instead of a wall,
that makes optimization possible but not worth the effort.
IMO Nim allows for progressive, smoother optimization.
[Ahem, if we exclude the
Fixed, thank you!
> malicious actor can always check if it's being run under some tool like this
Yes, or simply leave a vulnerability around that can be later exploited.
If you want to add auth to existing frameworks:
[https://github.com/FedericoCeratto/nim-httpauth](https://github.com/FedericoCeratto/nim-httpauth)
A benefit of shared/dynamic libraries is that they can receive security updates
from the OS without having to rebuild and deploy all impacted applications.
It's crucial in many scenarios.
How about having some regular conference calls during this days, while many
people are staying at home due to the lockdown?
There's a bug report - now fixed - at
[https://github.com/FedericoCeratto/nim-package-directory/issues/27](https://github.com/FedericoCeratto/nim-package-directory/issues/27)
Thanks!
Midnight commander [1] is actively developed and quite popular. Do you plan to
reach feature parity or have new features?
[1]
[https://en.wikipedia.org/wiki/Midnight_Commander](https://en.wikipedia.org/wiki/Midnight_Commander)
Raspbian already provides the official Nim 1.0.6 package from Debian:
[https://archive.raspbian.org/raspbian/pool/main/n/nim](https://archive.raspbian.org/raspbian/pool/main/n/nim)/
Shameless plug: This can help updating the naming style:
[https://github.com/FedericoCeratto/nimfmt](https://github.com/FedericoCeratto/nimfmt)
Details at
[https://nim-lang.org/blog/2020/01/24/version-106-released.html](https://nim-lang.org/blog/2020/01/24/version-106-released.html)
I think we are conflating two types of exceptions: recoverable ones, that can
be safely catched and enable granular error management, and fatal ones that Nim
cannot handle, where the only safe option is a restart.
I would argue that the second type should be exceedingly rare by default, due
to
We have a dedicated proc for this in the net module:
[https://nim-lang.org/docs/net.html#getPrimaryIPAddr](https://nim-lang.org/docs/net.html#getPrimaryIPAddr)
"no version" -> you need to create tags on GitHub in order for Nimble to treat
it as a version
"install test failing": As you can see from
[https://nimble.directory/ci/badges/diff/nimdevel/output.html](https://nimble.directory/ci/badges/diff/nimdevel/output.html)
Nimble thinks the repository
The current tags are far from descriptive, while categories organize packages
only along one arbitrary dimension.
A much better taxonomy in used in Debian by Debtags:
How are you guys fetching Nim packages? I could host them on
[https://nimble.directory](https://nimble.directory) if needed. Let me know if
it would help.
Expressiveness and readability are much more important than byte or line count.
Unfortunately it can only be sensed by reading and writing a sizeable amount of
code.
Unfortunately packages.json is not categorized and the tags are not based on
structured classifiers, see
[https://github.com/nim-lang/packages/pull/339](https://github.com/nim-lang/packages/pull/339)
I'd be happy to add browsing pages if we had categories or if the
Curated-Packages had a
We could assume: popularity = corporate_hype + 0.3 * quality + random()
...and despite the correlation, things that both very good and very popular are
really rare compared to very-good _OR_ very-popular
Blog post:
[https://nim-lang.org/blog/2019/11/26/version-104-released.html](https://nim-lang.org/blog/2019/11/26/version-104-released.html)
(The Debian package is currently uploading and the Ubuntu one will follow)
Nim favors static linking by default. If bignum has no runtime dependency on
any shared objects (DLL) the binary contains everything you need to run.
Static linking comes with some disadvantages, for example that end users need
to update the whole application every time a critical issue is
Enjoy - [https://nim-lang.org/install.html](https://nim-lang.org/install.html)
It's also available in Debian Unstable.
I support a smoother deprecation process, like the one Araq suggested, because
the abrupt change in #12321 creates conditions where csize has different
meaning in Nim 1.0.0 and the next release, making it difficult to maintain
backward compatibility in libraries. Also, the deprecation process
What traffic capturing speed do you want to achieve? DPDK is a monster, perhaps
A lot of people find Nim's expressiveness comparable to Python. I find static
types in Nim increase productivity even over Python although the ecosystem and
tooling are not that rich.
@Lachu: the official Nim packages in Debian are using reproducible builds
successfully.
@cheatfate: sounds like you are describing staticRead and staticExec as a way
to obfuscate malicious code. There are many other ways to obfuscate Nim code
e.g. with complex macros. I wonder if sandboxing a
> The definition of open source at opensource.org seems to be quite
> restrictive; by common sense, sources are open, if just are freely
> accessible, in the original, non-obfuscated form.
In this case common sense is not correct. Making sources available online does
not provide legal rights
There's also a lightweight StatsD-only library: statsd_client
[https://github.com/FedericoCeratto/nim-statsd-client](https://github.com/FedericoCeratto/nim-statsd-client)
The Debian (and therefore Ubuntu) package recommends gcc and build-essentials
and uses only 31MB. There is also a nim-doc package that contains
documentation. You can use it to build a Docker image with everything you need.
FYI: Nim is building and passing its tests on mipsel and mips64el:
[https://buildd.debian.org/status/package.php?p=nim](https://buildd.debian.org/status/package.php?p=nim)
Nimble could provide various quality suggestions when "nimble release" is
called, including:
* How to fix the package structure if needed
* Use structured tags from a list similar to
[https://pypi.org/pypi?%3Aaction=list_classifiers](https://pypi.org/pypi?%3Aaction=list_classifiers)
*
Fswatch supports Linux, most BSDs, OSX and Windows
[http://emcrisostomo.github.io/fswatch](http://emcrisostomo.github.io/fswatch)/
A wrapper for the shared library would be nice.
> new Nim compiler version produces different nimcache sources from the same
> .nim sources, so which ones are the "real" ones now?
This is a feature rather than a problem. The .nim files are the "real" sources
and the .c files are artifacts. If you commit the .c sources you can then
inspect
Nim is usually among the fastests languages around. Occasionally you run into a
shockingly slow proc without warnings in its documentation. Having a large set
of language/stdlib benchmarks could really help but so far there's been little
interest creating and maintaining such set.
Nimble could run better checks when releasing a package
[https://github.com/nim-lang/nimble/issues/632](https://github.com/nim-lang/nimble/issues/632)
The Nimble package directory can help with this, see:
[https://nimble.directory/about.html](https://nimble.directory/about.html) If
someone wants to contribute you can contact me on IRC
Neovim user here.
It's also quite common to use hyphens in project names, git repositories and
project home pages - including many projects in Nimble.
Being able to keep consistent naming across project name, filenames, executable
name and imports instead of a random mixture of "my-project" "my_project" and
I might release one. What is your use-case exactly?
A Devroom at FOSDEM would be really nice.
Nim 0.20.0 is now in Debian Unstable and will trickle down to Ubuntu and other
derivatives.
The package is entering Debian Experimental right now. I'll upload it to
Sid/Unstable after some testing and later Ubuntu and other derivatives.
A working example:
[https://github.com/FedericoCeratto/nim-dashing](https://github.com/FedericoCeratto/nim-dashing)
This page collects known configuration for buildservices:
[https://github.com/nim-lang/Nim/wiki/BuildServices](https://github.com/nim-lang/Nim/wiki/BuildServices)
> And Nim lacks the build tools, available for every Go programmer.
What tools?
There are different init system and tools to run an application as a daemon
without having to increase your application's complexity. Currently a lot of
distributions ship systemd by default as it provides features like automated
health check and restart and security sandboxing.
I wrote a
No, memfiles use the memory mapping mechanism provided by the OS (e.g. mmap).
[https://nim-lang.org/docs/memfiles.html](https://nim-lang.org/docs/memfiles.html)
@Gregbalfourd I added a multithreaded test to [1] and improved the library a
bit.
[1]
[https://github.com/FedericoCeratto/nim-lmdb](https://github.com/FedericoCeratto/nim-lmdb)
Please also keep in mind that counting downloads is not very meaningful for
languages using statically compiled libraries: often CI systems pull them on
every build.
I wrote
[https://github.com/FedericoCeratto/nim-testrunner](https://github.com/FedericoCeratto/nim-testrunner)
(testrunner in Nimble) for a similar use.
Run ./install.sh from the source directory after building
to extract the required files.
The "compiler" directory is currently included but it should not really
installed according to
We created a dedicated Telegram group at
[https://t.me/NimFOSDEM2019](https://t.me/NimFOSDEM2019) to avoid spamming the
general discussion group.
Nim is a good choice for this use-case because it's going to have very little
overhead. Anyhow you are mostly system-bound. Consider using SO_REUSEPORT and
spawning enough processes to use the two cores fully.
NESM comes in handy for data [de]serialization
[https://github.com/xomachine/NESM](https://github.com/xomachine/NESM)
> many of those who definitively rejected Nim for its case insensivity will
> have, anyway, rejected Nim for other reasons
Stating that the same group of people dislike style insensitivity, GC, etc is a
bold claim.
I do not want a vote. As GULPF wrote, Nim needs stability. Breaking
compatibility to fix language warts is beneficial as long as it happens
occasionally.
A lot of people express concern about style insensitivity fearing that it leads
to inconsistent naming withing the same project or even
Count me in!
Nim 0.19.0 is in Debian Unstable since yesterday evening. Derivative
distributions will fetch the package in the next days.
A little dashboard:
[https://repology.org/metapackage/nim/versions](https://repology.org/metapackage/nim/versions)
@MoKhaild123 I'll try to get the official package in Ubuntu updated. In the
meantime you can pull the package from Debian (it's the source used by Ubuntu):
[https://packages.debian.org/sid/nim](https://packages.debian.org/sid/nim)
> Packages in any registry, however "real", can disappear because of security
> or legal reasons.
The current registry requires merge approval to remove a package. This can be
used to prevent "leftpad"-like disastrous takeovers.
wavexx: for some time the forum was able to mirror posts to dedicated mailing
list. Unfortunately the SMTP integration has been shut down.
There was also an attempt at receiving messages from the mlist using POP - see
[https://github.com/nim-lang/nimforum](https://github.com/nim-lang/nimforum)
Logging in libraries is pretty common across different languages. It's not
invasive as long as libraries do not explicitly configure loggers to create
files and so on. The application is at the root of a hierarchy of loggers and
can set verbosity and backends for all imported libraries.
geo555 you can pick packages from Artful Aardvark (the current stable release)
or Bionic Beaver. They both ship 0.17.2 and are imported from Debian. There is
also HTML documentation in the nim-doc package.
[https://launchpad.net/ubuntu/+source/nim](https://launchpad.net/ubuntu/+source/nim)
There's an open PR for this:
[https://github.com/nim-lang/Nim/pull/6517](https://github.com/nim-lang/Nim/pull/6517)
@monster: since you mentioned Kubernetes - most container orchestration systems
can deploy and run arbitrary binaries in Linux containers. What matters is
performance and memory usage (and having small binaries is a little plus). Nim
is quite good in all of those.
Relevant:
[https://github.com/nim-lang/nimble/issues/413](https://github.com/nim-lang/nimble/issues/413)
Spam: if you need more logging helpers:
[https://github.com/FedericoCeratto/nim-morelogging](https://github.com/FedericoCeratto/nim-morelogging)
I'm using fsmonitor in
[https://github.com/FedericoCeratto/nim-testrunner](https://github.com/FedericoCeratto/nim-testrunner)/
and I'll be happy to support other OSes if fsmonitor did so.
Speaking of which, it's useful to track what dependencies (and exact versions)
were used in a build and ship this information with the binary.
This can be used to automatically identify if a binary was built against
libraries affected by known vulnerabilities or that use obsolete protocol/file
Speaking of crypto wrappers, a fairly complete wrapper for libsodium is at
[https://nimble.directory/pkg/libsodium](https://nimble.directory/pkg/libsodium)
or
[https://github.com/federicoceratto/nim-libsodium](https://github.com/federicoceratto/nim-libsodium)
Peer reviewers with experience in
I've seen flagging working well for other forums. When a comment is flagged as
spam by N users a moderator will be able to remove the comment and block the
account that posted it. If regular users abuse the spam flag the moderator can
block their account instead. N=1 is probably enough to start
I'm told that while marshal uses JSON, there is no guarantee that it will not
change.
@JohnS: are you developing this?
[https://github.com/johnscillieri/psutil-nim](https://github.com/johnscillieri/psutil-nim)
Issue created for the edit button:
[https://github.com/nim-lang/Nim/issues/4736](https://github.com/nim-lang/Nim/issues/4736)
> Anyone can raise a PR, but my perception is that very few do so
I think an "Edit me on GitHub" ribbon on the online copy of the docs could help.
> a periodic "lets figure this out together moment".
Some other projects are running monthly conference calls to improve
communication across
@andrea currently
[http://ci.nim-lang.org](http://forum.nim-lang.org///ci.nim-lang.org)/ is doing
only nimble install, indeed, but this is already catching some libraries that
fail to install. Running full unit/functional test suites might be unnecessary
for this use-case and too heavy on the
I don't know about StackOverflow Documentation, but the GitHub wiki allows
exporting pages. We could use it for collaborative editing and then extract
good pages and merge them into the mainline doc at release time.
I recommend using a local copy of the docs and using theindex.html when looking
for something.
IMO the docs would benefit from examples, usage patterns, and more linking
across pages (e.g. between manuals and library docs)
Maybe adding a "help improve this page" GitHub ribbon to the online
85 matches
Mail list logo
