4 ms·

Is it a good alternative to Go? How is interoperability?

by sgt 4y ago

hawski 4y ago
It is not an alternative to Go same as C++ or Rust is not really an alternative to Go. They are on a different level, but can do the same job. Though I could argue that Tcl could be an alternative to Go, I think many would not agree. Zig has manual memory management, doesn't have much of a runtime (no CSP out of the box) and above all is not mature yet (breaking changes do happen). As of now it has one of the best stories for interfacing with C as it can directly use C headers.
- rahen 4y ago
  I would be interested in hearing more about your point. TCL is an elegant scripting language, very LISP-y, where most data structures are lists of strings. Go on the other hand is more like a modern mix of C and Pascal with GC and lots of convenient libraries, and which builds statically. The performance of TCL and Go are also a world apart.
  - kaba0 4y ago
    Go is a worse Java 1.1. The only remotely interesting part is virtual threads.
    - sgt 4y ago
      Might as well use Java 19 then. Why not, really. Because Java is boring?
  - hawski 4y ago
    I am pulling a leg here a bit. I could risk a statement that Tcl could be an alternative when all you want is a simple CRUD backend. Now performance considerations are valid, but in some applications Tcl could be fast enough. Both languages, or maybe we could say platforms, have manged runtimes and maybe that's were similarities end.
    - blacksqr 4y ago
      Tcl is good for both CRUD and REST; for example, the sqlite.org web site uses a pure Tcl web server, through which you can access sqlite's SCM app which is backed by a SQLite database.
      - dmux 4y ago
        I was under the impression that the sqlite.org website used Dr. Richard Hipp's "althttpd" (written in C): https://sqlite.org/althttpd/doc/trunk/althttpd.md https://sqlite.org/althttpd/doc/trunk/althttpd.md
- drogus 4y ago
  I'm hearing this so often that I think I have to write a blog post some day. I think both Zig and Rust can be an alternative to Go. Zig is still young, so it probably lacks tools for many domains, but if it grows I expect it to get more tooling similarly to what's happening for Rust. So just talking for Rust today, it's used in: - gaming - web apps - networking - CLIs - distributed systems - crypto - systems programming (like for example databases) - language tooling (for example JS ecosystem has a lot of Rust based tools being developed right now) and probably much more. Go is used for every single of these categories too. Databases? Check. Networking? Check. CLIs? Check. And so on, and so on. The truth is that it's often a matter of taste, timing and various constraints that are often non technical at all. Taste is the most subjective reason, nevertheless it's often a driving choice. If I start a new personal project I usually default to Rust these days, unless it's a bad fit, but I've successfully used Rust in many different domains, so it's safe to say Rust covers most of my programming needs (other than maybe a quick throwaway script). Even if Go was a sligtly better fit, I would choose Rust anyway, cause I just enjoy it more. When it comes to constraints, I think that is most often relevant in a professional setting. I've worked in many different companies and very rarely, especially when a company is on the bigger side, you can just choose whatever tools you want just based on technical requirements. If a company is a Ruby shop, they will have to have a very strong reason to start a new project in a different language, even if it is clearly a better choice. But then a good question is: what makes a tool a better choice? It will very often be really hard to tell until you actually do the project. Have you ever been in a discussion about choosing a new language for a project? I have been, lots of times. One time was especially interesting, cause we were discussing what to use for a real time application keeping a long running websocket connections. We were considering Ruby (it was a Ruby shop), Go, Elixir and Rust. We chose Rust in the end, but I'm sure that we could have been successful with Elixir or Go too. The most interesting part? There was an experienced developer that was pushing for Ruby hard. He was working as a "Principal Engineer" and if it was up to him I'm sure he would have chosen Ruby, which for me was the least feasible choice. Would it be a good choice? I don't think so, but I can't say for certain and we will probably never know. So as you can see, even with very clear requirements people will disagree on "the best tool for the job" (which is also why I hate this term). But even if everyone agrees on a technical aspect, there might be also other constraints. If a company is growing very fast they might be worried about hiring for example. And they may choose a language that is technically a bit worse than some alternatives, but has a bigger talent pool. Timing is a tricky one, cause at the moment both languages are quite mature, but if you think about it, a lot of well known big projects in Go (k8s, docker, terraform etc) were started when Rust was honestly quite rough. So while I'm not saying if k8s was started today, it would be definitely started in Rust, I think that at least some of those projects might consider Rust. The same goes for companies that are invested in Go already. Even if Rust made sense for some of the new projects they would probably lean heavily towards Go, cause of a collective company experience. So, yes, Rust is an alternative to Go in many (most?) domains. In the same way Zig can be in this place too when it gets more tooling and maturity.
