What if Golang is purely systems programming language with good features like rust and no GC and minimal runtime?

<p>Recently I was going through rustlang, I find it really good, just that it feels like it is being built for geeks, without thinking about newcomers. so I was just having this thought, what if all the good qualities like no GC, automatic memory management, minimal runtime and all other goodies that rust has, will be ported to go?, it is just a thought, but anyone care to imagine what could happen, with that much power and that much simplicity ?</p> <hr/>**评论：**<br/><br/>ivoszz: <pre><p>Then there will be no simplicity.</p></pre>TheMerovius: <pre><blockquote> <p>what if all the good qualities like no GC, automatic memory management, minimal runtime and all other goodies that rust has, will be ported to go?</p> </blockquote> <p>Then you&#39;d have rust. Seems a lot of work compared to just use rust from the start. The complexity of rust isn&#39;t accidental, it is problem-inherent and due to all the &#34;goodies&#34; you mentioned. You can&#39;t just take the good things of both sides of a tradeoff; it wouldn&#39;t be a tradeoff then. You have to weigh both sides and accept the downsides of your choice to get the upsides. There is no such thing as a free lunch.</p></pre>aboukirev: <pre><p>Rust could have been better if it was not designed by a committee: great ideas, so-so execution. With a Go team&#39;s more systematic approach, some of these features could be done better.</p> <p>Still, Go&#39;s concurrency does not seem to jive with Rust&#39;s borrow system. That&#39;s why Rust is unlikely to ever get nice concurrency as part of the language and will have to live with macro and wrappers in crates. </p></pre>TheMerovius: <pre><p>I think rust is pretty great. I just don&#39;t think other languages need to become rust.</p> <blockquote> <p>That&#39;s why Rust is unlikely to ever get nice concurrency as part of the language and will have to live with macro and wrappers in crates.</p> </blockquote> <p>Rust <em>had</em> a nice concurrency system, but it was removed to keep the runtime down and stay with zero-cost abstractions, AIUI. Y&#39;know, those &#34;goodies&#34; of rust, that OP is referring to.</p></pre>Perelandric: <pre><p>I think <a href="https://ponylang.org/" rel="nofollow">Pony</a> offers a decent middle ground. The biggest hurdle is its memory safety which is achieved via its reference capability system, but they set it up with good defaults and the compiler is very informative when you have a violation.</p> <p>It does have GC, but it&#39;s concurrent and runs between asynchronous methods, so there&#39;s no stop-the-world that interrupts your code.</p> <p>I&#39;d stick with Go overall, but check out Pony too. It&#39;s not perfect (no language is) and it hasn&#39;t reached a stable release yet, but there&#39;s a very active and friendly community around it. Here&#39;s <a href="https://www.youtube.com/watch?v=fNdnr1MUXp8" rel="nofollow">an older overview</a> of the language if you&#39;re interested in the highlights.</p></pre>PaluMacil: <pre><p>I don&#39;t recall who talked about this but someone on the Go team did muse about this--something for very small machines indeed--but it would be far in the future since much fewer people would use it, the technical complexity of maintaining such a different edition, and all the language features that would need to be added for things such as manual memory management. Some of the ease of Go is from the carefully selected default decisions that fill most needs. Go and Rust are good for different things, but both overlap enough that a GC-less version of Go would only add a few more cases (Arduinos, true RTOS, manufacturing controls, etc). Another issue is that tutorials and documentation would need more caveats and clarification. That might beg us wait for a much larger Go marketshare before adding and noise via Go-slim.</p></pre>