
A Programming Language Underdog - dom96
https://totallywearingpants.com/posts/nim-underdog/
======
gtycomb
Since I have used Nim in a small team effort creating an enterprise data
analysis application, let me put in a good word. The ease of coding and speed
of execution was what caught our attention. I was expecting the worst (from
past experiences with new languages) but we were so surprised that we could
complete our project all in Nim. These are a few things that I love with Nim:

\- One's knowledge of Python jives really well with Nim. Thinking in Pythonic
ways, a small number of constructs in Nim gets you a long way without gotchas
that block you. For example you can easily integrate Numpy in minutes.

\- Statically typed, fast compilation, readable code, good module import
system, binary executable that you can move around easily without installing
anything more at distributed sites, and a built-in test and integration
framework.

\- An efficient web server comes along, supports a practical and useful
template system for small team web applications. Concurrency. Async
dispatch/coroutines gives you back-end options to scale.

\- Nim's Postgres database client driver is glitch free, easy to use, and it
turned out to be a real good work horse.

~~~
billrobertson42
What about run-time safety? e.g. are the pointers? does it have builtin in
array bounds checking? (Heck, does it even have arrays?)

~~~
gtycomb
yes to all of these -- Nim also has those intrinsic benefits that statically
checked and compiled languages bring.

Arrays? As pleasantly nimble as Python arrays to say the least. Pointers are
lengthy discussion, but suffice to say that pointers are smartly handled to
avoid their pitfalls at runtime (while integrating with external C if you
really need to)

Time time and again as I went through using Nim, what really stuck with me was
that the designers had thought through these practical matters so very well,
and even in its current < 1 version the language is remarkably complete and
robust for practical programmers.

~~~
billrobertson42
Thanks. That's very interesting. I don't suppose you're going to tell me that
it has Clojure's amazing data structures too. :-)

