@Krux02, good suggestion.
I like the direction that things are going with the website!
Very nice site! Much improved!
I like @Stefan_Salewski proposed wording changes. I don't agree with the @Krux02's menu, I think menus on the web are meh.
yeah, dropdowns are a no-go. Especially when considering that they don't support mobile at all.
Statically typed and compiled, it provides unparalleled performance in an elegant package.
If you check the exact meaning of "unparalleled" you may get: "having no equal; better or greater than any other". So it is better than C, C++, D, Rust and all the competitors?
Of course it is This is very much about marketing, which you even mention in your next paragraph...
High-performance garbage-collected language
As we know, that not all people like GC too much, marketing guys would write something like "High performance with true parallel executation and optional highly tuneable realtime GC support"
Perhaps we can add that it's optional into that point, but your version is far too long.
Runs on Windows, macOS, Linux, and more
I don't like the wording too much, and indeed it is not absolutely clear. Does it refer to the compiling process, the produced executable or both?
I agree, this is a bit vague. Perhaps "supports" instead of "runs" is better here, what do others think?
That's just a longer version of what you quoted.
Produces dependency-free binaries
Sounds like a big blob: Maybe "Produced executables are small(down to a few kBytes) with selectable dynamic or fully static linking for dependency-free binaries
Perhaps, but again that's too long IMO.
Krux02: Well, we all know that of course.
I was talking about "advertising" on the start page. "Optional, highly tunable GC" sounds great, and is not really wrong. Standard lib depends on GC, that is true. But for embedded devices or microcontrollers we may not need seqs and strings, so we may work in principle without GC. And I think there is even a stack-based GC option in development.
"unparalleled performance" are really strong words -- smart people know D, Rust and C/C++ well and see at once that this statement is not fully true.
One more remark: Personally I would put license information on the front page -- fully open source, community supported, MIT licensed. Not only for Libman that is an important fact, I have missed that information on front pages of some other languages. Putting it in the FAQ may be an indication that license is not a high priority for the developers, indicating that License may change later...
Well, when you say that GC is optional, you should say that disabling it pretty much makes the types seq and string unusable, and therefore the GC is not really optional.
Then how was I able to write Nim's GC in Nim? Of course it is optional.
You can also use --gc:stack and use Nim's full stdlib without the GC. (Yes, you need to handle memory regions then but that definitely counts as avoiding the GC.)
@Araq Well I did in fact know very little about the possibilities to use Nim without garbage collection. All I heared about was the string and seq are implemeneted in a way that they need the gc to run. Because I did not find any other documantation I came to the conclusion that disabling the gc is pretty much useless, because it creates leaks for nim's fundamental types. I am sorry though for the original words I had chosen. I wrote that comment when I had some frustration when writing the sizeof alignof implementation.
It would be nice if there would be a little bit more documantation oft the garbage collection in Nim. Especially on how to use Nim, when there is no GC.