Hacker News Reader

>I think it is also very hard to make a performance argument in 2020.

I think it is very EASY to make a performance argument in 2020. In every domain, from my phone, to my desktop pc, to our huge AWS servers at work, I encounter software that is slow. We struggle with our C/C+ database at work running on top of a C/C++ operating system. We can't buy a bigger server and it isn't fast enough to handle the load we get recently recently due to covid. You think I should be happy to incur GC overhead in both the OS and Database? No way! That would cost us a lot of money, and require a more complex architecture. (which also costs money)

On my desktop and phone I encounter applications that are annoyingly slow to start up, to compile, all kinds of things. The last thing I want is JVM or .NET runtime overhead occuring even at the level of my operating system, device drivers, etc adding to that. CPU cache space is precious, the low level things that everything else runs upon should be as efficient as possible.

I work in embedded software for network switches and almost everything is written in C. And most of the code is pretty new.

C++ fired back because integration was ugly (the SDKs are designed for C usage) and a lot of C developers that doesn't understand C++ well.

Go is used a bit, but again, training people for using it correctly is hard. And using the C SDK from Go is an obvious NO.

A lot there think that Rust would be in a similar situation that C++. Nice to have, but too much low level dependencies (hardware SDK) and high level (developers proficient in the language) to expect it to happen. Also, calling the SDK would convert everything I'm unsafe, so we are like in C, but with a language that nobody understands.

So, there are technical reasons, but also human resources and economic ones.

Yep, embedded is a whole other area than software that runs on a server host or desktop/laptop workstation. That shouldn't stop us though from improving safety where the restrictions of embedded development don't apply.

Ultimately I think the switch would pay off for most companies in the medium to long term. There are valid reason C is still the primary embedded development language but many are going away. One is that Rust only uses clang/llvm which doesn't support many targets. Still there are so many low level data races and challenges with embedded development that having a Rust environment would be a huge improvement, IMHO. The C / FreeRTOS project I’ve been using lately has random data races in the LwIP library which reset the device. It’s almost impossible for me to debug so I workaround by adding some delays here and there. C++ wouldn’t help resolve data races so it's just an extra cost. Also C++ exceptions on embedded are tricky, so the Rust error handling has closer semantics to C error handling.

A complete Rust system would likely help solve most of these issues and drastically reduce these bugs, increasing development speed. Unfortunately the lack of native SDK in Rust is annoying, but some groups are making progress on STM and no-lib Rust. It’d be great if STM makers adopted their sdk and made an official one!

Currently since Rust doesn’t support my chip, I’m using Nim to generate C. It doesn’t solve all the data races noted above but having generics and easy data structures like tables and vectors is fantastic and I'm not second guessing the code all the time. A deterministic GC covers my memory usages fine.

I work on network switches too, but we take the C SDK source, reverse engineer it, and write a bunch of C++ software that mostly does the same exact thing. It's already insane, I would not be surprised if some Rust components were added.

For some systems programming problems, the issue is real-time constraints. You need something to happen on a deadline, and adding GC prevents you from making that guarantee. Or, even if you don't have hard real-time constraints, sometimes you need very low latency in order for your controller to work properly.

Also, those high level languages require an OS. And many systems programs run on bare metal or a very minimal OS.

Edit: Also, the abstractions that higher level programming languages provide are often not really needed for low-level programming. In some ways, low-level programming is easier than application programming, since the actual programming required is often fairly straightforward and constrained by the application.

^^^ Yes. I see LOB apps and web-services being (re-)written in Rust from very high-level langs at great cognitive cost but little runtime benefit. Rust by all means should be treated as a better C(++) for applications where is is necessary -- but it rarely is. And most Rust code I see is simple and context/request-bounded - basically it amounts to a overly-complicated version of creating a private heap for the duration of a request, and then throwing it away, as making Rust happy with even mildly interesting data-structures that are expected to be long-running is a chore.

C# (per your example) is not orders-of-magnitude away from from C++ perf like Python is, but is w/in a very small constant factor, and often even faster for poorly-written C++ as GC is more efficient than calling copy c'tors where they needn't be called, for example.

And if you introduce features such as Span<> (and friends) and ref returns into your C# where you need them, you now how have safe GC-free/reduced code with perf that rivals Rust in the sections of code where you need it, with full GC as a backup.

