bgracontrols VS Nim

Compare bgracontrols vs Nim and see what are their differences.


🆗 BGRA Controls is a set of graphical UI elements that you can use with Lazarus LCL applications. (by bgrabitmap)


Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority). (by nim-lang)
Our great sponsors
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
bgracontrols Nim
1 127
112 12,404
0.9% 1.8%
4.9 9.9
3 months ago 7 days ago
Pascal Nim
- GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of bgracontrols. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-09-12.


Posts with mentions or reviews of Nim. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-23.
  • Most viable game (+ physics) engines for Nim in 2022?
    2 projects | | 23 Jan 2022
  • Antivirus software incorrectly flags Nim programs as malware
    1 project | | 22 Jan 2022
  • The case for a modern language (part 1)
    1 project | | 22 Jan 2022
    > isn't cpan pretty much the grandfather of "oh there's a library for that"?

    The TeX CTAN in 1992 [1] was clearly the inspiration for CPAN a year or three later [2] (in both name & thing). So, maybe CTAN is the great grandfather? :-) { My intent is only to inform, not be disputatious. I know you said "pretty much". }

    To be fair, C has an ecosystem. OS package managers/installers are a thing. There is surely a list of much >1 "core libs/programs" (terminfo/curses/some text editor/compilers/etc.) that would be in most "bare bones" OS installs upon which you could develop. One certainly depends upon OS kernels and device drivers. IMO, at least one mistake "language" package managers make is poor integration with OS package managers. Anyway you cut it, it is hard to write a program without depending upon a lot of code. Yes, some of that is more audited.

    As the "lump" gets giant, dark corners also proliferate. There was a recent article [3] and HN discussion [4] about trying to have the "optimal chunkiness/granularity" in various ecosystems. I agree that it is doubtful we will solve any of that in an HN sub-to-the-Nth thread. I think that article/discussion only scratched the surface. I will close by saying I think it's relatively uncontentious (but maybe not unanimous) that packaging has gone awry when a simple program requires a transitive closure of many hundreds of packages. FWIW, I also often write my own stuff rather than relying on 3rd parties and have done so in many languages. Nim [5] is a nice one for it. It's not perfect - what is - but it sucks the least in my experience.






  • Why static languages suffer from complexity
    5 projects | | 19 Jan 2022
    > I think the message is more nuanced

    I thought it was more nuanced too as they were explaining how integer types can be derived, until I finished the article, and they really did just seem to be complaining that there's a mismatch between compile time and run time.

    Dynamic types don't really solve the problems they mention as far as I can tell either (perhaps I am misunderstanding), they just don't provide any guarantees at all and so "work" in the loosest sense.

    > otherwise wouldn't lisp with its homoiconicity and compile time macros fit the bill perfectly?

    That's a good point, I do wonder why they didn't mention Lisp at all.

    > we don't have a solution yet

    What they want to do can, as far as I can see, be implemented in Nim easily in a standard, imperative form, without any declarative shenanigans. Indeed, it is implemented here:

    Of course, that implementation is more complex than the one in the article because it handles a lot more.

    At the end of the day, it's really a capability mismatch at the language level and the author even states this:

    > Programming languages ought to be rethought.

    I'd argue that Nim has been 'rethought' specifically to address the issues they mention. The language was built with extension in mind, and whilst the author states that macros are a bad thing, I get the impression this is because most languages implement them as tacked on substitution mechanisms (Rust/D), and/or are declarative rather than "simple" imperative processes. IMHO, most people want to write general code for compile time work (like Zig), not learn a new sub-language. The author states this as well.

    Nim has a VM for running the language at compile time so you can do whatever you want, including the recursive type decomposition (for example: It also has 'real' macros that aren't substitutions but work on the core AST directly, can inspect types at compile time, and is a system language but also high level. It seems to solve their problems, but of course, they simply might not have used or even heard of it.

    5 projects | | 19 Jan 2022
    > not slowing one's work

    Put back into context, your reply makes sense as these popular libraries are pretty battle tested. Having said that, it is a valid point that type hints being voluntary means they can only be relied upon with discipled developers and for code you control. Of course, the same point could be made for any code you can't control, especially if the library is written in a weakly typed language like C (or JS).

    > I just don't see its absence as the crippling dealbreaker

    My genuine question would be: what does dynamic typing offer over static typing? Verbosity would be my expectation, but that only really seems to apply without type inference. The other advantage often mentioned is that it's faster to iterate. Both of these don't seem particularly compelling to me, but I'm probably biased as I've spent all of my career working with static typing, aside from a few projects with Python and JS.

    > if there are languages besides JS that you feel get their type system "just right", I'd be curious as to what they are

    This is use case dependent, of course. Personally I get on well with Nim's ( type system: It's certainly not perfect, but it lets me write code that evokes a similar 'pseudocode' feel as Python and gets out of my way, whilst being compile time bound and very strict (the C-like run time performance doesn't hurt, too). It can be written much as you'd write type hinted Python, but it's strictness is sensible.

    For example, you can write `var a = 1.5; a += 1` because `1` can be implicitly converted to a float here, but `var a = 1; a += 1.5` will not compile because int and float aren't directly compatible - you'd need to type cast: `a += int(1.5)` which makes it obvious something weird is happening.

    Similarly `let a = 1; let b: uint = a` will not compile because `int` and `uint` aren't compatible (you'd need to use `uint(a)`). You can however write `let b: uint = 1` as the type can be implicitly converted. You can see/play with this online here:

    This kind of strict typing can save a lot of head scratching issues if you're doing low level work, but it also just validates what you're doing is sensible without the cognitive overhead or syntactic noise that comes from something like Rust (Nim uses implicit lifetimes for performance and threading, rather than as a constraint).

    Compared to Python, Nim won't let you silently overwrite things by redefining them, and raises a compile time error if two functions with the same name ambiguously use the same types. However, it has function overloading based on types, which helps in writing statically checked APIs that are type driven rather than name driven.

    One of my favourite features is distinct types, which allow you to model different things that are all the same underlying type:

  • Why Static Languages Suffer From Complexity
    8 projects | | 19 Jan 2022
    Nim is another candidate in the Zig-like space of exposing the AST to the macro system, and also has (albeit experimental) concepts. Perhaps more interesting is coalton, which is a functional type system on top of Common Lisp - the most dynamic language out there. Curious if you have any thoughts on those!
    8 projects | | 19 Jan 2022
    Nim is probably the closest I've seen, but I'm still waiting for what you're describing.
  • Static code generation DSL.
    6 projects | | 19 Jan 2022
    There are languages that work as source-to-source compilers like Haxe, Zig, Nim, but no emphasis on IR which you can compose with your own transformations.
  • Failing to Learn Zig via Advent of Code
    4 projects | | 17 Jan 2022
  • daily report for Nim language
    2 projects | | 16 Jan 2022
    merged PR(,

What are some alternatives?

When comparing bgracontrols and Nim you can also consider the following projects:

zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

go - The Go programming language

haxe - Haxe - The Cross-Platform Toolkit

rust - Empowering everyone to build reliable and efficient software.

rust - Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266

crystal - The Crystal Programming Language

NumPy - The fundamental package for scientific computing with Python.

godot-docs - Godot Engine official documentation

node - Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:

nimterop - Nimterop is a Nim package that aims to make C/C++ interop seamless

tqdm - A Fast, Extensible Progress Bar for Python and CLI

Carp - A statically typed lisp, without a GC, for real-time applications.