The state of low-level system programming • Hacker News Board

Re: The state of low-level system programming

#31

Post by bluehex » Sun, Dec 23, 2012, 3:22 PM UTC

pretoriusB wrote: post #24

> The Go language and the Rust language. What they have in common, though, is that both Go and Rust are entirely incapable of walking like a duck. Since you cannot call Rust -or Go code from a scripting engine, they are inadvertently positioning themselves as alternatives to the scripting engines themselves. Before writing all these BS, maybe he should do a little research first? Here's Rust (which is not even releas…

> Before writing all these BS, maybe he should do a little research first?

There's a subtle difference between being able to call back into Go/Rust code from C (where the main function is in Go/Rust) which both languages allow now, and allowing a call to originate from a C program, which neither currently do. The author is talking about the later.

I would agree the article could go into more detail about what's currently possible, and why it's not enough. But calling BS, I think, is going a bit too far.

Re: The state of low-level system programming

#32

Post by MatthewPhillips » Sun, Dec 23, 2012, 3:23 PM UTC

groovy2shoes wrote: post #28

Clay[1] doesn't get as much attention as it deserves. The authors seem well-versed in programming language theory, but they also understand the practical needs of a systems language. What you end up with is a language that's sufficiently low-level to be a C replacement, but it offers a plethora of mechanisms for abstraction. Of all the new languages billed as "systems languages", Clay is the only one that excites me.…

I can't find any kind of getting started guide, and most of the libs have no documentation at all.

Re: The state of low-level system programming

#33

Post by pretoriusB » Sun, Dec 23, 2012, 3:49 PM UTC

bluehex wrote: post #31

pretoriusB wrote: post #24

> The Go language and the Rust language. What they have in common, though, is that both Go and Rust are entirely incapable of walking like a duck. Since you cannot call Rust -or Go code from a scripting engine, they are inadvertently positioning themselves as alternatives to the scripting engines themselves. Before writing all these BS, maybe he should do a little research first? Here's Rust (which is not even releas…

> Before writing all these BS, maybe he should do a little research first? There's a subtle difference between being able to call back into Go/Rust code from C (where the main function is in Go/Rust) which both languages allow now, and allowing a call to originate from a C program, which neither currently do. The author is talking about the later. I would agree the article could go into more detail about what's curre…

>and allowing a call to originate from a C program, which neither currently do.

That one is also under consideration by the Rust developers.

Re: The state of low-level system programming

#34

Post by pretoriusB » Sun, Dec 23, 2012, 3:51 PM UTC

MatthewPhillips wrote: post #30

So what's the catch when it comes to D? If I can use all C libs easily, and get some more palpable syntax, what am I missing exactly and why haven't people transitioned to it?

The article is not about using C libs, is about C programs using you (your D code, that is).

That said, the problem with D: not enough marketing plus the two compilers / 2 libraries issue.

And it's close to C++ complexity enough to not let the scripting guys feel welcome (like they do in Go).

Re: The state of low-level system programming

#35

Post by PuerkitoBio » Sun, Dec 23, 2012, 4:03 PM UTC

bluehex wrote: post #2

I really hope to see Go and Rust move in the direction of pluggable runtimes that can be embedded into a C host program. Currently, both runtimes require being seated as the main entry-point of the program to function. Both projects also have issues in their bug trackers to rectify this: Rust issue: https://github.com/mozilla/rust/issues/3608 Go issue: http://code.google.com/p/go/issues/detail?id=2790 I wonder who wi…

Also, a way to compile without kernel (system) calls, so that it can be use for kernel development. It used to be possible with go, but no more with go1. Then these languages would truly be able to replace C.

Re: The state of low-level system programming

#36

Post by frujka » Sun, Dec 23, 2012, 4:07 PM UTC

it's probably an interesting read except that being hosted on google's blogspot means it only display blank pages due to content being embedded in some javascript shenanigans.

Even a screenshot would be better than this.

Please move on to some actual html website that just works or rehost the content elsewhere before posting it here. Thanks.

Re: The state of low-level system programming

#37

Post by sparkie » Sun, Dec 23, 2012, 4:19 PM UTC

TheCondor wrote: post #22

sparkie wrote: post #20

Earlier quoted context omitted.

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.

There is C specific hardware?!? This is a myth and part of the vicious circle here. I'm not a C hater by any means but the reason hardware vendors have historically included it is because there are free compilers that are nearly C enough that they can include and they have to include something. C is just a portable assembly, you can almost write a simplistic compiler in pure yacc and more than a couple of these C com…

I wasn't implying that there's C specific hardware, or that there's any technical restriction for shipping a C compiler with a chip. You're just reiterating my point about it being crowd effect.

Also, when talking about systems programming, we can't just limit our scope to linux - there's hundreds of other kernel projects, and embedded systems which don't have the luxury of a massive portable codebase already - they only have a basic C compiler, library, debugger.

Using a different language doesn't eliminate C, because chances are, the compiler you're using for that language has been written in C, because it's all the manufacturer supplied. Compiler vendors contribute to this cycle by expecting their compiler to run on any platform if they write it in C.

I was suggesting that if we want to liberate ourselves from C, we need the hardware vendors on board too - since they're where the cycle begins.

Of course, you don't need the vendor specific compiler if you have a cross compiler, and can build a different language compiler from another platform - however, if you look at what's available for doing that, there's nothing other than GCC - which is why new languages are unlikely to replace C as the defacto systems language, unless they can replicate that functionality.

Re: The state of low-level system programming

#38

Post by dschiptsov » Sun, Dec 23, 2012, 4:39 PM UTC

This is called FFI.)

And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language.

NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.)

But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specification and then push your bloatware - JDBC.

Re: The state of low-level system programming

#39

Post by eropple » Sun, Dec 23, 2012, 4:48 PM UTC

frujka wrote: post #36

it's probably an interesting read except that being hosted on google's blogspot means it only display blank pages due to content being embedded in some javascript shenanigans. Even a screenshot would be better than this. Please move on to some actual html website that just works or rehost the content elsewhere before posting it here. Thanks.

I used to be one of These Guys who never used JavaScript, too, but honestly? It's 2012 and JavaScript is a thing pretty much everywhere worth targeting. Demanding that somebody cater to your microsegment is a little much.

Re: The state of low-level system programming

#40

Post by pjscott » Sun, Dec 23, 2012, 5:21 PM UTC

dschiptsov wrote: post #38

This is called FFI.) And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language. NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.) But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specificati…

I believe his thesis was actually that most languages are handicapped because they can not easily be called via the usual "load a .so file and call a function" ABI. Java, for instance, would be a more useful language to me if I could easily create Python bindings for useful Java libraries like Lucene, without needing to use something like Jython that runs on the JVM.