~~~
PMunch
Well: [https://github.com/PMunch/nim-persistent-
vector](https://github.com/PMunch/nim-persistent-vector) But not built in. The
basic data types are very light-weight in their implementations to cover a
large range of needs.

------
nepeckman
Nim is my favorite language right now. If you look at the different metrics
that we use when discussing programming languages, it might not be the best of
any category, but its "good enough" in every category. It might not have as
powerful a type system as Haskell, but it's safe enough. It might not be as
fast as C, but its fast enough. It might not be as easy as Python or Ruby, but
it's pretty easy to get started with. It might not be the best web server /
embedded / native UI language, but it can do all of those things. Its
primarily procedural, but supports a lite version of FP and OOP, so you can
program in a comfortable paradigm. It's truly a jack of all trades languages,
and I think with a little time it might start mastering some.

~~~
vram22
What does it use for desktop UI dev?

~~~
nepeckman
There are a couple different libraries, not sure which one is the best though.
I know an official one is in development as well.
[https://github.com/VPashkov/awesome-
nim/blob/master/README.m...](https://github.com/VPashkov/awesome-
nim/blob/master/README.md#gui)

~~~
vram22
Thanks.

------
eggy
I had tried Nim a few years ago, and I liked it, but I am more of a Lisp or C
person. I am trying to learn Zig [1] which is intended to be a C replacement -
no GC, manual memory management, but avoiding C's pitfalls. Just recently I
have been playing with Terra [2] for low level stuff.

I am a fan of underdog languages - J, picolisp, shen, xtlang (extempore).
[3,4,5,6]

    
    
      [1] ziglang.org
      [2] terralang.org
      [3] jsoftware.com
      [4] picolisp.com
      [5] shenlanguage.org
      [6] extemporelang.github.io

~~~
peatmoss
If Nim’s compile-to-c is attractive, and you like lisp, how about Chicken
Scheme?: [https://www.call-cc.org/](https://www.call-cc.org/)

What little I’ve done is a pleasure. I like some of Racket’s post-Scheme
language features better, but Chicken has a lot of Get Stuff Done libraries
(eggs), and compiling a single executable is pretty killer.

Racket will bundle up an executable pretty well too, but it’s hard to compete
with Scheme -> C -> statically linked executable for some things.

~~~
sdegutis
The way Chicken Scheme compiles to C is pretty neat actually. It gets turned
into a giant chain of function calls, so that the stack never actually
returns.

So this Chicken code:

    
    
        (foo)
        (bar)
        (qux)
    

gets turned into this C code:

    
    
        foo(bar(qux()))
    

When it hits the C stack's limit, it resets the stack and unwinds to the
beginning, and starts over again. I think it was done this way to allow
call/cc to work without having to use setjmp/longjmp.

~~~
waterhouse
It also, assuming it follows Baker's original paper[1] (which I believe it
does), allocates all objects on the stack, maintaining the invariant[2] that
nothing on the heap points to anything on the stack, and nothing in an older
stack frame points to anything in a newer stack frame; and, to maintain this
invariant, it kicks things out of the stack and onto the heap whenever
necessary. The stack thus serves as a nursery in a kind of generational GC.

[1] "CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A."
[http://home.pipeline.com/~hbaker1/CheneyMTA.pdf](http://home.pipeline.com/~hbaker1/CheneyMTA.pdf)

[2] "CONS Should not CONS its Arguments, or, a Lazy Alloc is a Smart Alloc"
[http://home.pipeline.com/~hbaker1/LazyAlloc.html](http://home.pipeline.com/~hbaker1/LazyAlloc.html)

------
ducklingslicks
I read the article. Still no idea what Nim is good for and why it's better
than some other language.. and for which use cases?

~~~
dom96
This might sound strange but Nim is good for everything. From writing backend
services to creating web apps running on the client side. I've built
emulators, CLI apps, a full blown forum and much more in it.

It's particularly great for systems programming tasks that require high
performance and zero dependencies. For example, Status is currently writing an
Ethereum 2.0 sharding client for resource-restricted devices[1] in Nim.

Nim is also awesome if you've got an existing C or C++ codebase, the interop
that Nim offers is one of the best (if not /the/ best), especially when it
comes to C++ interop. As far as I'm concerned no other language can
interoperate with C++ libraries as well as Nim can.

1 - [https://github.com/status-im/nimbus](https://github.com/status-im/nimbus)

~~~
iTokio
What are Nim’s main weaknesses?

~~~
skellock
Post author here. A few things that make me sad in the pants:

\- js doesn't have source maps (kinda of a big deal to me)

\- some error messages are head scratchers (seem to remember trying to add
things to an immutable array not being clear)

\- docs could use love (eg seeing more examples of macros in action)

\- devel (their nightly compiler) can be rough (e.g. i found the "strings
cannot be null" cutover a bit rocky -- my own damn fault, i can't go back to
0.18 after being on 0.18.1)

\- the big one I think, however, is adoption. I keep hearing "i'll just use
rust or go". That's legit as they're also awesome.

nim's stdlib is massive (too big?) and there's tonnes of high quality packages
out there. You won't be left thinking... well, crap, looks like I need to talk
to roll this redis layer myself.

EDIT: Formatting. How does it even work?

~~~
kungtotte
The docs issue and devel being rough are both due to the pre-1.0 status and
the smaller community. It's a little bit of a catch-22; you need adoption to
gain contributors but people won't adopt until there's enough contributions to
make it stable.

~~~
dom96
yeah, which is usually where big companies help out. Their respect in the tech
communities makes people take note of the new technology.

I really really think "underdog" is the best way to describe Nim because of
this.

------
mratsim
By removing the C standard lib and using a custom linker you can get the Hello
World down to 150 bytes. Here is a fun read: [https://hookrace.net/blog/nim-
binary-size/](https://hookrace.net/blog/nim-binary-size/).

~~~
marmaduke
Other than a sort of ELF golf why would dropping the C lib be useful?

~~~
nickpsecurity
In high-assurance fields, the mindset is all code is malicious, buggy garbage
until proven otherwise by rigorous analysis. That means everything we include
will cost us. If we don't use it, we don't include it by default to save us
work.

------
peheje
Really excited to see Nim here on top of HN.

I wish it would gain more traction.

I like the pythonic syntax and easy 'fast code'.

~~~
AsyncAwait
I like the _concept_ of Nim, as in: fast, statically typed, inferred, compiled
etc. but I do not enjoy whitespace-sensitive languages, so am keeping an eye
on Crystal more than Nim.

If that doesn't bother you, Nim is really neat.

~~~
bbeonx
Actually, I'm curious why people don't like white space sensitive languages. I
get the tab v space thing, and there are certainly a couple of other down
sides, but none of these seem like deal breakers to me. Given that python was
the second language I learned, it's possible that I drank the coolaid early
and I'm blind to some things that are truly egregious.

So the question is: why do folks completely avoid a language for a single
relatively bland syntactic feature? Is there some cost I'm not aware of, or is
it just stylistic/aesthetic?

~~~
lylecubed
> why do folks completely avoid a language for a single relatively bland
> syntactic feature?

Personal preference isn't a good enough reason?

I don't like white space sensitive languages because I've seen what happens in
python when somebody accidentally adds a couple of lines formatted with spaces
into a file formatted with tabs. I've seen git and svn mangle tabs. Long
blocks are harder to track. Refactoring functions and nested ifs are much
harder to keep track of. If you somehow lose all of the formatting in a block
or a file, it's much more difficult to recreate the code if the only block
delimiters are whitespace.

Essentially, white space delimiters are just one more thing that can go wrong
and ruin my day. I try to keep those to a minimum. That said, Nim is my new go
to for short scripts. I wouldn't write anything large in it for the reasons
mentioned above.

~~~
kungtotte
Nim disallows tabs entirely, and in Python 3 it's an error to mix the two in
the same file. So those errors can't happen anymore.

Out of your list, the only one that seems like a real problem is recreating
blocks if the code lost all formatting.

~~~
lylecubed
You just described two errors that do actually happen and in the next sentence
say those errors can't happen anymore. What am I missing here?

~~~
kungtotte
The comment I replied to was talking about errors arising from mixing tabs and
spaces and incorrect indentation levels that arise from it.

If a language either disallows tabs entirely or will refuse to run/compile
code that mixes tabs and spaces in the same source file, you obviously can't
get errors related to mixing tabs and spaces.

------
jarcane
I find the framing of “no big backers” kind of weird, considering they do have
one big backer in a crypto currency startup that is providing the overwhelming
majority of its funding. Sure it’s not the big coffers of Google, but it’s
concerning that the entire language seemingly depends on the fates and desires
of an incredibly volatile field.

[https://nim-lang.org/sponsors.html](https://nim-lang.org/sponsors.html)

~~~
dom96
This is a very recent development and it will only serve to accelerate
development.

But yes, we do have sponsorship now. I don't consider it at the same level as
the likes of Google/Mozilla though. If it wasn't for those companies I doubt
Rust/Go would be alive today. You've gotta give us some points for our
persistence :)

------
decentrality
At the time of me writing this, the link to nim at the top of the article is
wrong. I let the author know, but it ought to be:

[https://nim-lang.org/](https://nim-lang.org/)

The first reference to the FQDN ends with "-" before the TLD, apparently
inadvertently.

~~~
decentrality
Right on, it's fixed now.

------
cshenton
Does nim have a concurrency story yet? That’s what gave me pause last time I
checked it out.

~~~
dom96
Yep. Concurrency is achieved via async await. Parallelism via `spawn`.

Here is an example from my book that uses both: [https://github.com/dom96/nim-
in-action-code/blob/master/Chap...](https://github.com/dom96/nim-in-action-
code/blob/master/Chapter3/ChatApp/src/client.nim)

~~~
karmakaze
Where is supporting use of multiple cores on the roadmap?

~~~
mratsim
Compile with `--threads:on` and everything in the threadpool module are
available. You can also use `CreateThread` for long-lived threads.

Alternatively, you have an open-mp for loop that you can use with `||`:

    
    
        for i in 0||1000:
          doParallelSomething()

------
nundah_guy
Exactly the same story with Dlang.

------
k__
All the languages mentioned got rather much publicity in the last years.
Wouldn't call one of them obscure..

~~~
skellock
I tried to phrase it as "wandering down the obscurity path" because I agree
with what you're saying: they aren't obscure. They're just not the default
choice.

------
fnord77
I do not think all this language fragmentation is a good thing. A million
little obscure languages that all at the end of the day do the same thing.

Yeah, we need language research to keep devising new features and more
efficient ways of programming, but this is different.

I wish the world would get behind a couple well thought out languages that
cover most programming needs (functional, systems/bare metal, scripting) and
stick with those.

I've seen some ridiculous and unsustainable stacks at some shops because
everyone got to pick their favorite language. Then the morale of subsequent
hires is in toilet because there's such a cognitive load to learn all these
little crap languages.

I feel like some of these languages come about because someone needed to do
some task and didn't understand or take the time to learn how to do it in an
existing language. Among the latest versions of the mainstream language, there
is no programming paradigm you cannot do.

And where these obscure languages REALLY fall down is tooling. Got debugger
support for this? Got perftool support? No, of course you don't.

With a small number of languages, work can be put into serious tooling, and
fixing compiler bugs, rather than a few devs spread thin trying to keep up
with the bugs in their hobby language.

~~~
habitue
This are great arguments for why we should all just use Java. Great tooling!
Lots of high quality libraries! Nothing to make you get out of bed in the
morning!

Why enjoy anything after all?

~~~
ehnto
We forgot to add enjoyment to the unit tests and now it would require a
refactor, sorry about that.

------
atombender
I really like Nim, but one thing that's stopped me from using it for any
recent project is the lack of Protobuf and gRPC support, which we use
extensively. There are some Protobuf libraries, but they're all incomplete and
unmaintained. Being able to generate code from gRPC proto files (either
compile-time or runtime generation) is a must.

~~~
dom96
Sounds like a perfect Nim project for you ;)

In all seriousness, I would love to write this myself... but I physically
cannot pour my heart into any more Nim projects. We need more people to help
us out!

~~~
atombender
Definitely a chicken/egg problem for nascent languages like Nim -- _someone_
has to furnish the house before people can properly move in.

The only way I could solve this and make Nim a viable language for these
projects is to spend my spare time tinkering, and that's unlikely to happen.

The situation is particularly problematic for something like gRPC where you
really have to know Nim well to create a good tool.

As cool as Nim is, I've gotten to a stage in my career where I just want tools
that work. That's the attraction of Go these days (though Rust is looking
nearly as good now) -- most libraries already exist, and you can focus on the
task at hand, instead of being forced to invent a bunch of wheels first.

------
Cognitron
Might be nice for scripting games in Unreal Engine? Looks like someone else
had the same idea:

[https://github.com/pragmagic/nimue4](https://github.com/pragmagic/nimue4)

------
bjourne
What's the status of Nim's garbage collector? [https://nim-
lang.org/docs/gc.html](https://nim-lang.org/docs/gc.html) Last time Nim came
up on HN someone said they were changing from reference counting to tracing.
Also seems like the Nim developers are reluctant to make a choice here? GC is
a show-stopper for some developers but an absolute necessity for others.

~~~
lylecubed
Nim has multiple garbage collectors you can change at compile time. Here's the
--gc option from the documentation.

    
    
        --gc:refc|v2|markAndSweep|boehm|go|none|regions
    

I don't know if this is up to date or not. There's an open issue on github to
improve the documentation on the garbage collector.

[https://github.com/nim-lang/Nim/issues/8802](https://github.com/nim-
lang/Nim/issues/8802)

------
ColinWright
Does it have arbitrary length integers? I've not been able to find any
reference to such.

 _Edit:_ OK, there's a library called "bigints" \- it's not clear how
"natural" the resulting code will be, but I might experiment.

~~~
arc776
Try "StInt: A fast and portable stack-based multi-precision integer library in
pure Nim"

Being stack based and having some nice compile time evaluation features should
make it very performant.

Here: [https://github.com/status-im/nim-stint](https://github.com/status-
im/nim-stint)

~~~
ColinWright
That's excellent - thank you.

Assume I'm not a complete numpty, but are there directions for:

* Download

* Install

* Invoke

... anywhere? I'm not at all familiar with retrieving and installing libraries
from git, nor with NIM and how/where to install code. All assistance
gratefully received. Pointers to existing detailed instructions also very
welcome. I can investigate all this myself with trial-and-error, but if
someone's done it before it saves me the time and effort of making all the
mistakes again.

Thanks.

~~~
mratsim
Easiest way to start with nim is via choosenim:
[https://github.com/dom96/choosenim](https://github.com/dom96/choosenim)

then `nimble install [https://github.com/status-im/nim-
stint`](https://github.com/status-im/nim-stint`)

Unfortunately I didn't have time to focus on documentation but the easiest way
to get started with Stint is to check the tests: [https://github.com/status-
im/nim-stint/tree/master/tests](https://github.com/status-im/nim-
stint/tree/master/tests).

The casts are there to check binary representation compatibility in the tests
and are not needed otherwise.

Alternatively you can check:

\- [https://github.com/FedeOmoto/nim-gmp](https://github.com/FedeOmoto/nim-
gmp), A GMP wrapper (very low-level/C-like and not updated since 2015)

\- [https://github.com/status-im/nim-decimal](https://github.com/status-
im/nim-decimal), a arbitrary-precision floating point wrapper to MpDecimal
(used by python). Unfortunately it's very low-level/C-like at the moment.

------
presscast
How does Nim stack up against Go? I got the impression that Nim was very
performant in the concurrency/parallelism space, but I'm wondering whether the
switch is worth making.

~~~
atombender
Nim has a level of richness you won't find in Go. Optional GC, unions, enums,
macros, compile-time function evaluation (so code generation and other
compile-time magic can happen in Nim code instead of via reflection or the
rather poor "go generate"), generics, async/await, real threads... Nim has
much of Go's simplicity while managing to be a lot richer. But it's also less
mature and has almost zero mindshare.

------
ngvrnd
The tutorial starts with a quote from a song by Rammstein.

"Der Mensch ist doch ein Augentier -- schöne Dinge wünsch ich mir."

Humans are just creatures of the eye -- Beautiful things are what I want

------
bayesian_horse
There is a race going on for the first language not being javascript being
compiled to javascript/webassembly and actually worth using.

No, coffee-script, typescript and the like don't really count, they are
relatively thin layers. Several options are in the works. Implementations of
Python and .Net (Blazor). Languages like Rust or Nim.

The crucial point is that it needs to have a compelling framework like vuejs
or react. Then the toolchain needs to be superb and result in small enough
webassembly packages.

No project is currently achieving this, to my knowledge. But the race is
heating up!

~~~
weavie
In my opinion, that race has been won.

Ocaml, or it's cousin ReasonMl are well worth looking into. Compile to JS with
Bucklescript. Compelling frameworks are Bucklescript-Tea for an Elm like
experience or Reason-React as a layer over React. Both frameworks are
excellent.

~~~
bayesian_horse
Bucklescript doesn't really count, because it is a relatively thin layer on
top of javascript, not even Webassembly. It looks interesting, but the lack of
popularity argues somewhat against it.

It may be still in the race...

------
JepZ
Another interesting upcoming language ist JAI:
[https://inductive.no/jai/](https://inductive.no/jai/)

Its purpose is to become a better C++ for game development (high performance,
simplicity).

~~~
mswift42
Can anyone explain what "designed for good programmers" means?

~~~
krapp
> Can anyone explain what "designed for good programmers" means?

It means "programmers who agree with Jonathan Blow and his opinions on what
good programming is."

------
Annatar
Interesting!

Minus: yet another proprietary package manager, bypassing the operating
system's software management subsystem (operational maintainability)

Plus: finally a language which compiles to binary executable machine code.

Plus: transpiles to multiple "backend" languages (but transpilers incur a
performance penalty).

Plus: can link with shared object libraries, thus having instantaneous
integration choices with an enormous corpus of existing software.

Plus: can turn off garbage collection, which is ideal for command line
programs designed to be chained with the shell pipe mechanism.

~~~
eeZah7Ux
> Minus: yet another proprietary package manager, bypassing the operating
> system's software management subsystem (operational maintainability)

False. Nimble installs packages only in the current user's home.

It's one of the few package managers that does not encourage the dreadful
"sudo pip/npm/... install"

~~~
dom96
oh, guess I shouldn't implement that[1] then :)

To be honest, now that I'm thinking about it again, I think you're totally
right.

1 - [https://github.com/nim-lang/nimble/issues/80](https://github.com/nim-
lang/nimble/issues/80)

~~~
Annatar
If you implement that, you instantaneously take away the ability to deploy
applications through OS's automated deployment (like Kickstart, Jumpstart, or
AutoYaST) and you create more work for every system engineer in existence
because they have to finish your work for you, namely integration of your
software (nim language) into the OS.

For every platform nim supports, native operating system package(s),
delivering into /opt/nim (and system-wide configuration into /etc/opt/nim)
should be provided. This is not some whim, it's a formal system engineering
specification. See LSB FHS, /opt, /etc/opt and /var/opt sections, or the
illumos filesystem(5) manual page for the same. (Why aren't you as a third
party supposed to deliver software into /usr as you intend in that Github
issue?)

If you do not do it this way, it will impede adoption because it's one thing
for a developer to play around in a language and another for a system engineer
to make it operational: system engineers' time is usually in extremely short
supply, and if they have to package your language for you, they could easily
just move on to writing software in a different language that they can mass-
provision natively, and nim will stay an underdog. Operational maintainability
is the end goal, means mass deployment without extra code or software like
Docker, only using native subsystems. Sooner or later things must go into
production.

Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere
into /usr, not even /usr/local.

~~~
debiandev
You seem to be confusing /opt and /usr.

> native operating system package(s), delivering into /opt/nim (and system-
> wide configuration into /etc/opt/nim) should be provided

No, native package managers should install binaries in /usr/[s]bin and
libraries under /usr

> Never bypass OS packaging. Unless you are an OS vendor, never deliver
> anywhere into /usr, not even /usr/local.

+1

~~~
Annatar
"You seem to be confusing /opt and /usr."

It is very unfortunate for me that it _seems_ this way to you, but as someone
doing precisely this kind of engineering for almost three decades, I can
assure you that this is not the case.

"native package managers should install binaries in /usr/[s]bin and libraries
under /usr"

Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian,
Canonical, CentOS, ...) _third party and unbundled applications_ must never be
installed into /usr: by doing so, one risks destroying or damaging systems in
production in the case where the vendor decides to deliver their own version
of the same software, and the vendor's upgrade overwrites one's own software
and configuration. Long story short: don't deliver your unbundled software
into someone else's space. /usr belongs to an OS vendor and to that vendor
alone (vendor in this context also includes volunteer operating system
projects one is not a part of).

/opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5)
manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4.
and 5.12.:

[http://illumos.org/man/5/filesystem](http://illumos.org/man/5/filesystem)

[http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt...](http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages)

[http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc...](http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcoptConfigurationFilesForOpt)

[http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...](http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varoptVariableDataForOpt)

section 3.13.2., _Requirements_ , explicitly states:

 _No other package files may exist outside the /opt, /var/opt, and /etc/opt
hierarchies except for those package files that must reside in specific
locations within the filesystem tree in order to function properly. For
example, device lock files must be placed in /var/lock and devices must be
located in /dev._

[http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#req...](http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#requirements7)

~~~
debiandev
> as someone doing precisely this kind of engineering for almost three
> decades, I can assure you that this is not the case

Same here.

> Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian,
> Canonical, CentOS, ...) third party and unbundled applications must never be
> installed into /usr

That's what I wrote: "native package managers should install binaries in
/usr/[s]bin and libraries under /usr"

"native" as in: provided by the distribution. Not third party.

[https://github.com/nim-lang/nimble/issues/80](https://github.com/nim-
lang/nimble/issues/80) is about using /opt/nimble and you wrote "If you
implement that, you instantaneously take away the ability to deploy
applications through OS's automated deployment", hence the confusion.

~~~
Annatar
""native" as in: provided by the distribution. Not third party."

It was a misunderstanding then: I thought native meant the packaging format
native to the OS, not packages which come with the OS (bundled software).

Issue 80 from what I understood is about nimble, a packaging format
proprietary to one programming language, providing system wide installation
capability; this would indeed preclude using native provisioning technologies
because those use the OS's native packaging format and hence know nothing of
"nimble".

