proc fibonacci(n: int): float =
if n < 2:
result = float(n)
else:
result = fibonacci(n-1) + fibonacci(n-2)
echo fibonacci(50)
On my machine it is faster then any other language out there, including C.
This are the ones I have tested: fibonacci_c fibonacci_cpp fibonacci_java fibonacci_javascript fibonacci_.net fibonacci_nim fibonacci_pascal fibonacci_python fibonacci_rust fibonacci_scala
This are some of my reasons why I chose Fibonacci to test the languages: the code is very simple and makes it very easy to implement it the same way in all the languages. Also it test the language ability to use the stack, it does some type casting, and float operations. It also works with small and big numbers.
Some of these design choices have their downsides too of course, but it's really not hard not to spot differences everywhere: Syntax, type system, compilation model, produced binary sizes ...
I don't understand why the other languages are slower, but you can make the Nim version faster by using smaller types (same as your other languages) and using an explicit main function:
proc fibonacci(n: int32): float32 =
if n < 2:
result = float32(n)
else:
result = fibonacci(n-1) + fibonacci(n-2)
proc main =
echo fibonacci(50)
main()
Edit: I believe this is some magic GCC can do on the source code that Nim spits out. Compiling with nim --cc:clang -d:release is not so fast.
and using an explicit main function:
Really?
I would be (again) very surprised, as fibonacci() was already a standalone proc, and all execution takes place inside this function. I can not imagine that the symbol "main" does any magic, and that echo is faster inside main should be not really relevant.
I mean a string composed of tokens. You can't do say parseExpr{a * x + b} which in D just syntax highlights everything normal even inside the {}. parseExpr"a * x + b" requires the editor to treat everything between "a * x + b" as untyped, untokenized string characters.
It's really a very minor quibble though. Nim has statement macros, which work in much the same way.
It's may be a strange question, but what do you think about PureBasic ?
I don't think about PureBasic, because it's proprietary. I don't hate proprietary software - I'm sure plenty of people find it useful - but I have no use for it personally.
It seems like PureBasic had a raison d'être around the turn of the millennium, when BASIC / VB was popular in universities and business, and that carries some momentum to the present day. It added Mac & Linux/GTK support, and went a different path than MS VB did with .NET, which probably made it a better BASIC for many business needs.
But in the current year there are better alternatives on every level. It can't run on other OSes (ex. FreeBSD) without emulation. Its GUI builder is no longer a competitive advantage given free Glade / Qt Creator, which have bindings for many high-level languages. (Not to mention that Java and Mono are now portable and "free".) And the BASIC syntax is (IMHO?) much uglier than languages like Crystal, Swift, D, and especially Nim.
</off-topic>
Back on topic, the big news in Dland is:
"The D programming language front-end has finally been mainlined in GCC! There is now D support beginning with GCC 9."
I wonder if that will affect D's popularity...
I wonder if that will affect D's popularity...
What does "mainlined" mean?
Ada and Modula-2 have had GCC frontends for decades now, but they're still basically invisible. One reason may be that they typically require you to download and/or build a separate compiler. In Modula-2 you have to download an earlier GCC, then compile it through a process that does not seem to work half the time. (I felt a huge sense of accomplishment when I made it work on one machine, then moved to another machine and couldn't replicate it.) For Ada you basically have to download gnat, which may or may not install an earlier version of GCC.
On the other hand there were Java and Python frontends on the GCC, and where are they now? I think only Ada and Fortran frontends are really good GCC citizens along side with C/C++/ObjC.
The main Modula-2 developer said at a 2016 GCC development conference that the developers' penchant for changing major subsystems makes things pretty hard on front end developers. The silver lining (his phrase) is "a cleaner front end."
For Modula-2, where there really isn't much competition, where the language has stopped developing, and where the main developer is a guy who has spent his life implementing Modula-2 compilers, that probably isn't a problem. (Yet even now, after 20 years, it's still not part of GCC proper!) For Java, the open-source competition, the constant extension to the language, and the fact that other opportunities are available for the people who work on that sort of thing, probably spelled the end of the GCC effort. The GCJ developers said this explicitly, and I imagine that this is true of Python, especially with the Python2 -> Python3 revamp a decade ago.