Happy to see you paint Nim in a (sort of) positive light, I hope I can help with this one negative.
> I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes.
Can you give some examples and elaborate on what you mean by "fail silently"? Did you at least get a segfault?
It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground with statically linking sdl2 (again on Windows).
The build/package/config system appear to in a bit of flux?
[ED: and I think there were old open issues and forum posts for both problems, hence no new bug reports...]
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.
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
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()
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.
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 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.
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"
But no matter how you look at it, there's no such thing as "simple" handling of international text.
Same goes for things like handling paths, line endings for text files, resource forks (or not) for files, changing file meta-data...
As for how it failed, it did not segfault. It just stopped and dumped me back out on the terminal with no output at all.
(I'm on OSX 10.12.6.)
Next time please create an issue on GitHub[1], you don't have to worry about creating a small example either, as long as you give us all the code to compile it.
If you do find anything else then do post it on GitHub, or at least let us know on IRC/Gitter.
Also, you can use auto too + Template constraints would help you here.
Seeing MapResult!R map(R, alias fn)(R range) makes it seem like MapResult is a thing you can reference/use. But it's an internal struct, so it's neither accessible not documented. That's a whole lot more confusing than having auto and documenting that the result is an input range.
typeof(var).stringof.writeln;
pragma(msg, "var has type: ", typeof(var));
Fortunately, the programmer gets to decide which to use.
Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?
In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a familiar language, and it's a bare-bones language, but that's not the same thing as being simple.
One last thing that was interesting: I got more null pointer runtime exceptions in Go than I expected (vs none in Nim, for example). Granted, I'm a Go n00b, but I'm also a Nim and Dart n00b, and didn't have nearly as much trouble with those two languages (aside from the aforementioned compiler bugs).
I really wish modern statically typed languages would rid us of null pointer errors once and for all. This is totally possible with Option types, but seems to rarely be done. I wonder why?
However, the compiler could (and did, I believe) run inference and suggest a fix that the programmer can explicitly include.
There are a number of RFCs in the pipeline to help with lifetimes, including more elision. In no particular order:
https://github.com/rust-lang/rfcs/pull/2115
Granted Rust has some paradigms and constructs which are not easy to learn, I found it rather exciting. I think it has future scope.
Wonder whats happening with Redox. I hope Rust adds more libraries, especially network related, since the networked world is increasingly looking like a distributed OS of sort. Browsers are looking like an OS or a shell inside the OS. Browsers are getting more complex with more functionalities added every few months. Not sure I expressed my thoughts correctly, but I guess one can understand what I mean.
Rust should move away from C standard library, if possible.
They've been involved in Google Summer of Code, and so have had lots of status update posts lately, here's the latest: https://redox-os.org/news/gsoc-self-hosting-final/
> Rust should move away from C standard library, if possible.
It's not always possible, but on systems where it is, there's some ability to do so, see https://github.com/japaric/steed
>It's not always possible, but on systems where it is, there's some ability to do so, see https://github.com/japaric/steed
Doesn't linking to it make a Rust program "unsafe", in the Rust sense? Or my understanding is probably not correct.
Toy example, a language that is simpler than possible:
- If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible".
The only example I know from Go:
- Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.)
(A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.)
So I've given you a single real example. But it's the only one I can think of.
Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.
It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago).
I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings.
I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings.
It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.
---
Thanks for your answers!
So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages.
You just list:
>(e.g. no generics, error handling littering my code and obscuring intent, etc).
But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.)
Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week".
You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you.
Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple.
Thank you.
No generics, error-handling obscuring flow of logic, dependency-management, the compiler complains about not-used vars and imports (which is great, except when you're prototyping) it should be togglable, it felt like I was producing a lot of code to do something small (I felt the same about C, but not about e.g. Nim), and then, I think the little oddities I mentioned in my comments on simplicity added up to make me feel like I was building an inelegant solution.
That's off the top of my head. There were possibly other gripes, and I am possibly mis-remembering, so take it all with a grain of salt.
(What I mean is if if you worked with Go every day you likely would not have the same perspective anymore.)
so thank you, perfect reply.
Simplicity is not the same as familiarity. It's not the same as a small feature-set, either. Gratuitous Rich Hickey reference for what I mean by simple[1]. So most languages aren't simple by that definition, but I'd say that Go's inconsistencies prevent it from being what I call simple. Some examples:
Instead of having a general mechanism for describing datatypes, they have several one-off, exceptional syntaxes (such as for how you define tyep type of a map).
Go's dependency management / vendoring (or lack thereof) is complexity-inducing, even though it appears simple at the outset.
Sometimes you do things via method (such as `fmt.Println(message)` and sometimes via function (such as `len(message)`).
And so on. Coming from a language like Clojure that is regular, possibly to a fault, Go seemed to be littered with one-offs and inconsistencies.
[1] https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign.
Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: https://www.youtube.com/watch?v=rI8tNMsozo0
Here's something familiar to most professional web developers: JavaScript.
But it's also complicated: https://www.destroyallsoftware.com/talks/wat
Here's the spec: https://www.ecma-international.org/ecma-262/8.0/index.html
And here's something unfamiliar and often considered difficult: lambda calculus.
And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia):
---
Lambda expressions are composed of:
* variables v1, v2, ..., vn, ...
* the abstraction symbols lambda 'λ' and dot '.'
* parentheses ( )
The set of lambda expressions, Λ, can be defined inductively:
1. If x is a variable, then x ∈ Λ
2. If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ
3. If M, N ∈ Λ, then (M N) ∈ Λ
Instances of rule 2 are known as abstractions and instances of rule 3 are known as applications.
---
So, while JavaScript programmers might find the lambda calculus unapproachable, it would be difficult to argue that the former has fewer gotchas than the latter, as the former is wildly complicated and the latter is so simple that you could fit its definition on business card. Once you appreciate the difference between simplicity and ease you can better evaluate your options, as it might be worth investing time in learning an intimidating, foreign solution if you believe that it will provide better stability/correctness guarantees/etc. Also, simple things are generally easier to work with compared to complex things assuming a similar degree of experience -- so investing in unfamiliar-yet-simple things will often save you a lot of effort in the long run. Strictly adhering to familiar things is a recipe for being stuck in a local optimum.
To take this full circle, Go being easy doesn't mean that it's simple.
You weren't kidding about the lambda calculus definition!
https://en.wikipedia.org/wiki/Lambda_calculus#Formal_definit...
With that said, your comment seems quite technical, about the single point of simplicity. You don't talk much about Go at all, and although the other poster has also answered, I'd be curious in your answer as well (if you've worked with Go):
You've given a definition of simplicity (correcting mine). Did you find Go simple? What other thoughts did you have?
D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `auto` to refer to its return value, so I don't know how to annotate my method.)
I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes.