What's Zig got that C, Rust and Go don't have? [video] | Hacker News Reader

What's Zig got that C, Rust and Go don't have? [video]

youtube.com

33 pointskristoff_it22 comments

I wouldn’t normally post video content featuring myself but this video was particularly well received.

Since it was published, people pointed out two mistakes I made:

1. Go has been able for a while now to export dynamic libraries. My knowledge was from before that time and I also got confused, thinking that you could not export C ABI functions at all, while in fact you can. That said, having a runtime still makes Go not a viable C replacement in the most direct sense of the expression.

2. Zig used to only support pointer arithmetic by converting the pointer to an int, applying the operation, and then converting it back to a pointer. Since a few months ago, `[*]T` (and related) started supporting arithmetic. That’s a pointer type that you don’t touch directly often, as you normally would use a slice (ptr + len).

Why is Go included in the comparison, and not, say JS, OCaml, Haskell? It makes zero sense, and I swear that’s some marketing tactic for that language to sell itself.

I think it's fair. Go and Rust are both new, viable backend languages with a ton of traction.

JS is not a serious contender in the space. OCaml and Haskell fit better, but with a much different language paradigm.

Go has a fat runtime and GC, which is absolutely not a bad thing, that’s not my point, but Rust and Zig are in their niche, because they are low-level programming languages. That’s their unique trait. You can’t just call into go from the kernel, but you could do it for the other two languages.

Also, rust is not a backend language, it can be used for that, but that’s definitely not its main appeal.

Not only you can fit Go into a kernel, there is at least two products that do so.

TamaGo, used to write the firmware used in USB armory.

https://www.withsecure.com/en/solutions/innovative-security-...

TinyGo, which even has official Arduino and ARM support, and is sponsored by Google

https://tinygo.org/

Ah but that isn't proper Go.

Well neither is the C code that is allowed to be used in typical kernel code, almost nothing from ISO C standard library is available, and usually plenty of compiler specific language extensions are used instead.

So can Java, Javascript, there is nothing fundamentally new here. As I said, I’m all for managed languages, and I believe they should be the default choice, only seldom “overwritten” by going lower level in very specific circumstances. Nonetheless, Rust is an interesting, novel language for this very reason - it is memory safe without having a GC.

You are the one who always mention stuff like gcj - how is that, available at Java 1.2 times, any different than Go, in a fundamental way?

I seldom mention gcj, it was half baked, only supported Red-Hat's case of AOT compiling Eclipse and little else, it was abandoned in 2009.

What I quote are production quality compilers for embeeded space like ExcelsiorJET (also creators of Modula-2 and Oberon compilers, now out of business), PTC, Aonix (acquired by PTC), Aicas, WebSphere Real Time (AOT technology nowadays lives on OpenJ9), and microEJ.

As for the differences they aren't, that is the point, we should open our minds to use managed systems programming languages, like Xerox PARC, ETHZ and Microsoft Research did.

Rust is interesting in being the language that brought affine types into mainstream, although with a productivity cost.

As shown by Haskell, OCaml, Swift, Chapel, D, Roc, Hylo (nee Val) efforts, the best is being able to combine automatic memory management with linear/affine types for a low level language subset, with the benefit of not having to type ".clone()" all over the place.

As for Go versus Rust, definitly Rust, only because I am not a big fan of Go's language design, and love ML derived languages since Caml Light, nevertheless better Go than C.

We agree here on everything, I just find it dishonest to put Go next to Rust all the time, and not all the millions of managed languages that compile AOT, like you list quite a few. Go is not any lower level than they are, it is just catering to the kind of people that will believe it is somehow a “modern C”.

From the point of view of Limbo's role in Inferno, it kind of is, even if only for the userspace side.

Which ironically, the closest we got there in modern computing, in tortuous ways, is Android.

I mean, it's not an exhaustive comparison from Zig to every language. To understand where Zig is in the language space, you only need a few points of reference to triangulate from. The choice of which points to use is presumably a balance between what the presenter was familiar with or had a preference for, and what they believed the audience would be familiar with or have a preference for.

I don't think it's likely that a presentation about Zig is stealth marketing for Go. It seems more likely that the presenter, say, didn't think as many people in the audience would be familiar with Haskell, or maybe doesn't personally care for JavaScript.