flohofwoe 4y ago
The Zig compiler is also a (clang compatible) C/C++/ObjC compiler, the Zig toolchain comes with C and C++ runtime headers and libraries, C headers (but not C++ or ObjC headers) can be directly imported into Zig code. Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Whether it's going to become a good alternative for Go will depend mainly on the stdlib I think. What's clear is that the Zig stdlib will be much richer than C's or C++'s, but whether it will be a good match for Go's stdlib for backend work remains to be seen.
- aserafini 4y ago
  I expect the stdlib will not be quite as tailored for general backend work as Go’s, but I envisage we’ll ultimately see a rich and vibrant package ecosystem with all those bases covered.
- TUSF 4y ago
  > Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Go lets you write C in your Go files, and reference it with a psuedo-package, "C". So you can import C headers, but Go itself doesn't come with a C compiler toolchain, and ends up relying on your system's C compiler, and thus you lose Go's cross-compilation, unless you have the headers for your target platform. I've seen some have been using "zig cc" as their C compiler with Go, given it makes cross-compilation easy.
fbouvier 4y ago
Coming from a Go background I found it quite easy to use Zig, as the language is small and you can be proficient in few days. Of course you have more to handle by yourself in Zig. For example a simple string concatenation will need more work as there is no implicit heap allocation. For interoperability with Go it's quite the same than C<>Go through Cgo: doable but not ideal. However the Zig toolchain can be used to improve the build system of Go projects with Cgo dependancies. That's what Uber is doing https://jakstys.lt/2022/how-uber-uses-zig/ https://jakstys.lt/2022/how-uber-uses-zig/

Is it a good alternative to Go? How is interoperability?

by sgt 4y ago

Is it a good alternative to Go? How is interoperability?

It is not an alternative to Go same as C++ or Rust is not really an alternative to Go. They are on a different level, but can do the same job. Though I could argue that Tcl could be an alternative to Go, I think many would not agree. Zig has manual memory management, doesn't have much of a runtime (no CSP out of the box) and above all is not mature yet (breaking changes do happen). As of now it has one of the best stories for interfacing with C as it can directly use C headers.

rahen 4y ago
I would be interested in hearing more about your point. TCL is an elegant scripting language, very LISP-y, where most data structures are lists of strings. Go on the other hand is more like a modern mix of C and Pascal with GC and lots of convenient libraries, and which builds statically. The performance of TCL and Go are also a world apart.
- kaba0 4y ago
  Go is a worse Java 1.1. The only remotely interesting part is virtual threads.
  - sgt 4y ago
    Might as well use Java 19 then. Why not, really. Because Java is boring?
- hawski 4y ago
  I am pulling a leg here a bit. I could risk a statement that Tcl could be an alternative when all you want is a simple CRUD backend. Now performance considerations are valid, but in some applications Tcl could be fast enough. Both languages, or maybe we could say platforms, have manged runtimes and maybe that's were similarities end.
  - blacksqr 4y ago
    Tcl is good for both CRUD and REST; for example, the sqlite.org web site uses a pure Tcl web server, through which you can access sqlite's SCM app which is backed by a SQLite database.
    - dmux 4y ago
      I was under the impression that the sqlite.org website used Dr. Richard Hipp's "althttpd" (written in C): https://sqlite.org/althttpd/doc/trunk/althttpd.md https://sqlite.org/althttpd/doc/trunk/althttpd.md
