Indeed there are some bugs with unicode output[1]. Just to be clear the standard way to output anything to the console is `echo` (similar to Python's `print`).

It seems that the progress on that issue has stalled. It's unfortunate but we do have limited man-power and rely on the community to help us out, this does mean that at this stage it helps if you don't mind getting your hands dirty with potential bugs.

Unless one of us are directly affected by a bug, or we see a large number of users affected by it, it's unlikely that we will focus on it. Not much we can do there sadly. I hope you can understand.

Regarding static linking I would say that it's challenging for most languages. Especially on Windows. If you pop into our IRC/Gitter channel[2] though I'm sure somebody would help you out. You can also probably get pretty far by asking C users for help.

Regarding the build system, perhaps you are referring to the fairly recent addition of NimScript? I think that has stabilised by now. But if you've got any specific questions about it then feel free to ask them.

1 - https://github.com/nim-lang/Nim/issues/2348

2 - https://nim-lang.org/community.html

As I'm now on my laptop with access to the two simple programs; for text output:

  import encodings
  var hello1 = convert("Hellø, wørld!", "850", "UTF-8")

  # Doesn't work - seems to think current codepage is utf8.
  var hello2 = convert("Hellø, wørld!", getCurrentEncoding(), "UTF-8")

  # Outputs correct text:
  echo hello1
  # Outputs corrupted text:
  echo hello2

(And simply outputting an unconverted string fails, like hello2 does).

As for the linking problem I had, the main issue is that it seems to be harder than it probably should, to get started with the GUI-programming with nim on windows. The following code works, provided one manually obtains sdl2.dll (and sdl2.lib for static linking) - however, even with static linking flags (no errors), the resulting exe still depends on the presence of sdl2.dll:

  import nimx.window
  import nimx.text_field
  import nimx.system_logger

  proc startApp() =
    var window = newWindow(newRect(40, 40, 800, 600))
    let label = newLabel(newRect(20, 20, 150, 20))
    label.text = "Hellø, wørld!"
    window.addSubview(label)

  runApplication:
    startApp()

With sdl2.dll (and .lib) in the same folder both of these work:

nim --threads:on --dynlibOverride:SDL2 --passL:SDL2.lib c -r win.nim

nim --threads:on c -r win.nim

but both fail without sdl2.dll present (ie: the "statically" linked exe still depends on dynamically loading sdl2.dll).

And there's so far no easy way of getting a "supported" sdl2.dll to go with the nim compiler - as far as I can tell, neither "nimble install sdl2" or "nimble install nimx" provide a way to get the sdl2.dll and/or C source code to compile it.

But perhaps managing DLLs and such is considered to be out-of-scope for nimble/nim package manager for now.

Ha, your comment was my first introduction to Nim but it looks interesting so I "brew install nim" and tried your test (thanks!) with "nim c test.nim && ./test" on macOS and my results is the opposite of your: hello1 is garbled while hello2 works.

I bit of googling found the next steps "nimble install minx" but for compiling your win.nim example I had to use "nim --noMain --threads:on c -r win.nim" but the result worked. However AFAIK, there's no official way to make statically linked binaries on the latest macOS.

It's not really Nim's fault that cmd.exe has crap Unicode support.

If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api").

It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "hello world" should "just work" on windows, and it doesn't.

It doesn't really make much sense to only do the right thing on systems that happen to have a utf8 locale (it's not that windows doesn't handle wide strings, it just doesn't have a utf8 locale by default).

It's not my impression that the nim community doesn't want to be cross-platform and beginner friendly - it's just that they're going through a phase of modernizing the win(32) sub-system.

Correct text handling isn't "just use utf8", as fun as that would be - correct handling is figuring out "what encoding is the source text", "what encoding is the destination file/device" and "how do I put the source into the destination".

I'd expect a latin1, a utf16 and a utf8 string to all be output correctly with "echo" - on all supported platforms. It's kind of why you would want to use a higher level language with "batteries included" in the first place.

Nim is not a Win32 runtime. It outputs strings to stdout. Any sane OS would do the right thing in 2017.

I should perhaps clarify that "just use the win32 api" refers to on Windows. Just as one might use syscall 4/write() on Linux, if one doesn't want to/can use libc printf.

See also, for example:

https://stackoverflow.com/questions/15528359/printing-utf-8-...

https://stackoverflow.com/questions/26106647/c11-unicode-sup...

http://www.cprogramming.com/tutorial/unicode.html

Note; I'm not convinced using utf8 internally is a great idea - especially for a "beginner friendly" language. Playing with anything from palindromes to revise strings and character/grapheme counts and

  "d o u b l e  s p a c i n g"

strings can be fun learning exercises - that might be easier with a 32-bit (or even 64 bit) representation.

But no matter how you look at it, there's no such thing as "simple" handling of international text.

I'm not sure how there can be "one true sane thing". There's more to strings than Unicode, and more to Unicode than utf8. In fact the os does pretty sane here - not checking for utf16 or utf32 isn't really great on Linux either (haven't checked how/if nim handles locales on Linux). Afaik, eg python3 does the right thing on Windows and Linux w/print(). It's just one of the many little things were one may whish for "one, simple, sane way" - but have to deal with the realities.

Same goes for things like handling paths, line endings for text files, resource forks (or not) for files, changing file meta-data...