Suppose this piece of code for a very simple menu system I'm developing in Nim.
type
MenuId = enum
MainMenu, FileMenu, EditMenu, ViewMenu
ActionId = enum
Action1, Action2, Action3
ActionKind = enum
GoToMenu,
I think most cases are a balance between performance (speed) and resource usage
(RAM). But probably someone else knows better...
Godot is probably the best 100% free game engine overall. It has 2D support
[(now with
"pseudo-3d")](https://godotengine.org/article/godot-32-will-get-pseudo-3d-support-2d-engine).
There are [Nim bindings](https://github.com/pragmagic/godot-nim).
Being a much simpler language FreeBasic may be fast (having no GC for example),
but I bet it won't be reasonably faster than Nim. I don't really see why now
anyone would choice FreeBasic over Nim, D, Rust or any other modern alternative.
> Because I'm looking for a cross-platform[Windows +Linux, etc], fast,
> relatively easy language that compiles to C or C++, and which can interop or
> imbed with code +libs from C or C++.
I'm curious to see some evidence that FreeBASIC is "fast".
(Although transpiled languages do have the adva
I think encouraging the use of `nimpretty` and extending its features could
subdue a lot of criticism currently directed at Nim. It can even have options
for consistency in things like:
* Identifier casing / underscore style.
* Forcing explicit module prefixes (probably the biggest issue for
I would not say that Nim has perfect support for Unicode in Windows console
because it hasn't. Neither input, nor output of unicode chars works out of the
box in any version of Windows from WinXP x32 ANSI to Windows 10 x64 Unicode.
But actually it is not Nim fault, but creepy Windows/MSDOS suppo
Goodwin refers to both Rust and Pony. I think that Pony has the bigger
potential, especially when combined with the Bacon/Dingle approach. They have
something in common: An adaptive view to a given reference. It might change
from e.g. "owned" to "unowned". Pony offers a little bit more than
Bac
I was looking at some string routines and I noticed that some string functions
like toLowerAscii, indent, replace, etc take a string and return a new string.
While a few others like removePrefix, addSep do in place modification. Is this
for a reason or convention?
It may be due to how the console is treated. winlean library implementation
seem to default to wide-chars operations instead of your expected one byte char.
Try compiling with this flag, see if it makes any diffeence for you:
-d:useWinAnsi|
---|---
For me is not working as that mode -
> 1a. I find the lack of built-in hash tables in Nim a disadvantage.
Can you explain that? There are advantages of course for not making hash tables
a compiler builtin, for example it would make the compiler more complex,
separate modules let us choice different implementations. I do not see the
> And Nim lacks the build tools, available for every Go programmer.
What tools?
Update: This weekend I decided to try Haxe once again. I successfully installed
the Lime library, and built a simple example (via compilation Haxe -> C++).
Results:
1) It works. Although the compilation time is VERY, VERY, VERY, ..., VERY LONG
in comparison to both Nim and Go.
I can only hope,
Are you truly, positively sure ?
[https://www.ascii-codes.com/cp866.html](https://www.ascii-codes.com/cp866.html)
14 matches
Mail list logo