drogus 4y ago
I'm hearing this so often that I think I have to write a blog post some day. I think both Zig and Rust can be an alternative to Go. Zig is still young, so it probably lacks tools for many domains, but if it grows I expect it to get more tooling similarly to what's happening for Rust. So just talking for Rust today, it's used in: - gaming - web apps - networking - CLIs - distributed systems - crypto - systems programming (like for example databases) - language tooling (for example JS ecosystem has a lot of Rust based tools being developed right now) and probably much more. Go is used for every single of these categories too. Databases? Check. Networking? Check. CLIs? Check. And so on, and so on. The truth is that it's often a matter of taste, timing and various constraints that are often non technical at all. Taste is the most subjective reason, nevertheless it's often a driving choice. If I start a new personal project I usually default to Rust these days, unless it's a bad fit, but I've successfully used Rust in many different domains, so it's safe to say Rust covers most of my programming needs (other than maybe a quick throwaway script). Even if Go was a sligtly better fit, I would choose Rust anyway, cause I just enjoy it more. When it comes to constraints, I think that is most often relevant in a professional setting. I've worked in many different companies and very rarely, especially when a company is on the bigger side, you can just choose whatever tools you want just based on technical requirements. If a company is a Ruby shop, they will have to have a very strong reason to start a new project in a different language, even if it is clearly a better choice. But then a good question is: what makes a tool a better choice? It will very often be really hard to tell until you actually do the project. Have you ever been in a discussion about choosing a new language for a project? I have been, lots of times. One time was especially interesting, cause we were discussing what to use for a real time application keeping a long running websocket connections. We were considering Ruby (it was a Ruby shop), Go, Elixir and Rust. We chose Rust in the end, but I'm sure that we could have been successful with Elixir or Go too. The most interesting part? There was an experienced developer that was pushing for Ruby hard. He was working as a "Principal Engineer" and if it was up to him I'm sure he would have chosen Ruby, which for me was the least feasible choice. Would it be a good choice? I don't think so, but I can't say for certain and we will probably never know. So as you can see, even with very clear requirements people will disagree on "the best tool for the job" (which is also why I hate this term). But even if everyone agrees on a technical aspect, there might be also other constraints. If a company is growing very fast they might be worried about hiring for example. And they may choose a language that is technically a bit worse than some alternatives, but has a bigger talent pool. Timing is a tricky one, cause at the moment both languages are quite mature, but if you think about it, a lot of well known big projects in Go (k8s, docker, terraform etc) were started when Rust was honestly quite rough. So while I'm not saying if k8s was started today, it would be definitely started in Rust, I think that at least some of those projects might consider Rust. The same goes for companies that are invested in Go already. Even if Rust made sense for some of the new projects they would probably lean heavily towards Go, cause of a collective company experience. So, yes, Rust is an alternative to Go in many (most?) domains. In the same way Zig can be in this place too when it gets more tooling and maturity.

flohofwoe 4y ago

The Zig compiler is also a (clang compatible) C/C++/ObjC compiler, the Zig toolchain comes with C and C++ runtime headers and libraries, C headers (but not C++ or ObjC headers) can be directly imported into Zig code. Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Whether it's going to become a good alternative for Go will depend mainly on the stdlib I think. What's clear is that the Zig stdlib will be much richer than C's or C++'s, but whether it will be a good match for Go's stdlib for backend work remains to be seen.

aserafini 4y ago
I expect the stdlib will not be quite as tailored for general backend work as Go’s, but I envisage we’ll ultimately see a rich and vibrant package ecosystem with all those bases covered.
TUSF 4y ago
> Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Go lets you write C in your Go files, and reference it with a psuedo-package, "C". So you can import C headers, but Go itself doesn't come with a C compiler toolchain, and ends up relying on your system's C compiler, and thus you lose Go's cross-compilation, unless you have the headers for your target platform. I've seen some have been using "zig cc" as their C compiler with Go, given it makes cross-compilation easy.

fbouvier 4y ago

Coming from a Go background I found it quite easy to use Zig, as the language is small and you can be proficient in few days. Of course you have more to handle by yourself in Zig. For example a simple string concatenation will need more work as there is no implicit heap allocation. For interoperability with Go it's quite the same than C<>Go through Cgo: doable but not ideal. However the Zig toolchain can be used to improve the build system of Go projects with Cgo dependancies. That's what Uber is doing https://jakstys.lt/2022/how-uber-uses-zig/ https://jakstys.lt/2022/how-uber-uses-zig/