Go is not a system programing language... Rust is

[Bill Cox]

This is my biggest concern for Go.  The overhead of Go's runtime has to be tiny.  Why can't we upgrade the tool flow a bit and start creating C-linkable Go libraries that all the rest of the system can use?  I should be able to write Chrome, or Android, in Go.  Maybe even Linux.

I looked briefly into Rust.  Three pointer types?  Geeze.  One in Go is already one too many.  Were there any C++ features they felt they could leave out?  I think the enhanced compile-time memory safety is an upgrade, but what happened to Python simplicity and power with C-like speed?  Rust doesn't hold much promise compared to Go, IMO, but at least it's a systems programming language.

Bill

[Ian Lance Taylor]

On Fri, May 15, 2015 at 5:25 PM, 'Bill Cox' via golang-nuts
<golan...@googlegroups.com> wrote:
>
> This is my biggest concern for Go. The overhead of Go's runtime has to be
> tiny. Why can't we upgrade the tool flow a bit and start creating
> C-linkable Go libraries that all the rest of the system can use?

It's done. It will be in the 1.5 release, at least for some OS's.
Use go build -buildmode=c-archive.

> I should
> be able to write Chrome, or Android, in Go. Maybe even Linux.

In my opinion, you could already write Chrome in Go. I'm not sure
just what you mean by Android, but it would be hard to write a kernel
in Go. Not completely impossible, just hard. Go is designed to crash
if it runs out of memory; a kernel doesn't have that luxury.

Ian

[andrewc...@gmail.com]

Garbage collection really is needed to keep channels useful, and the GC is a large part of the Go runtime. I think a mix of C and Go is a decent combo. Rust and Go also should work nicely together. Use the right tool for the right job.

[Joubin Houshyar]

> what happened to Python simplicity and power with C-like speed?

The (so-called) Von Neumann Architecture. As long as you are compiling to pointer machines you will hit this reality check. The Rust project is a data point that this issue is not motivational.

[Jesper Louis Andersen]

On Sat, May 16, 2015 at 4:24 PM, Joubin Houshyar <jhou...@gmail.com> wrote:

The (so-called) Von Neumann Architecture.

To be precise, most modern machines are modified Havard architectures. They act like Von Neumann machines when accessing DRAM, but the caching setup is usually of the Havard kind. As we try to squeeze out more efficiency of modern CPUs, the original logical definition of what a machine really is grows more blurry every day.

In turn, the simple representation of the machine is torn apart, and we need models of ever increasing complexity to understand them.

--

J.

[Joubin Houshyar]

Von Neumann apparently took credit for other people's work. So-called since it is the Eckert/Mauchly architecture.

Caching and IO models are orthogonal concerns to location-addressing.

[Roberto Zanotto]

Why do you want a system programming language, do you have to write an operating system? Because for creating applications and services, Go looks nicer than Rust :P (to me at least)

On Saturday, May 16, 2015 at 2:36:11 AM UTC+2, Bill Cox wrote:

[...] Rust doesn't hold much promise compared to Go, IMO, but at least it's a systems programming language.

Bill

[Aaron Cannon]

Last time I compiled a Rust "Hello world" program, the binary size was pretty on par with the size of binaries from Go. I don't know if this was from a runtime or what, but I was not expecting it. 

Aaron

 

--

This message was sent from a mobile device

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kamil Chmielewski]

W dniu sobota, 16 maja 2015 02:36:11 UTC+2 użytkownik Bill Cox napisał:

Python simplicity and power with C-like speed?

There's also http://nim-lang.org/

[David Leimbach]

Nim and Go are currently my top two favorite languages to learn and play around with.  Nim has a lot Go doesn't and should probably never do. 

Go makes a lot of stuff incredibly easy and the tool-chain is greatly appreciated.  I love being able to cross compile from OS X amd64 to linux 32bit arm and have stuff work by changing only a few environment variables.

I test software as I write it on my desktop, then build a version to target a Raspberry Pi and "deploy it" (scp).

Since llvm is a cross compiler, Nim can probably do this, but I've not played with cross-compilation with Nim on LLVM.  Nor have I exported the C code to the Pi to build it there (compiling on a Raspberry Pi is painfully slow by today's standards)

[Kevin Malachowski]

Not only that, but Go compiles so quickly I often just develop straight on my Raspberry Pi. (which is useful for binding to native libraries because afaik you can't use cgo if you cross compile)