> I don't think it's likely that a presentation about Zig is stealth marketing for Go

It’s obviously not coming from the presenter, but it is waay too common to see Rust and Go in the same sentence, when it is just dumb in most contexts.

I think you might have some nontraditional views here. Eg you say that Go isn't a low level and that Rust isn't a backend language - these are poorly defined terms and subjective judgment calls, so I'm not going to tell you you're wrong, but I will say that I and many others would regard Go as being low level, Rust as being a backend language (not to the exclusion of using it other places), and both languages as being peers you might weigh the benefits of on the same project.

Which is all to say, comparing Go to Rust makes a lot of sense to me.

They are poorly defined words, but they still have some sane usage.

How many production systems use Rust as their backends? Sure, it has 3 half-baked frameworks going on for it, but it is nothing like Spring, asp.net, python’s django, RoR, etc feature wise. It is as much a backend language as haskell is, hell, I’m quite sure there are much more haskell backends buzzing somewhere, than do rust ones, and even that is insignificant.

If Go is a low-level language, is OCaml, Haskell, C# and Java also that? They all are (or have ways to) AOT-compiled to a single binary that contains their runtime as well, there are zero differences to Go. Hell, all of them have arbitrary pointer manipulation as well, even if it doesn’t have specific syntax in every case, but it is a special library call. So there is an objective distinction in how Rust or Zig fundamentally operates compared to these.

Unix system programming in OCaml (2014)

https://ocaml.github.io/ocamlunix/

"MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms."

https://mirage.io/

"Docker Desktop avoids this problem by forwarding all traffic at user-level via vpnkit, a TCP/IP stack written in OCaml on top of the network protocol libraries of the MirageOS Unikernel project. The following diagram shows the flow of packets from the helper VM, through vpnkit and to the Internet:"

https://www.docker.com/blog/how-docker-desktop-networking-wo...

I'm not going to try and talk you out of your position, it's clearly an informed and considered one and I don't think you're wrong, but the answer to your question "why do people keep comparing these languages, and is it stealth marketing for Go?" is "no, it's not stealth marketing, other people just think about these things slightly differently and it makes more sense from that perspective."

Just to reiterate, I'm saying your views aren't the consensus, but I genuinely don't mean that as a criticism and do think you have a point.

You can’t practically write a kernel in Go. Or the entirety of its own runtime.

Likewise for ISO C.

"In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an WithSecure Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors."

https://www.withsecure.com/en/solutions/innovative-security-...

I’m unsure who you think is using subterfuge here? The interviewer or the interviewee?

For instance the three languages listed in the title were organically brought up when discussing zigs cross compilation features (~14m into the video) because it still manages its cross compilation even for cgo and rust with c or c++ ffi.

Go was originally marketed as a convenient alternative to C. There was even planned support for a freestanding backend which never materialized, unfortunately. There were discussions at the time on using it to write OSes, bootloaders, and such.

Perhaps OP remembers this like I do?

I'm aware that Go has more-or-less become a language for writing webapps, but once upon a time the team had loftier goals.

I abandoned pursuing the language when these plans were dropped. My interest in working on anything web-related died around 2003 or so.

It's not OP only, it's freakin' everyone. If it would be a one-off occurrence I wouldn't have bothered writing a comment about it.

Go is always compared to Rust for some godforsaken reason.

Go was never meant to be a low-level language. It was called a systems language in that sense that system management software was written with it, rather than say operating systems and the like. It was to be a more tractable language than C/C++ for the many devs at Google.

> Go was never meant to be a low-level language.

I didn't make this claim.¹

With that being said, high(er)-levels languages can be used for OS development and the like. There's considerable work in providing the underpinnings necessary for the abstractions, but it's doable and has been done.

There are plenty of archived discussions from the nascent-Go days on this topic. Using Go in the places C is used was discussed and, given that a directory named "freestanding" exists in the source tree from that time, I'm inclined to believe it was seriously considered.

[1] Also, FWIW, C is not a low-level language. As with any other systems language, a generous amount of work has to be done in order to make its abstractions map to the computer architecture. A macro assembler is a low-level language.

Reply on news.ycombinator.com