Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The state of low-level system programming

erik-poupaert.blogspot.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: The state of low-level system programming

#11

Post by smosher »

jzwinck wrote: post #9
bluehex wrote: post #5

Earlier quoted context omitted.

True, and so can C call back into go code with cgo. The problem is that it still requires that the main function be in a Rust/Go binary. A program written in C can't currently call into a library written in one of these two languages since the runtimes don't work unless they control the main entry point. From the Rust doc linked: "The primary motivation of extern functions is to create callbacks for foreign functions…

Then is it even possible to make a program that can use libraries written in Rust and Go and C++? If everyone wants to control main(), is there an escape hatch provided by any of these languages, like a C function that can be explicitly invoked near program start?

You can do this with C++ already. Rust's plan seems to be to eliminate or reduce its runtime and give up the entry point. Go doesn't appear to have a plan.

Re: The state of low-level system programming

#12

Post by keypusher »

zanny wrote: post #8

Compatability with the C ABI I feel isn't a necesssity. On platforms built on C it is, but if you wanted to invent a new machine running a new system language with the ABI messes of C exonerated, you could. You would need to devise a translation layer in the OS executor to be able to interpret classic C ABI .so or .dll files for legacy applications and so you could compile C on these platforms, but that isn't a prohi…

Doesn't almost all systems programming take place on platforms built on C? If creating a new machine and new language, convincing the existing systems programmers to move is going to take something very compelling.

Re: The state of low-level system programming

#13

Post by qxcv »

gmt2027 wrote: post #10

Vala does not seem to get much attention. It borrows C# syntax (and maybe Java), compiles down to C and offers nearly symmetrical interoperability as a result. I believe Ubuntu's Unity is written in Vala. Knowing Java, it was easy to acquire the syntax from the tutorial [ https://live.gnome.org/Vala/Tutorial ] in very little time. For transparent access to compiled C libraries, external C functions need to be declare…

If it has GObject as a dependency, then it's not designed for "low-level systems programming". Hell, just having a GC more-or-less discounts it due to the associated problems with runtime size and performance[0]. As a general rule of thumb: if you can't write a kernel in it, it's not a systems language.

[0] It is possible to write a systems language with these features, but low-level systems stuff is not what Vala was designed for.

Re: The state of low-level system programming

#14

Post by justincormack »

The C ABI is not great for interacting with scripting languages though, even if it is the best we have right now. For a start there is no type information obtained with dlsym and you basically have to parse headers the interpretation of which is not clearly defined as the C language really defines an API and the ABI is defined by the compiler. Many libraries for this reason do not define stable ABIs and are a pain to use from a scripting language. Hence Python has two ffi modes an ABI interface and a compiler mode.

Now if someone produced a better solution to that it would be useful...

Re: The state of low-level system programming

#15

Post by davidw »

keypusher wrote: post #12
zanny wrote: post #8

Compatability with the C ABI I feel isn't a necesssity. On platforms built on C it is, but if you wanted to invent a new machine running a new system language with the ABI messes of C exonerated, you could. You would need to devise a translation layer in the OS executor to be able to interpret classic C ABI .so or .dll files for legacy applications and so you could compile C on these platforms, but that isn't a prohi…

Doesn't almost all systems programming take place on platforms built on C? If creating a new machine and new language, convincing the existing systems programmers to move is going to take something very compelling.

Historically, the "turtles all the way down" approach has not been very successful outside of niches. Lisp, Forth, Java have all been used for OS's that never seemed to go anywhere.

Re: The state of low-level system programming

#16

Post by Symmetry »

davidw wrote: post #15
keypusher wrote: post #12

Earlier quoted context omitted.

Doesn't almost all systems programming take place on platforms built on C? If creating a new machine and new language, convincing the existing systems programmers to move is going to take something very compelling.

Historically, the "turtles all the way down" approach has not been very successful outside of niches. Lisp, Forth, Java have all been used for OS's that never seemed to go anywhere.

I've always wondered about the possibility of creating a stack system, application, and scripting language all designed to work together though.

Re: The state of low-level system programming

#17

Post by tehwalrus »

I asked a very relevant question on stackoverflow about this recently: "Writing a Python extension in Go" http://stackoverflow.com/questions/12443203/writing-a-python...

Now technically you can compile a special python which can handle Go extensions, which is the wrapper mentioned in the second answer, but you can't distribute python modules that ask people to install "this special python" to run (which will reliably work with all their other installed code..)

I would like to see a "go init" function in a C API, that would let you interop the two whichever had the `main()`, since that would let you link with all the other c-implemented scripting languages (python, ruby, etc) which would mean that Go extension support could be added to the main cpython trunk as a compile-time option.

Re: The state of low-level system programming

#19

Post by damian2000 »

If programmers wanted a statically-typed, compiled system language for their scripting efforts, they would be using the existing system languages for that already.

I think Go has been fairly successful at Google in terms of improved code maintainability, and as an alternative to not just C but C++.

Re: The state of low-level system programming

#20

Post by sparkie »

zanny wrote: post #8

Compatability with the C ABI I feel isn't a necesssity. On platforms built on C it is, but if you wanted to invent a new machine running a new system language with the ABI messes of C exonerated, you could. You would need to devise a translation layer in the OS executor to be able to interpret classic C ABI .so or .dll files for legacy applications and so you could compile C on these platforms, but that isn't a prohi…

The need for C isn't so much restricted by the operating system, but by the hardware manufacturers. The simple fact is that C is the defacto choice of language for hardware vendors to ship a compiler for, and that doesn't look to change any time. It's a standard that can't be avoided, unless we can work cooperatively with enough major vendors to change this.
Post reply on HN