I've actually enjoyed playing around with Beef, the dev basically took C++ and gave it the syntax and core library design of C#. Here's a page from the guide just to give an example of the look and feel: https://www.beeflang.org/docs/language-guide/memory/
Note that despite the appearance, there's no GC, no ref-counting, explicit manual memory management, and so on.
One of my favorite things about it is the way it handles memory during debug runs. (My #1 favorite thing is that it was all developed by one guy working solo - Brian Fiete, a cofounder of PopCap Games.) First, it's able to trace allocated memory during debug execution and immediately report on memory leaks, along with the location in code where the leaked memory was allocated. Second, it can guard against use-after-frees in debug by marking the memory freed, but not actually reclaiming it. Any subsequent writes/reads to that location will immediately fail with the object's allocation stack trace.
Both of these are turned off during normal builds but seem to be excellent debugging tools.
The IDE is also cool and was developed in conjunction with the language. It's not the most feature-rich application and there are some bugs as you'd expect, but it's a perfect example of dogfooding as it was written in Beef. Hot code reloading is also supported.
Note that I have zero connection with this language, other than that I really enjoy it so far, and that I reported a minor issue that is probably very specific to me and me alone, and Brian replied to me personally and we had a pleasant brief exchange.
And coupled with the implicit `context` system, it can very easily profile third party Odin code's allocations too!
As far as performance vs C - there's not a lot of features that incur dynamic dispatch: virtual method calls, dynamic casts (as/is keywords), and direct interface dispatch. When you use interfaces as generic constraints, those monomorph into static dispatches unless the implementing method itself is virtual.
For C-style code, however, the performance should be the same as the C equivalent in Clang. File a bug if it isn't!
Existing C++ tooling (sanitizers) achieve this too.
https://mobile.twitter.com/odinlang/status/11957620628419379...
It was really fun to hang out and talk shop
I created Odin for the very same reason that I wanted a tool that made me more productive and helped me solve the problems that I actually have. Even if Odin only benefited myself, I would class that as a success, but it has been helping so many people create amazing things.
Perhaps, but a programming language which is released when “done” is essentially dead on arrival. I’d guess the people who created amazing things with Odin helped the language move forward, right? Nothing wrong with keeping something to oneself, but promising for a long time to move something into an open source model with no set date.. I’ve rarely seen that end well. Hope I’m proved wrong though!
A reverse corollary to Russell's Teapot? So what if there is a teapot orbiting Jupiter, I can't get it so it allows me no ability to serve tea. Therefore it might as well not exist!
Just say it's not useful to you because you can't use it. No need to say it doesn't exist, even if it just doesn't exist "for you."
(As an aside, I think a lot of societal problems in the world today have roots in relativism and such -- so it's a bit of a bugbear.)
Of course you could make the argument that its mere existence and him highlighting certain aspects could have influences on other language designers... and wow am I going down a tangent spiral now...
Anyways: TL;DR reality is objective but words can have complex semantics
nimc --gc:none
Also, the arc/orc GC is shaping up and already allows you to use exclusively reference counted memory management - so, efficient and perfectly deterministic timing but still get automatic memory management. (As usual, if you introduce cycles, it becomes more complicated)
And the Nim compiler elides many ref/unref ops, as well as keeping objects thread-local, so most performance objections to ref counting don’t actually apply. (.... and you have a choice of other automatic GC modes, including “none”)
What good is a language if you can't (easily) use its libraries?
It has very different selectable GC systems - Boehm, Bacon/Dingle, reference counting, or real-time deadline mark-and-sweep, and “none”. Perhaps I forgot one. Some libraries rely on a specific GC behavior but most work with any (with the caveat that “none” requires you to manually deal with garbage).
Nim’s mark-and-sweep is suitable for embedded systems and games, unlike Java’s, and so is the ref counting one; but even if none of the GCs work for you, the fact that there’s many of them and they are mostly interchangeable means that the dependency on them is much, much weaker than you are used to (although it still exists)
Fun fact: Odin has this exact same thing with `using`. https://odin-lang.org/docs/overview/#using-statement
Windows().apply {
width = 100
height = 200
}
val someStructure = ...
someStructure.x = ...
someStructure.y = ...
someStructure.name = ...
As far as I can tell, Odin's `using` is applicable in the same areas as Kotlin's, but I still favor Kotlin's scoped version. When I see "using foo;" in Odin, it's not quite obvious to me where the scope of applicability is.
Any reason why you didn't do something like
entity.use {
// "this" is now the entity instance
}
// back to your regular "this"
?Koltin's approach is limited to purely the same Pascal's `with` allowed.
But if you want to be clear:
{ using entity;
// the fields of "entity" are not usable in this scope
x = 123;
}
entity.x = 123;The D programming language can be used as a better C:
https://dlang.org/spec/betterc.html
and only requires the C runtime library to link to.
Nim is also a very complex language with numerous features to it making it a lot more complicated compared to C. So for someone who might like C might not like Nim. However, I recommend everyone try out as many languages to see what they like.
Being that I am the Odin creator, I do think you should give Odin a go because it is much more focused on being a C alternative and tackling the kinds of problems it solves.
https://forum.nim-lang.org/t/5734
The objective is to make nim suitable for embedded programming and other use cases for which garbage collection is a non starter. This new —gc:arc mode is already available in the nightly builds and the benchmarks are already impressive. I believe that the plan is to make arc the default “garbage collector mode” in nim 1.2.
Custom allocators are a pleasure to use, and allow for so much control. Along with the temporary allocator, you can make Odin feel like it's a dynamic language whilst being extremely fast. Custom allocators are an under-utilitized thing in programming in general, and I hope more people release what is possible with them that is not possible with automatic memory management schemes.
Why is garbage collection considered a negative thing?
I have no experience programming low-level languages, but I do follow and try new/obscure languages for fun.
Zig, Nim and V were the few I found + tried first, but I learned about Odin and Scopes recently and found them both interesting.
A programmer writing managed C# in an engine like Unity will often spend a lot of programming time ensuring that the code will not allocate every frame, as the additions to the heap will eventually trigger a pause.
That said, every game and its requirements are different, and some game development might not mind that as much. A C++ engine programmer on a Nintendo Switch is in a very different situation than a hobbyist in JavaScript or a server backend programmer on a mobile game.
I still remember when doing games in Basic/Pascal/C was considered to be like Unity nowadays, real games had to be written in Assembly.
As you say, every game and its requirements are different, and many 8/16 bit games were perfectly doable in C, Pascal, Basic and eventually the community moved along, just like it happened with C vs C++ a couple of years later.
I see the use of GC enabled languages the same way, and C# belongs to those languages that also offer other means of memory allocation, not everything needs to live on the GC heap.
Thank you guys for the response, super appreciate it.
I guess, I can understand from an abstract perspective that you can manually tune performance and optimize to a higher degree if you can control memory allocation yourself.
And for a lot of purposes where performance is imperative, like games or embedded devices it can make or break the ability of software to function properly.
But my question then is, if languages like Crystal, Nim, or D (or any other GC lang with similar speed) can operate either at/near the performance of C, why exactly do you need manual memory management?
And if you do need it, I assume many languages that cater to this audience provide some sort of symbolic annotation that allow you to manually control GC where you feel you need it, aye?
Optional manual memory management sounds great, but I'm skeptical it would work well in practice. The reason is that if the language default is GC, libraries won't be designed for manual memory management, meaning it will be hard for your manual code to interact with data structures created by non-manual parts.
Who's to say who's right and who's wrong? Ultimately life (and the subset of life that is software development) is a massively complex strategy and tactics game with a myriad of possible playing strategies and no agreed perfect solution.
That depends entirely on how you define and measure performance. If total throughput is your metric, then it's no problem - for example, Go is perfectly acceptable for web services.
Predictability of latency, however, is absolutely _not_ on par with C code. For example, 3D rendering with a GC can easily result in perceptible stuttering if care isn't taken to minimize allocations and manually trigger the GC at appropriate times.
> some sort of symbolic annotation that allow you to manually control GC
It's not that simple. D tried to sell this at one point, but it just doesn't work for large multithreaded programs and things aren't single threaded these days. Manually controlling a global GC means manually balancing, for example, one block of threads that perform lots of allocations and deallocations (and will starve if the GC doesn't run regularly) with soft real time networking code and hard real time VR rendering code. And (for example) you certainly don't want your rendering loop pausing to scan the _entire heap_ (likely multiple gigabytes) on each frame! Alternatively, in the case of Go (and depending on your particular workload) you might not appreciate the concurrent GC constantly trashing the caches.
Custom allocators and non-atomic reference counting are fantastic though.
Several companies have been selling Java, Oberon and now Go runtimes targeted to bare metal deployment on embedded scenarios.
Some of them are more than 20 years old, so apparently they might have one or two customers keeping them alive.
The hate against GC feels like the hate against high level languages on 8 and 16 bit platforms back in the day, because anyone doing "serious" stuff naturally could only consider Assembly as a viable option.
Since you mention telecommunications, I would consider network switches running Erlang a use case of embedded development.
Other examples would be the Gemalto M2M routers for messaging processing, or some of the NSN base station reporting platform.
So while it doesn't fit your scenario, it does fit other ones, this is what some in anti-GC field need to realise.
This isn't an all or nothing equation.
There is also a common misbelief that compacting GC helps make heap allocations faster than malloc. While technically true - the allocation itself is simple and fast, because it is only a pointer bump, a problem occurs immediately afterwards - this new heap memory hasn't been touched since the last GC, and it is very likely not cached. Therefore you get a cache miss immediately after the allocation (managed runtimes initialize memory on allocation for safety). Because of that, even allocating plenty of short-lived objects, which is the best case for GC, is not actually faster than a pair of malloc+free.
There are also other overheads:
* Managed runtimes typically use heap for most allocations and make stack allocation harder or not possible in all cases - e.g. it is much harder to write Java code with no heap allocations than C.
* To facilitate GC, objects need additional word or two words of memory - e.g. for mark flags or reference counts. This makes cache locality worse and increases memory consumption.
* During heap scanning, a lot of memory bandwidth is utilized. Even if GC does that concurrently and doesn't pause the app, this process has significant impact on performance.
* Tracing GC prevents rarely used parts of the heap to be swapped out.
You either use:
- an object. Which is on the stack and is either trivial or uses destructors and is suitable for embedded due to deterministic memory management
- a pointer object. Which is a raw pointer like C *. Managed directly via raw malloc/free or Nim malloc/free. Suitable for embedded
- a reference type. Which is managed by one of Nim GC or is an error if you use gc:none
FSecure's foundry USB security key, runs bare metal Go, TamaGo.
It runs even on the smallest microcontrollers.
I don't see C going away anytime soon, but it's exciting to see people attempting to replace it over the long term. Fun to see where it goes!
Odin fills like go with "special" runtime. For example dynamic arrays are implemented as compiler component in C++.
Zig has a runtime of its own now since it has added coroutines (async/await) as a core feature, but that is still extremely minimal aw well.
Too true. I ran into this after about 10 minutes of trying the language. Copy pasting from a GitHub issue? Better hope those invisible newlines are what you expect.
It would be interesting to hear from anyone who has spent time in both about the differences in experience.
It’s a trend of “Better C than C” languages that don’t go as far as Rust or C++ in terms of either complexity (or safety) but are more opinionated and modern than C. I think Nim can squeeze into this category, too, but maybe not? Nim is confusing to me.
Jon Blow is also working on one of these, but it isn’t released yet: https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md