It could be preserved if specifying the namespace used a different syntax.

Right now, if I have the `foo` module and `bar` function, I can call `arg1.bar()`, or `foo.bar(arg1)`. But if the namespace didn't also use `.`, then it wouldn't be an issue.

For sake of argument, lets choose `/` like Clojure. Then we'd get: `arg1.foo/bar()` so we can specify the namespace and uniform function call syntax is preserved.

True. That said, would you find, say,

    "one,two".std/strutils/split(',')

more readable than this?

    "one,two".split(',')

Maybe. First, you need the module name primarily for disambiguation for compiler or possibly for readability. I wouldn't recommend requiring it for everything, eg one of the arguments against requiring naming all imported symbols explicitly is for procs that use `[ ]`.

But I think the std/strutils/split counter example isn't strong for two reasons:

1. When you disambiguate in Nim, you use just the module name, not it's full path. So it would still just be `strutils/split`.

2. If we were to introduce such a syntax, we could also introduce an `import foobarbazqux as foo` alias syntax, which is present in many languages (eg JavaScript, Clojure, etc). This would also be useful if we ever had module name collisions, which has never happened to me in Nim, but doesn't seem impossible.

Charitably reading his comment, I think he sees questions about a "foundation", "organization", etc as the thin edge of a wedge for people with political agendas.

As a response to "Is there a Nim foundation?" it can be interpreted as "No, and there won't be, and this is why..."

Having said that, I like Nim, but have advised against using it in important projects for exactly this issue: it has bus factor 1 (ref https://en.wikipedia.org/wiki/Bus_factor ).

No it's not a bus factor of 1. Why would you think that? If you don't know why would you talk? There is at least another full time compiler dev. And a stream of contributors.

I believe it, but I'd be happy to be wrong. Here is my reasoning:

My concern is leadership, not technical ability per se. There are a number of people capable of maintaining Nim or advancing it (off the top of my head I can think of 6). The important question is, _will they?_ Has anyone involved made commitments about what they'd do? Has any such commitment been accepted by the rest of the community? Maybe I've missed such statements, but Araq's comment makes me think there just aren't any such plans.

If Araq is hit by a bus, what _will_ happen? I could think of a number of scenarios that seem _possible_ to me, some good, some bad, the problem is that I don't know which if any it would be. For example, maybe diverse contributors organize and take over the project, maybe just contributors from status take over, maybe it's forked repeatedly and the community fragments, maybe it putters along with just bug fixes, maybe it never sees another release, maybe Araq has it in his will that no one can ever use Nim again, etc.

Is there anyone we _know_ would take over for Araq? Do we have a a "Vicearaq"? If not, then I believe a bus factor of 1 is justified.

To be clear, I like Nim a lot and I introduce it to other devs given half a chance, but I don't feel comfortable betting other people's jobs on it at this time. Maybe it's just that Elm has made me wary of BDFLs and I should be less paranoid.

Typing that out is making me re-evaluate my position.

I made my judgement a few years ago, when the technical bus factor might have legitimately been 1, but there are a lot more people involved now, and some of them may have sufficient motivation to maintain Nim themselves rather than just move off of it ASAP. I'm still not sure exactly how it would shake out, but I think Nim would survive the absence of Araq, at least for a time.

Sorry for my earlier comment. I can't edit it anymore, but I will not make it again.

I was under the impression that using "nimrod" as an insult was an American thing (reference https://en.wikipedia.org/wiki/Nimrod#Idiom ). The creator of Nim is European.

It doesn't? https://nim-lang.org/docs/re.html and https://nim-lang.org/docs/net.html are part of nim's standard library. Are they missing something you expect?

They are dependent on pcre and openssl respectively unlike Golang which is native.

Well, sure Golang, but to be fair they are not native pure Python in Python's stdlib either...

This is more broadly relevant since part of the appeal of Nim is its easy C/C++ interoperability (by generating to these and so only requiring some declaration).

Has anyone tried prologue? https://github.com/planety/prologue

Yup, but it's more similar to "express" in Node than to a full framework like Django. I have plans to build a library on top of prologue for the ORM and database interaction and other cool features of Django that prologue currently lacks.

Without knowing too much about the original poster's particular circumstances, I expect this is probably the answer. If you can endure until early next year, things may improve.

I mentioned elsewhere, but I made a simple bash function that does something like that but matches a string in a previous commit message (because I found that easier to type quickly than a commit hash):

  function git-commit-fixup() {
    git commit --fixup ":/$*"
  }
  # usage: suppose there's a commit "fix: the thing"
  git-commit-fixup thing
  # now there's a new commit "fixup! fix: the thing" which can be autosquashed

Haha, true! On the other hand, is that better or worse than running into a string of "wip" commits that had the code in a broken state.

I've been recommending making a git tag before rebasing. eg:

  git tag -f pre-rebase

Me too. I made an alias that was _shorter_ than --force to make it easier to type (and hence more likely for me to use by default).