8 ms·
I played with Go a bit and I like the idea of Go replacing C/C++ to write *NIX tools (no, not the GUI ones, the command-line ones, the daemons, the utilities, t
by edwinnathaniel 12y ago
I played with Go a bit and I like the idea of Go replacing C/C++ to write *NIX tools (no, not the GUI ones, the command-line ones, the daemons, the utilities, the server/collectors).
- Animats 12y agoIt would be a big step forward to have everything that runs as root written in something safer than C/C++. (Screams come from the Old UNIX Admins.)
- tene 12y agoThe biggest stumbling block there, for me, is that it's impossible to write shared libraries in go. You can't write libraries in go that can be used from anything other than go, so until you've converted everything over to go, you'll still need to write libssl.so and friends in C. Go is a great application language, but it doesn't play well enough with others to really be a systems language as long as you can't write libraries other languages can use in it.
- jzelinskie 12y agoWhile totally unsuited for the aforementioned hypothetical situation, Go has also supported SWIG for a few years now.
- colin_mccabe 12y agoShared libraries are coming for Go. https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.
- tene 12y agoThere are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.
- marcus_holmes 12y agoI moved from C# to Go, and one of the things I really loved is the sudden absence of DLL-Hell. I never have to worry that installing my program on another machine would suddenly cause it to bork. I guess I'm happy importing everything into monster huge static binaries and not worrying :)
- johnny_reilly 12y agoMarcus, I'm also giving Go a try at the moment (C# is my day job). What are you using tooling-wise? I'm trying out Lite IDE at the moment and that's the best experience I've had yet. So far my view is that I really like the language but I'm finding the tooling pretty unappealing. Wonder if I'm missing a trick?
- okatsu 12y agoI find that Sublime Text with the GoSublime plugin works pretty well. There's "Intellisense" for imported packages and GsLint actively detects syntax errors. Gofmt also takes care of indentation and formatting for you at every save.
- bkeroack 12y ago++ to Sublime Text and GoSublime. It's what I use and anecdotally appears to be the most popular Go dev environment.
- codexon 12y agoAnd because everything is statically compiled, go binaries tend to be very large. Imagine each binary being 5 mb on average and multiply that by 100.
- slimsag 12y ago> And because everything is statically compiled, go binaries tend to be very large. Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? > Imagine each binary being 5 mb on average and multiply that by 100. I don't think it's a factor of 100 times, that seems a bit outrageous.
- rurounijones 12y ago>> Imagine each binary being 5 mb on average and multiply that by 100. > I don't think it's a factor of 100 times, that seems a bit outrageous. I think he means 100 utilities all weighing in at 5mb
- masklinn 12y ago> Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? Removing DWARF information with -ldflags -w reduces the size of the binary by 20%. The binary is 1.8MB originally... $ go build hello.go $ wc -c hello 1806192 hello $ go build -ldflags -w hello.go $ wc -c hello 1408880 hello the rest is pretty much all runtime, the hello world itself should take about 10k, that's more or less the size of the C or dynamically linked Rust versions (Rust also uses static linking by default, and the hello world is 300k in that case)
- f2f 12y agoto see how much the runtime contributes to the size of the binary use an empty main. for hello world you bring in the fmt package which is a relative heavyweight: $ cat > t.go package main func main() {} $ go build t.go $ wc -c t 623280 t $ nm t | wc -l 1029 $ cat > t.go package main import "fmt" func main() { fmt.Println("hello world") } $ go build t.go $ nm t | wc -l 2541
- pjmlp 12y agoThat is a toolchain limitation, not the language. I think gccgo allows for .so. And the work for Android is adding .so support to the main toolchain.
- codygman 12y agoYou could write those command line libraries/etc in Ocaml now ;)
- Animats 12y agoAre shared libraries a memory win in production environments? For shared libraries to be a win, you have to be running different executables on the same machine (or VM) which share libraries of significant size relative to the memory use of the program itself. You also have to be using a big fraction of each shared library. With static linking, if you need "cos", you get that loaded; with a shared library, you bring in the entire math library. Modern production environments often involve only one program per VM, or multiple instances of the same program. In such cases, shared libraries are a lose.
- luckystarr 12y agoYou mean something like Perl Power Tools from the late 90s? https://metacpan.org/release/ppt https://metacpan.org/release/ppt :)
- pjmlp 12y ago> It would be a big step forward to have everything that runs as root written in something safer than C/C++. As you know, options have existing since the early days, but mentalities are hard to change. I came to the conclusion that many issues in computing are only solved with change of generations.
- waxjar 12y agoOnce Rust is stable, it would be really cool to see these rewritten in Rust.
- untothebreach 12y agoNo need to wait! :) https://github.com/uutils/coreutils https://github.com/uutils/coreutils
- vezzy-fnord 12y agoThere's still findutils, inetutils, binutils and other collections part of the GNU base system, though. The core daemons are all separate projects, as well.
- StevePerkins 12y agoBy the time Rust is stable, there will be something cooler. And so on, and so on...
- Arnor 12y agoWhy wait for rust to be stable for something cooler? Haskell is already here :)
- YakovYakov 12y agoWhen will it be that Rust is stable? Many moon ago I was of the told that December of 2014 would be the calendar date of the Rust stable version. Yet December is now and I see no Rust stable version. When come it? When?
- steveklabnik 12y agoRelease candidate around the end of the year. See http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html and http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html for more details.
- zak_mc_kracken 12y agoGo is never going to make much inroad in that area until it supports shared libraries, and its creators seem to be strongly opposed to that idea (while claiming their goal is to replace C++...).
- niemeyer 12y agoThere are many different aspects to shared object support, there is support to some of these aspects today (you can link against shared libraries, for example), and there are on going conversations about supporting other models. This is a recent thread on the subject: https://groups.google.com/d/msg/golang-dev/0_N7DLmrUFA/qGRb876_3XMJ https://groups.google.com/d/msg/golang-dev/0_N7DLmrUFA/qGRb8...