Well written C# definitely has a performance ceiling that greatly reduces what things need C++ or Rust, but idiomatic C#, what most people actually write, what is taught and encouraged is pretty slow. (lots of linq, arrays of pointers to objects on the heap, that are iterated over with iterators instead of directly, calling virtual functions that are not devirtualized, etc etc etc)

One thing I like about Rust is the idiomatic way is usually very close to the fastest way. There are exceptions of course. But it you tend to get steered to efficient solutions.

Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstractions, like link-to-objects, etc.), with the other 5% requiring diligent attention (Span, etc.) - then your making gradual perf gains as you wish, all within the same language, runtime, and memory pool. This is much better than a re-write and dealing with FFI, or just as likely, full-on serialization between your old code and Rust code.

With that said, there isn't much of an excuse for non-0-cost enumerators, etc. -- given that refactoring tools switch between foreach, linq, indexing or ptr/spanning, you'd think the compiler-chain or jitter could do the same. Roslyn is a better back-end for meta-programming, but it's too bad MS denies us the benefits of surfacing meta-programming to the language or at least tool level, or we'd have tools that could easily convert linq to highly optimized code.

You could also have compiler-enforced "levels" of C# code that had restricted features/semantics, such as "alloc-free", etc. - right now the choice is just "default" or "unsafe".

I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like:

"LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)."

Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.

Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.

I’m going to disagree with you that idiomatic C# is somehow unnecessarily “slow”.

The performance overhead of a virtual vs non-virtual call on the CLR is negligible - same as with C++. For proof, look at Direct3D which is performance-critical, yet Direct3D’s API is based on COM which is all about vtable-calls.

Linq itself is also very decent. I won’t argue that Linq is perfect (e.g. suboptimal list allocations when the total output length can be known in-advance), but its hardly “slow” - certainly not enough to impact any production workloads - you’d only observe a difference between hand-written loops and a Linq expression in a contrived synthetic benchmark.

> Direct3D’s API is based on COM which is all about vtable-calls.

It isn’t. It looks like COM, but it isn’t.

Did things change with DX12?

Just asking because this article is quite clear about how DirectX is all about COM: https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-...

> The Microsoft Component Object Model (COM) is an object-oriented programming model used by several technologies, including the bulk of the DirectX API surface. For that reason, you (as a DirectX developer) inevitably use COM when you program DirectX.

DirectX yes, Direct3D no.

I am not sure about D3D9, but 10 and 11 and 12 are not COM.

We are talking about device drivers and OS kernels, as well as mission-critical realtime code that can't tolerate random latency injections (garbage collection). It's important to have a safe alternative to C and C++ in these contexts.

Naive question - what makes Swift less suitable than Rust for this?

Isn't Swift limited to just a few platforms?

It seems that it's not available both for the largest desktop platform, Windows, and for the largest non-desktop platform, Linux on ARM (https://swift.org/blog/swift-linux-port/ says "Currently x86_64 is the only supported architecture on Linux.") i.e. all the IoT devices which need code in a "systems language" and Android phones.

Swift doesn’t have sufficient control over memory (where things get allocated and using or avoiding the reference counted garbage collector).

Swift doesn’t make low-level control of memory and other low-level details easy.

Long-term: I feel that Swift was meant as Apple’s answer to C# and as way to retain XCode users as Objective-C became increasingly unfashionable over the past decade and Apple lost employees who could properly maintain it. Swift won’t go away, but I suspect that Apple doesn’t want to have to pay to maintain Swift while the rest of the industry gets to use it for free and port it to platforms that Apple won’t see any revenue from: i.e. Apple doesn’t want to be like Sun/Oracle and have other companies (Google) use their work (Java) for a competing platform (Android’s Dalvik).

So, I’m wary of adopting Swift - while Apple does currently support it on non-Darwin platforms right now I fully expect Apple to lose interest in maintaining first-class support for Windows and Linux at some point, just like how OpenStep was repurposed as a Mac-only when it became the rational decision for them.

Maintaining a thriving developer ecosystem and platform requires a degree of trust, transparency and a history of commitment to a product - and Apple (as a company) is the anathema of transparency.

Apple does write software for other platforms [1][2]. If they continue their shift to services I only expect that to increase.

However I think you are correct in that they won't want to put much effort into it. Their support for developers is already somewhat half-hearted if you compare it to Microsoft. Using XCode over the last few months has made me appreciate how good Visual Studio is. Apple's developer documentation has me missing Microsoft's.

