News for hackers. Stuff that matters.
Re:Baby Steps: Slowly Porting Musl to Rust by pjmlp on Monday June 13, 2016 @04:14AM (#11892320)
Still, isn't ironic that a systems programming language isn't able to be used without C, because its runtime was made to rely on libc instead of the raw OS APIs?

I understand the shortcut as a way to reduce development time, but maybe that is something to improve.

Go made the right decision by integrating directly with the OS APIs.

Re:Baby Steps: Slowly Porting Musl to Rust by claudius on Monday June 13, 2016 @04:48AM (#11892448)
> rely on libc instead of the raw OS APIs?

The argument here is that on Windows and Mac OS X, the libc library is the ‘raw OS API’ and it hence makes perfect sense to rely on it if you want to support such operating systems.

Re:Baby Steps: Slowly Porting Musl to Rust by bjourne on Monday June 13, 2016 @10:35PM (#11899392)
On Windows it isn't. Microsoft has made it clear that you aren't supposed to link to the msvcrt.dlls shipped in Windows. See https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20again...
Re:Baby Steps: Slowly Porting Musl to Rust by pjmlp on Monday June 13, 2016 @05:37AM (#11892614)
If I want to zero memory on Windows without libc dependencies, I use ZeroMemory() or FillMemory() and not memset().

No need to have any dependency on msvcr*.dll or the equivalent for Borland, Intel and other Windows compilers, which are effectively the Windows libc.

Re:Baby Steps: Slowly Porting Musl to Rust by choosername on Monday June 13, 2016 @07:23AM (#11892923)
there is a baremetal rust os that avoids libc. I think it achieves this by avoiding the rust standard library.