<p>Hey guys! I'm really facinated by golang. It might be new system programming language after C and C++. But I'm a bit confused about the aims of the project. What I know, is that it want's to conquer the low level serverside programming from C++ and C, but does it aim to get a hold in other territories of the ancestors as well? I mean, people use C and C++ for rendering engines, all sorts of drivers, embedded systems, and the list goes on and on. Can golang compete with the oldies also in these areas? Or it is only focused on server programming?</p>
<hr/>**评论：**<br/><br/>shazow: <pre><p>(Reading other replies...) Clearly we're still figuring out what Go's purpose in life is.</p>
<p>I think Go's strengths are:</p>
<ul>
<li>Really easy to learn and become productive with. The language itself is quite small in syntactic features, but plenty powerful.</li>
<li>Really easy to target builds to a large number of supported architectures.</li>
<li>Excellent standard library for systems/network programming, and solid ecosystem that is rapidly growing (already good progress in the scientific community and desktop applications, recently starting to enter the realms of mobile and game dev).</li>
<li>Concurrency is not an afterthought but a carefully designed aspect of the language, increasingly important in our world where CPUs are getting more and more cores.</li>
</ul>
<p>Most importantly, I'm a fan of the velocity and direction of the language's progression. I think the core architects of Go are great at prioritizing efforts and have a realistic roadmap towards improving the language even further (better GC guarantees, compiling optimizations, even better bindings support, etc). There are still some unknowns (like the role of generics) but I respect the attitude towards that discussion and appreciate the care they put into fostering the language's growth.</p>
<p>I don't think there is as much effort in replacing low-level C the way Rust is trying to, but I can definitely see Go as a great substitute for complex C++ systems. </p></pre>hawtpeppers: <pre><p>the standard lib is crap, full of flaws. It has been chatted about endlessly on go-nuts and go-dev. go1 compat hinders improvement. the standard tools and libs are crap. everyone knows it. people are now fed up with the core devs and have started to replace the standard libs and even the standards tools. If those core devs don't get a clue fast it risks fracturing the ecosystem.</p>
<p>I am a consultant for a groups of corporations in the delaware valley. a group of 4 including me have been hired to replace as much of the toolchain with a 2-clause bsd with no CLA.</p>
<p>I've heard that another team is also working on replacing and stripping and fixing the standard lib. I haven't seen this work but I hear its promising.</p>
<p>these companies are spending what seems like millions to reproduce a go-like ecosystem without all the headache from google.</p></pre>gdm85: <pre><p>Ah, nice to hear!</p>
<p>Can you disclose if in that group (or that other team) work has been done on the build environment to address package/dependencies management in a sane way?</p></pre>szabba: <pre><p>Wouldn't breaking compatibility also cause ecosystem fragmentation?</p></pre>hawtpeppers: <pre><p>golang was intended to be a server application language. golang is suitable for any application that doesn't have hard real time expectations. GUI development is promising, so I see golang gui applications soon.</p>
<p>There is a chit ton of resistance from the core devs to expand the ecosystem of the standard tools and libs. that is the only threat I see to golang.</p></pre>hariharan-uno: <pre><p>It is a general purpose programming language which you can use depending on your technical requirements. You wouldn't use it for building a browser or very low latency software (e.g. the Need for speed game). In contrast to C or C++, Go is garbage collected. So, it is a bit slow. But as long as you don't have the necessity for raw speed, you can use Go. As far as I can tell, Go is a pretty good replacement for higher level dynamic languages like Python and Ruby. It isn't popular in other kinds of software as most of the work is currently being done on servers and networking (docker, kubernetes, etc.) But, it is extremely good for building command line applications. We will have to wait and see what the future holds. May be if a nice graphics library is developed, it might catch up in the desktop apps territory too.</p></pre>kylewolfe: <pre><p>I disagree with parts of this response. Calling the language slow is too much of a blanket statement, especially when referencing that it is garbage collected. Garbage collection can be turned off, for starters. I'd also be curious to see how the performance of Go's GC stacks up against others (if this is even possible).</p>
<p>Go is an open source project. It's goal is whatever the community decides it to be. IMO, one of the other areas outside of the obvious that is getting a lot of attention right now are mobile libraries. From what I've seen, it is becoming increasingly easier to develop apps for mobile.</p>
<p>There's not much that Go can't target. Depending on your definition of embedded systems, this may be one area it can't target. Go needs to be run on an existing supported OS. So you won't be compiling your own operating system in Go, for example.</p></pre>dasacc22: <pre><p>Along the same lines, saying it's no good for low latency software is a blanket statement that means little. For the recent Go challenge of writing a piano app for mobile (which consequently works on desktop), I wrote a sound synthesis package that produced, I think anyway, a realistic piano sound with minimal software latency on Desktop of only 1.2ms. Due to the buffer length and mobile target, the actual software latency is hard set at 5.8ms so there was still plenty of head-room for more complex effects on desktop.</p>
<p>On mobile, I got by for a long while until the effects became more complex but the majority of this has very little to do with Go.</p>
<p>Go also made it easy to process many synths in parallel given the architectural choices I made, taking advantage of multiple cpus. This was a win on mobile freeing up another 0.5ms of headroom early on. Sometimes that 0.5ms of headroom is all you need to breath a little extra life into a sound :)</p>
<p>And with all that said, it manages to do this with zero allocations during synthesis.</p>
<p>If there was one thing I would like, it would be a way to avoid bounds checking in a practical way (not fiddling with build flags, or avoiding what bounds checks are meant to prevent). I know that probably doesn't make a lot of sense, but it's not really meant to.</p></pre>ecmdome: <pre><p>Any parts of your project open source? I'm intrigued.</p></pre>dasacc22: <pre><p>All of it will be soon. The go challenge will publish my entry but I'll also be reorganizing and placing on github with the piano app serving as an example of using the package, and also publish app on my play account for general availability. Hopefully I'll get to that this weekend, but whatever the case I'll make an announcement here when I get to it.</p>
<p>I also still have a long TODO list in it as well :p</p></pre>dasacc22: <pre><p>still want to clean up the package and example before i do any other sort of announcement first, but here it is: <a href="https://github.com/dskinner/snd" rel="nofollow">https://github.com/dskinner/snd</a></p>
<p>The contest winners have been announced as well, so you may be interested in checking out what others have done (im winner #2): <a href="http://golang-challenge.com/go-challenge7/" rel="nofollow">http://golang-challenge.com/go-challenge7/</a></p></pre>umren: <pre><p>do you have desktop part of app open sourced?</p></pre>dasacc22: <pre><p>checkout the README of the example, you'd just run <code>go run *.go</code> in the example.
<a href="https://github.com/dskinner/snd/tree/master/example/piano" rel="nofollow">https://github.com/dskinner/snd/tree/master/example/piano</a></p>
<p>The way gomobile works is you can launch the same thing on desktop as would be seen on phone just by building and running. I don't know if windows is fully supported yet though if you happen to be on that platform.</p>
<p>The example app wasn't made for desktop though (or large form factors in general) but works just fine. I'd disable the freezing if running only on desktop: <a href="https://github.com/dskinner/snd/blob/master/example/piano/main.go#L227" rel="nofollow">https://github.com/dskinner/snd/blob/master/example/piano/main.go#L227</a></p>
<p>so there's an actual release triggered. The snd.Freeze type was tossed in last minute to compensate for going overboard designing my piano sound while still targeting low software latency on a cheap smartphone.</p></pre>boomshroom: <pre><blockquote>
<p>Go needs to be run on an existing supported OS. So you won't be compiling your own operating system in Go, for example.</p>
</blockquote>
<p><a href="https://github.com/boomshroom/goose" rel="nofollow">Denied</a></p></pre>hawtpeppers: <pre><p>writing it in asm wrapped in golang doesnt really count.</p></pre>boomshroom: <pre><p>Does that mean asm wrapped in c/c++/d/rust doesn't count? I guess OSs don't exist. Every OS ever requires assembly. rt0.s is even required for userspace apps. There is no escape from assembly.</p>
<p>[edit] do you consider</p>
<pre><code> asm ("movl %%eax, %%ebx");
</code></pre>
<p>to be assembly or c?</p></pre>hawtpeppers: <pre><p>And don't get me wrong I like what you are doing. I've started a similar project. For my project I've taken freebsd 10.2 release base install and I've been replacing parts written in c with go equivalents. </p>
<p>I picked freebsd because its a complete system, the most widely used bsd, and the license is compatible.</p></pre>hawtpeppers: <pre><p>you are missing the point, you arent writing it in golang. you are writing assembly.</p>
<p>that means chit wrapped in anything doesn't count as actually writing it in the language. don't kid yourself. when you get to write in golang then pat yourself on the back. Until then, but good progress</p></pre>boomshroom: <pre><p>So Unix is written in assembly wrapped in c and that's why it's so portable. Got it.</p></pre>dotcoder: <pre><p>I thithink, Go is more suited for software like proxy servers (Squid anyone?), netflow collector, torrent trackers, mail servers, etc.</p></pre>
