firesloth

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.

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.

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 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.

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 ).

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?

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

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).

I did something very similar with a bash function:

  function git-commit-fixup() {
    git commit --fixup ":/$*"
  }
  alias gcf="git-commit-fixup"
  # Looks for the most recent commit that matches its arg
  # eg: we have three commits with messages: 
  #   "fix: the thing" 
  #   "feat: 5 percent cooler"
  #   "test: test coolness"
  # then we do some work and git add, then do:
  gcf cooler"
  # now we have 4 commits: "
  #   "fix: the thing" 
  #   "feat: 5 percent cooler"
  #   "test: test coolness"
  #   "fixup! feat: 5 percent cooler"
  # And autosquash will combine the fixup commit with the appropriate semantic commit as you say.

Sadly I've stopped using it as someone introduced a bunch of commit lint git hooks that choke horribly on the "fixup!" part. And you can't pass --no-verify while rebasing.

My understanding is that nim's arc memory management strategy inserts frees where it can automatically without being a GC, and that rust actually does something similar in many cases. Nim's arc doesn't handle cycles, and there is a more GC-like orc strategy. Even using only arc (and refraining from cyclic data structures or handling those specially) still seems better than "barely ... anything on top of C apart from an oop system".

I have a bash function I use to checkout a git branch based on a search string:

  function git-checkout-branch-by-search-string() {
    local maybe_branch_name
    maybe_branch_name=$(git branch --sort=-committerdate | grep $1 | head -n 1)
    if [ -n "$maybe_branch_name" ]; then
      git checkout "${maybe_branch_name:2}"
    else
      echo "Could not find branch matching $1"
    fi
  }
  alias gcos="git-checkout-branch-by-search-string"

Branches often include things like ticket numbers and project keys, so you can do

  $ gcos 1234

and save some typing.

I have a pair of fixup commit functions, which make it faster to target fixup commits prior to rebasing:

  function git-commit-fixup() {
    git commit --fixup ":/$*"
  }
  function git-add-all-then-git-commit-fixup() {
    git add .
    git commit --fixup ":/$*"
  }

Long function names that are then assigned to an alias can make it easier to find them later if you forget rarely used ones. That is you can do:

$ alias | grep fixup

to see the list of relevant aliases and the functions they call.

I also have two functions I use like a linear git bisect:

  function git-checkout-parent-commit() {
    local prev
    prev=$(git rev-parse HEAD~1)
    git checkout "$prev"
  }
  function git-checkout-child-commit() {
    local forward
    forward=$(git-children-of HEAD | tail -1)
    git checkout "$forward"
  }
  function git-children-of() {
    for arg in "$@"; do
      for commit in $(git rev-parse $arg^0); do
        for child in $(git log --format='%H %P' --all | grep -F " $commit" | cut -f1 -d' '); do
          echo $child
        done
      done
    done
  }

I did something similar in bash using cd instead of jump.

  export CDPATH=.:~/.marks/
  function mark {
    ln -sv "$(pwd)" ~/.marks/"$1"
  }

I prefix all the "marks" with a symbol (eg "@") then if I do

  $ cd @

then press tab it will list all the marks, or autocomplete if I type more.

Actually another way to do nimscript is to make a config.nims file with tasks in it. eg:

In config.nims:

  switch("hints", "off")
  task hello, "say hello world":
    echo "hello world"

In bash:

  $ nim hello
  hello world

For nim, you could use something like nimcr (https://nimble.directory/pkg/nimcr). You put a shebang in your script `#!/usr/bin/env nimcr` and then call it like a normal script.

eg:

  $ code script.nim


  #!/usr/bin/env nimcr
  echo "hello world"


  $ ./script.nim
  hello world

edit:

There's also the possibility of using nimscript, using nim e. It works similarly but you'd change the shebang line to something like

  #!/usr/bin/env nim e --hints:off