[1] https://play.google.com/store/apps/developer?id=Apple+Inc.&h... [2] https://support.apple.com/en-gb/HT210384

There do exist real-time GCs, though. And there is no fundamental reason OSs couldn't be written in high-level, managed memory languages. Some of the oldest OSs were.

> GC can be treated like a backstop which helps to keep your application from exploding while you work on memory management, and then you can incrementally address heap alloc (aka latency) concerns with an application that actually runs (for a little while at least).

This is not a good approach in general. GC is only really needed in applications when working with data that's graph-like and potentially involves cycles of object references. A software project should be properly designed at the outset so that GC can be used in a "pluggable" way where it's strictly needed. Rust will probably enable this kind of use in the future, but other languages such as Go can already be used to comparable effect, seeing as they're generally limited to smaller pieces of code ("microservices") running in their own separate address space.

There are already a couple gc libraries in rust. I wouldnt say Go is strictly "pluggable gc" since...well you can't get rid of the gc. You can try and keep it from doing meaningful work but thats quite different than "RAII managed memory with a fallback to a gc library that targets my particular use-case"

Fully agree with you that GC should be abstracted away and used for where it shines: cycles and graphs!

is there any pluggable GC libary in rust that is both correct and stable?

The only one I've heard of is Boehm GC. Is it not correct or stable? I do not have any experience or special knowledge of it myself.

Boehm is conservative, unfortunately.

There was some consideration for a formal library based rust GC back in 2018 such that one could write GC<CyclicDataType> and get the benefits of a GC such as

- Not leaking memory - Not invoking unsafe - Not angering the rust compiler

None of those efforts stabilized to my knowledge, and the libraries developed for this task all have experimental/research tags associated to them.

For better or worse all the guides for using rust strongly encourage avoidance of primitive cyclic structures such as doubly linked lists, graphs, and other structures in favor of statically allocated fixed size variants. Like golang's preference for map/list as the only primitive structures, this is a constraint that one can get used to for most problems. But it doesn't feel great that as a language there are basic algorithms and datastructures that can't be idiomatically coded in the language.

There’s a new GC library released the other day https://blog.typingtheory.com/shredder-garbage-collection-as...

Still extremely new, of course, but has promise!

You can already use reference counting when needed. Pretty close to what you are envisioning.

Interoperability with other languages can be one reason, for example writing a library can can be reused in different languages. The sad truth is that exposing a C ABI is still the most widely adopted approach for that. And that is quite hard with many higher level languages, like Java/C#/Python/JavaScript etc.

> What is the exact aspect of "systems programming" that precludes the use of higher-level languages which are safe by default? Unless we are writing device drivers or OS kernels, why are we using these low-level languages for mission-critical applications?

IMHO "systems" here means running on an OS, not network systems or internet apps.

So None, but you want to write libraries that are easily linked to all manners of 3rd party languages and can squeeze the last drop of OS performance. Your language with automatic garbage collection cannot do that. If all you end up doing is wrapping stuff with C or C++ headers then better use C or C++ at first place.

The biggest problem is that nobody actually made a programming language with a GC that is worth using for system level programming. In theory nothing prevents the existence of such a language but it simply doesn't exist. For example, stop the world pauses are the primary reason why languages with a GC are unsuitable for systems programming. You can write one heavily optimized critical section that runs in real time and then be interrupted by some unrelated unoptimized low priority code that allocated memory and triggered a GC stop the world pause. Basically average performance in a GC language is dictated by the slowest performing section of the code base. A trivial model that avoids this problem would be a language where each thread has its own garbage collector. If a slow code path triggers a collection cycle it will not interrupt other threads. The second problem is that using a library written in a managed language requires initialization of the runtime. One could resolve this problem by switching away from C FFI to shared memory IPC where a separate process is running in the background.

It really sounds like what you are describing here is Nim. In fact, Nim even does per-thread heaps. It also implements a soft real-time garbage collector which for most use cases avoids GC pauses.

So I would say there is definitely at least one GC language that is worth using for systems level programming.

> I think it is also very hard to make a performance argument in 2020. Especially when you are comparing low level against something like the newest C#/.NET Core stack.

I agreed until this. I don't take anything not AOT compiled with an optimizing compiler as fast.

JITs may work well for numeric benchmarks with one tight loop, but there is extra memory and energy overhead.