I love this language

I just want to say, I've been following the go language for a while now and I love it. I'm a systems engineer who fell into software development and love doing it. I came from a matlab and python background so I'm not the typical software developer, but I've learned a lot. I've heard the old guards' (c++, c, java) gripes about the language and i sort of get some part of their side of the story. But the more i understand this simple language the more i think it's strengths more than make up for it's weaknesses. The interfaces, the inheritance by composition, the concurrency model baked in, the channels, even the way go handles reading and writing, which at first was insanely difficult to understand why, but now makes so much sense in the context of the language. I especially love the speed i can get with garbage collection, the tooling built in, and the ease of compilation. But i just wanted to voice my support that, for a rapid development, high performance, networked software system, i don't think go can be beat. And i can't wait to see the ecosystem that develops around it. <hr/>**评论：** maus80: <pre>I am also a system (and network) engineer and I completely agree. Go is the best candidate to follow up C. It is fast, safe and simple. It really is a dream come true for DevOps/NoOps type of engineers.</pre>orbat: <pre>Rust is probably the next C. I mean I like Go well enough, and it's absolutely great for e.g. network-facing projects or anything where a GC and a simpler type system won't be in the way. Having a runtime and/or a GC just doesn't work in certain scenarios (e.g. device drivers or operating systems in general). Rust has no runtime and no GC, but it also has no manual memory management as such, it encourages functional patterns (and makes most of them very cheap), it has an interesting and powerful type system, and it makes it easy to interface with C.</pre>jerf: <pre>Rust is significantly and irreducibly more complicated than C. There are good reasons for that, and it gets things for that complexity that are impossible to get without it, but it's hard to see it completely replacing C's niche because of that. Not everyone is a professional programmer, and I've seen professional programmers balk at Rust's complexity too. (We can criticize them for that, but that doesn't change much.) Go, it is true, also does not completely replace C. But Go is mostly much simpler than C (at least to program in), and does the vast bulk of what people use C for, with a 21st century solution. Neither one is, strictly speaking, a "replacement", but between the two of them, the vast majority of what you might want to do in C is covered by the two of them. After all, languages are complicated things. If you get particular enough about your specification for your C replacement, you just end up specifying C again. You do have to grant your replacement at least a little wiggle room if you want to avoid that outcome. </pre>jeremiahs_bullfrog: <pre>If you're not a professional programmer, then you probably shouldn't be writing in C. If you're not a professional programmer and C is your only option, them Go likely doesn't work on the platform you're targeting since it's GC'd (hard to have a GC on a microcontroller). I don't think Go's niche is to replace C, but to be a faster alternative to Python, Node.js, Ruby, etc for threaded applications. That's essentially what we've used it for, and we really appreciate the low learning curve as we tend to train a lot of our programmers.</pre>jerf: <pre>I agree that almost nobody should be writing in C, and that even if you are in a situation where it is forced on you, all that means is that you're being forced to take a bad choice, not that it's a good choice. But that still seems to be a minority view right now. We're slowly getting change on that, but there's still a lot of professional programmers who see no problem writing in C, even after all the plainly-visible issues it is responsible for.</pre>jeremiahs_bullfrog: <pre><blockquote> almost nobody should be writing in C </blockquote> I didn't say that and I think C is a fine language, it just doesn't scale well (the larger it gets, the more likely bugs are). For microcontrollers and projects with only a few hundred lines of code, I think it's a perfectly reasonable choice. I think we need something safer as a replacement for C, and I think that language is Rust, but like any new technology, it needs to prove itself so it can replace C.</pre>orbat: <pre>Oh yeah, I absolutely agree with you; probably should have worded myself better. It's not a question of any language absolutely replacing or superseding another, but more that they fill a certain niche. Go and C are ultimately in different niches. C and Rust share one niche, but Rust also shares one niche with languages like Scala. C will be around long after we're gone, but some of its niche may now be filled by Rust</pre>SSoreil: <pre>I don't see Rust replacing C. The features it offers over C come at a cost to the programmer I don't think is low enough to justify moving away from C for many. Maybe in a few years with a few iterations of Rust.</pre>comradeswitch: <pre>Yeah. C has an odd sort of simplicity, somewhat like Python in my experience- it's easy to pick up and write a basic application in, but it takes a lot of work to master the languages. Rust definitely takes a lot of work to master- but that work has to be done up front in many cases. A concurrent application you could whip together the first day or two with Go could require dozens of hours of time with Rust before you get something you can run. I don't think that's inherently a bad thing, especially considering the safety benefits you get in exchange, but it's certainly going to hurt adoption. The fact that there are 20 different solutions in crates for any conceivable problem with no reasonable way to determine the quality or stability of each makes it an unappealing choice for business applications, too. I want to see Rust, or something like it, succeed. But I don't think "success" for Rust is going to look like it being a C killer. Not yet, at least. Too high of a barrier to entry, the main ecosystem of packages being unstable by definition just to get important compiler features...idk. I don't know the answers but I don't think C is in any danger of being replaced soon to any significant degree.</pre>mundanevoice: <pre>Rust has probably much worse syntax. It looks so complicated. </pre>ar1819: <pre>Sorry, but no. Rust is next something, but definitely not C. And type system, while being interesting, is definitely a problem, because of the complexity. And while some projects may benefit from it, I say safely say right now that systems programming and language complexity do not mix together. More importantly, most of the C developers this days are actually very good at managing memory and handling threading. The tooling also progressed. You may point me at examples like OpenSSL but those software was written long before Rust, Go, Nim or D. It also made to support tons of hardware configurations which LLVM didn't even heard of. The C is also relatively simple to implement for the target hardware. Short story - I believe that Rust will find it target audience when it stops comparing itself with C and C++. </pre>jeremiahs_bullfrog: <pre><blockquote> systems programming and language complexity do not mix together </blockquote> C++ would like to have a word with you. Yes, Rust has a fairly complicated type system, but you don't need to use all of it, much like in C++. If you stick with loops, structs and implementing existing traits, you essentially have C or Go without channels/goroutines, just now strict. <blockquote> More importantly, most of the C developers this days are actually very good at managing memory and handling threading </blockquote> Yet they either still make mistakes or use excessive locks, which hits performance. Rust essentially double checks your code for you, so the term "fearless concurrency" is apt. If you're convinced you're right, you can always disable the checker with <code>unsafe</code>. I've run into tons of concurrency related errors in Go (mostly due to invalid assumptions) that would have been caught with Rust. I think Rust will do quite well routing itself as a replacement for C/C++ because that's essentially what it was designed for, as it fixes many of the most common problems in C/C++. I don't think C will ever entirely go away, but I can see a lot of non trivial code moving from C to Rust. I'll still want C for my microcontroller projects, but I'll use Rust for everything where Go isn't a good fit.</pre>ar1819: <pre><blockquote> C++ would like to have a word with you. </blockquote> Oh - it constantly does. Because I work with C++ too =). It's good for creating all kinds stuff (we have goroutines and channels too - in boost) but it's incredibly complex (boost). You need at least 1-2 years to get productive in it and 5+ to get proficient. Drivers are still C only in 99% of the cases (runtime). And don't get me started on Altera or such and their C++ implementation. And their optimizer. Grrrr.... <blockquote> Yes, Rust has a fairly complicated type system, but you don't need to use all of it, much like in C++. </blockquote> I must be able to read it and "parse" in my head on the fly. Security flaws are not bound to index out of bounds (pun intended) and data races. Those do happen, but overrated (IMHO) because they are simpler to talk about. <blockquote> Yet they either still make mistakes or use excessive locks, which hits performance. </blockquote> Rust doesn't protect you from logical mistakes (<code><</code> instead of <code>></code> lol). Valgrind can catch most of the memory bound errors. Good static analysis can catch even more. As for performance - it depends. Benchmarks show that Rust is good at handling one sort of situations while failing at others. <blockquote> Rust essentially double checks your code for you, so the term "fearless concurrency" is apt. </blockquote> Rust forces me to strict owning mechanic. Which is not bad by itself, but on complex scenarios, it starts to slow down (RC is not free) or\and get incredibly hard to write. <blockquote> If you're convinced you're right, you can always disable the checker with unsafe </blockquote> I don't like to disable language features in critical parts of code. This essentially nullifies any statement about code being correct (unless unsafe part is proven, but that's entirely different subject). <blockquote> I've run into tons of concurrency related errors in Go (mostly due to invalid assumptions) that would have been caught with Rust. </blockquote> Rust doesn't protect you from thread starvation. That's why I like Go channels - they ensure that each goroutine would eventually access the shared data. <blockquote> I think Rust will do quite well routing itself as a replacement for C/C++ because that's essentially what it was designed for, as it fixes many of the most common problems in C/C++. </blockquote> First versions of Rust were entirely different language - with functional patterns, green IO. Then it was redesigned to be used as a new language for the next Mozilla browser. Then they decided to use "just in web rendering engine" (Spidermonkey is not going anywhere.). So the language was designed to solve Mozilla problems. Just like Go was designed to solve Google problems. And here lies my problem - I have no trouble with borrow checker. Trait system and implicit conversions, on the other hand, which allow you to write incredibly complex code is bad for security. Because security is about readability when project reaches 100k+ lines of code. <blockquote> I don't think C will ever entirely go away, but I can see a lot of non trivial code moving from C to Rust. I'll still want C for my microcontroller projects, but I'll use Rust for everything where Go isn't a good fit. </blockquote> You can use any kind language you want, as long as it fulfills your needs or the needs of your customers. In end, all we care about is the result. But I honestly tired of this "Rust is our salvation" spam. It's not - Pony is coming and their type system is even "better" (and formally proven btw). Don't get me wrong - my company (listed on the Rust site btw) is using it - good language for some sort of the situations, but the scope is limited. And instead of seeing things like "This would be better if it was written in Rust" I would like to see "We saved N amount of money\resources\manpower by writing this piece of our infrastructure in Rust. And here what we learned".</pre>jeremiahs_bullfrog: <pre><blockquote> I must be able to read it and "parse" in my head on the fly </blockquote> And Rust is very good at that, but it takes some time to get familiar with it enough to do so. The benefit of Rust, IMO, is that it takes away many of the commonly missed memory errors and frees you to focus on the logic errors. <blockquote> Rust doesn't protect you from logical mistakes </blockquote> True, which is why it's awesome that it eliminates entire classes of errors and lets you focus on the logic. <blockquote> As for performance - it depends </blockquote> Exactly. Go's GC was a huger problem at launch (almost prevented us from adopting it because it's imprecise nature cause issues on low memory systems), but it's gotten way better. I expect the same from Rust, that as it matures, so will performance. Just recently someone landed a patch for <code>sort</code> that dramatically improves performance (based on TimSort). <blockquote> Valgrind can catch most of the memory bound errors </blockquote> Only if you hit that code path in your testing, which you should, but you won't necessarily do. I'm still finding problems with Go's race detector in code I haven't touched in over a year, because it's not as commonly hit. Rust prevents nearly all classes of memory issues so you don't need tools like Valgrind, which simplifies testing. <blockquote> unless unsafe part is proven, but that's entirely different subject </blockquote> I think that's exactly the subject. If you have <code>unsafe</code> code, that's a red flag for an audit/unit tests, and should be the most well tested part of your code. You still get checks there, so it's at least as good as other languages in <code>unsafe</code> blocks. <blockquote> Rust doesn't protect you from thread starvation </blockquote> True, but that's not a memory error, and you can always use a async library to solve the same problem (like <a href="https://github.com/carllerche/mio"><code>mio</code></a> for sockets or <a href="https://github.com/tokio-rs/tokio-proto"><code>tokio</code></a> for other I/O). <a href="https://github.com/golang/go/issues/10958">In Go, tight loops can block the GC</a>, so it's also a problem in Go (but I think it will be fixed in 1.8 since a commit seems to have landed). <a href="https://doc.rust-lang.org/std/sync/mpsc/index.html">Rust also has channels</a>, so you can get similar benefits. They're not as nice as Go's channels (can't use them in a <code>select</code>), but they're there. <blockquote> it starts to slow down (RC is not free) </blockquote> You don't have to use reference counting, it's opt-in with the <code>Rc</code> and <code>Arc</code> types. By default it essentially works like C++ using scope to determine when to destruct things. If you want smart pointers w/o reference counting, use <code>Box</code>, which essentially just allocates on the heap and deallocates when it goes out of scope. In this case, it's better than Go in many regards because: <ul> <li>you can choose the costs you want to pay (copying, <code>Rc/Arc</code>, <code>Box</code>); I've heard rumors that there are some WIP garbage collectors you can add if that's your cup of tea</li> <li>no built-in garbage collection means you never stop the world</li> </ul> <blockquote> First version's of Rust were entirely different language </blockquote> True, but the core reasons for its existence never changed: memory safety without compromising performance. Go also had quite a few major design changes since it was introduced, and it spent far less time as a public beta than Rust did (Rust was essentially developed in the open, Go only became public within a year or so of hitting 1.0). I do miss green threads, but I also like the direction it's gone since those things can (and are) be developed as libraries efficiently. <blockquote> Trait system and implicit conversions </blockquote> Examples? Rust has a more strict definition for implicit conversions than most languages, so you won't get the same issues that you'd have in C, C++ or Java for example. I can see this potentially being a problem in crypto, for example, but the memory guarantees really offset that minor issue. YMMV of course. <blockquote> But I honestly tired of this "Rust is our salvation" spam </blockquote> I'm not saying that at all. I use Rust, Go, Python, C, JavaScript, etc all for different purposes. My argument is that Rust is a more likely shoe-in for the types of problems most people use C for, and Go fits more as a replacement for higher level languages (like Ruby, JavaScript, Python, etc) when performance is needed. <blockquote> "This would be better it was written in Rust" I would like to see "We saved N amount of money\resources\manpower by writing this piece of our infrastructure in Rust. And here what we learned" </blockquote> I'm sure we'll get that in time, just like we got with Go. It took a year or two for larger companies to switch to Go and blog about it, and I'm sure the same will happen with Rust. Mozilla switching Firefox to Rust will be a fantastic boon to these kind of anecdotes (and they've already landed code in Firefox). So yeah, that'll come in time, and I'm eager to read them. I love Go and I love Rust, and before I push for it in a larger project, I'll need more proof that it scales well. For now, I'm enjoying using it in smaller projects that I hope to ship to actual users.</pre>ar1819: <pre><blockquote> Rust is very good at that </blockquote> Depends on who you asking. <blockquote> True, which is why it's awesome that it eliminates entire classes of errors and lets you focus on the logic. </blockquote> I really don't remember the last time I've encountered use-after-free or data race error in my cpp apps. YMMV. <blockquote> Exactly. Go's GC was a huger problem at launch </blockquote> GC was young back then and immature. More importantly - it's quite different from Java\C# one. <blockquote> I expect the same from Rust, that as it matures, so will performance. </blockquote> Rust uses JeMalloc which is neither young nor immature. <blockquote> Only if you hit that code path in your testing, which you should, but you won't necessarily do. </blockquote> In critical systems? You wold not only test it, but will prove it be correct. <blockquote> Rust prevents nearly all classes of memory issues so you don't need tools like Valgrind </blockquote> There was an article about use after free in Rust. Also Valgrind is used for other things. <blockquote> Rust also has channels , so you can get similar benefits. </blockquote> You are comparing SPSC queues with MPMC. That's not the same thing. <blockquote> If you want smart pointers w/o reference counting, use Box, which essentially just allocates on the heap and deallocates when it goes out of scope. </blockquote> You can't use object graph with Box. <blockquote> no built-in garbage collection means you never stop the world </blockquote> STW argument is only working when you don't allocate\deallocate memory at all. Box doesn't allow you(yet) to specify allocation strategy. And Jemalloc is not free. <blockquote> Examples? </blockquote> <code>Into</code> and <code>&str</code>. <blockquote> same issues that you'd have in C, C++ or Java for example </blockquote> I'm not talking about <code>int -> float</code> implicit conversions. Those could be enabled as warnings (even blocking ones) in GCC, Clang and MSVC. <blockquote> My argument is that Rust is a more likely shoe-in for the types of problems most people use C </blockquote> I need specific examples. I use Go, but I also still use Python. Scientific computations are MUCH cheaper in NumPy (FORTRAN say hello btw). <blockquote> I'm sure we'll get that in time, just like we got with Go. </blockquote> It has been almost two years since the release - at that time (2014) we had Iron.io, Dropbox, CloudFlare and others. I don't love languages - they are simply the tools for making things done. But I also don't like complexity, when it's not needed. I heard "C needs to go" mantra back in 2007 and even before that. Even better - we had better C dialects (I'm not talking about C++) with safe memory model. Didn't get much traction.</pre>jeremiahs_bullfrog: <pre><blockquote> I really don't remember the last time I've encountered use-after-free or data race error in my cpp apps. YMMV </blockquote> But that's not the only thing it prevents, and misses arguably the most important one: data races. When I first started building a large project in Go (I was lead developer), I made some unfortunate assumptions in Go and I ended up having to throw mutexes in a lot of places for operations that I thought were atomic (map reads/writes). On Go 1.4 and before, Go only used a single execution thread, so we didn't have any bugs, but once Go 1.5 came out, all kinds of threading-relate bugs surfaced. I then realized my error and have been adding mutexes everywhere to make sure things are safe. In Rust, such code would fail to compile. <blockquote> Rust uses JeMalloc which is neither young nor immature </blockquote> <ol> <li>the allocator isn't the only thing that can be optimized</li> <li>Rust <a href="https://github.com/rust-lang/rfcs/blob/master/text/1183-swap-out-jemalloc.md" rel="nofollow">has accepted allowing a custom allocator</a> and <a href="https://github.com/rust-lang/rust/issues/33082" rel="nofollow">it's being worked on</a></li> </ol> <blockquote> In critical systems? You wold not only test it, but will prove it be correct. </blockquote> Not everyone works on critical systems, but if you do, it would be far nicer to catch those errors in development so the review goes faster. <blockquote> There was an article about use after free in Rust </blockquote> There's also an article from someone on the Go core team about <a href="https://research.swtch.com/gorace" rel="nofollow">Go not being memory safe</a> and <a href="http://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html" rel="nofollow">relatively recently confirmed</a>, so it's likely not fixed (though the Go bug mentioned is hard to trigger). Both compilers have bugs, but I haven't been able to find the one you mentioned, though I'm very interested in reading it (the things I've found are from over a year old). <blockquote> You are comparing SPSC queues with MPMC. That's not the same thing. </blockquote> Sort of. Go's channels are MPMC, Rust's channels are MPSC, but <a href="https://github.com/BurntSushi/chan" rel="nofollow">there's a library for MPMC channels in Rust</a> from someone who is quite big in the Rust community (author of <a href="https://github.com/BurntSushi/ripgrep" rel="nofollow">ripgrep</a>), so I'm fairly confident in its quality. So you're right, Go and Rust don't quite do the same thing, but with a library they effectively do. <blockquote> You can't use object graph with Box </blockquote> Yes, there are limitations. See <a href="http://featherweightmusings.blogspot.com/2015/04/graphs-in-rust.html" rel="nofollow">this blog post</a> if you haven't already that gives solutions here. There has been talk about having an external GC (used much like <code>Rc</code>) to make these types of things easier, but I haven't seen anything concrete yet. There is <a href="https://github.com/Manishearth/rust-gc" rel="nofollow">this project</a> and I'm sure others to solve these types of problems. <blockquote> I need specific examples </blockquote> <ul> <li>games</li> <li>kernels/drivers</li> <li>microprocessors (assuming you have compiler support)</li> </ul> <blockquote> It has been almost two years since the release </blockquote> And <a href="https://www.rust-lang.org/en-US/friends.html" rel="nofollow">here's a list of organizations using Rust in production</a>, among them is Dropbox, so it looks like Rust's market isn't necessarily so different from Go's. <blockquote> we had better C dialects (I'm not talking about C++) with safe memory model. Didn't get much traction </blockquote> The problem is that nobody wants to switch unless they're sure the thing they're switching to has long term support. Go took off in large part because it's backed by Google, and I expect Rust to take off because it's backed by Mozilla. D, Vala and many others are not backed by a large organization, so people are a bit more hesitant to switch. The good part about Rust is that it's easy to port part of your application to Rust (since you can use Rust as a C library), whereas for Go, that wasn't possible until 1.6 or something like that, and even today, working with C++ is very difficult in Go and hasn't been a huge focus from what I can tell. From <a href="https://github.com/rust-lang/rfcs/pull/1774" rel="nofollow">Rust's 2017 roadmap</a>, this will hopefully be a focus. Under <a href="https://github.com/rust-lang/rfcs/blob/master/text/1774-roadmap-2017.md#integration-with-other-languages" rel="nofollow">"Areas of Exploration"</a>: <blockquote> <ul> <li>Continuing work on bindgen, with focus on seamless C and eventually C++ support. This may involve some FFI-related language extensions (like richer repr).</li> <li>Other routes for C/C++ integration.</li> </ul> </blockquote> I really hope this gets attention this year as it's one of my biggest complaints about Go. I'm not sure what I'm expecting though. <blockquote> I don't love languages - they are simply the tools for making things done </blockquote> And I do, but I use the right tool for the job. I wanted to build a game and I really wanted to do so with Rust, but the tools just weren't there for the platforms I wanted to target, so I'm building it in Java (this particular game isn't very CPU/graphics intensive) using a framework that works on all platforms I want to target. I really don't like Java as a language, but it works well as a tool. I opted for writing the server in Rust because I want to make sure I don't have any concurrency-related issues as it would really suck to have to take the game server down for maintenance because of a data race. For smaller web-based projects, I use Go because the library support just isn't there in Rust yet (well, it's there, but not 1.0, though that's a focus for 2017). I expect C/C++ programmers to flock to a variety of different languages, and if I had to give a prediction today, I'd say the main contenders are Rust, Go and Swift.</pre>ar1819: <pre><blockquote> But that's not the only thing it prevents, and misses arguably the most important one: data races. </blockquote> I've mentioned them. <blockquote> When I first started building a large project in Go (I was lead developer), I made some unfortunate assumptions in Go and I ended up having to throw mutexes in a lot of places for operations that I thought were atomic (map reads/writes). </blockquote> <a href="https://golang.org/doc/faq#atomic_maps" rel="nofollow">https://golang.org/doc/faq#atomic_maps</a> <blockquote> Rust's channels are MPSC, but there's a library for MPMC channels in Rust from someone who is quite big in the Rust community (author of ripgrep ), so I'm fairly confident in its quality. </blockquote> I'm not - Andrew Gallant is a really good developer, and I'm grateful for ripgrep, but he is not "multi-core developer". And, he himself, even admits that: <pre><code>Channels can be leaked! In particular, if all receivers have been dropped, then any future sends will block. Usually this is indicative of a bug in your program. // This implementation is extremely naive and probably very inefficient. // Notably, *every* channel send/recv calls `notify`, which needs to acquire // a lock and broadcast to every select's condition variable. </code></pre> This queue IS extremely naive and has no guaranties about thread ordering. I'm not talking about cache lines and sizing, because it's not a lock-free queue. <blockquote> So you're right, Go and Rust don't quite do the same thing, but with a library they effectively do. </blockquote> Please read Go channel implementation before making such claims. You will surprised =) <blockquote> Yes, there are limitations. See this blog post if you haven't already that gives solutions here. </blockquote> I know about UnsafeCell, but I don't like the fact that I must bypass the language features in order to make this simple thing. <blockquote> but I haven't been able to find the one you mentioned </blockquote> <a href="https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety" rel="nofollow">https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety</a> - it's not a bug, it's a valid construct. <blockquote> games </blockquote> Unless you talking about indie games - it's not happening. Triple A developers especially care about how EXACTLY their code is matched to the CPU set. There is also support problems (Official DirectX API in Rust) and tooling. And - you'd not be surprised - game developers are willing to trade correctness for speed. <blockquote> kernels/drivers </blockquote> Good luck convincing Linux core people about that =D <blockquote> microprocessors (assuming you have compiler support) </blockquote> Yeah, about that - have you looked at LLVM hardware support? Better yet - have you looked at first-class Rust support? <blockquote> Rust to take off because it's backed by Mozilla. </blockquote> I'd be vary before making such statements - Firefox market share is still shrinking. They essentially lost mobile segment entirely. And most of the senior stuff I've talked with are well aware of that. <blockquote> I wanted to build a game </blockquote> <ol> <li>Unreal Engine</li> <li>Unity</li> </ol> Pick one and don't bother yourself. <blockquote> I expect C/C++ programmers to flock to a variety of different languages </blockquote> Yeah - C++ expected C developers to make transition. It was 90s. Didn't happen.</pre>jeremiahs_bullfrog: <pre><blockquote> <a href="https://golang.org/doc/faq#atomic_maps" rel="nofollow">https://golang.org/doc/faq#atomic_maps</a> </blockquote> Yup, I found that when I was wondering why everything was broken. It doesn't help that many of our developers used to write in Node.js, so data races weren't commonly dealt with (we migrated because Node.js wasn't fast enough and was hard to debug). <blockquote> This queue IS extremely naive and has no guaranties about thread ordering </blockquote> I actually didn't really look into it beyond checking if there was a reasonable MSMC library. <blockquote> Please read Go channel implementation before making such claims. You will surprised =) </blockquote> I hope so, but I do know that Go uses locks both on send and receive, though I also know that the Go developers are very technically aware, so they probably use a hybrid lock-free/mutex design of some sort. I'll have to give it a read though, thanks for the nudge. <blockquote> but I don't like the fact that I must bypass the language features in order to make this simple thing </blockquote> It's a "simple thing" that plagues naive garbage collectors and pretty much any other form of memory management besides manual memory management. I seem to remember needing to manually nullify my ring buffers and graphs in Java to make sure the GC detected it (though I think that's since been solved). <blockquote> There is also support problems (Official DirectX API in Rust) and tooling </blockquote> Well, not to nitpick, but I think (hope?) Vulkan will replace DirectX. That being said, as long as there's a C API, it'll be fairly easy to make an efficient Rust binding. <blockquote> game developers are willing to trade correctness for speed </blockquote> Game developers also care a lot about meeting deadlines, and if Rust can help prevent the types of bugs that delay releases, it will be a big sell. Also, Rust has the option of using inline assembler (in <code>unsafe</code> blocks of course), so you can still optimize the hot paths in the same way. The one major hurdle that I can see with games is that game developers really don't like allocating or deallocating memory (as that's expensive), so it'll be interesting if safe concurrency is a big enough sell. <blockquote> Good luck convincing Linux core people about that =D </blockquote> Yeah, but Linux also isn't the only kernel around. <blockquote> Yeah, about that - have you looked at LLVM hardware support? </blockquote> Yup, definitely a WIP. But I'm looking at the 5-10 year horizon, so it's certainly possible. <blockquote> Firefox market share is still shrinking </blockquote> True, but millions still use Firefox. Opera and Safari are way below Firefox, yet they're still being commercially developed. It'll be hard to convert the Chrome crowd for sure, but if Servo is even half as good as they say it will, they'll have lots of benchmarks to back them up, which apparently is important to some people. Anecdotally, I use Firefox on both desktop and mobile. <blockquote> <ol> <li>Unreal Engine</li> <li>Unity</li> </ol> Pick one and don't bother yourself. </blockquote> I went with <a href="http://libgdx.badlogicgames.com/" rel="nofollow">libgdx</a>, mostly because I wanted a 2D game and it was easier to get up and running than Unreal Engine. When I build a 3D game, you bet I'll try Unreal Engine (Unity isn't really an option for me because it doesn't seem to work well on Linux, and that's my dev environment).</pre>lonahex: <pre>Rust is a better C++. Go is a better C.</pre>orbat: <pre>People here keep repeating that, but I don't think you fully understand that C and Go have, for the most part, very different use cases</pre>comrade-jim: <pre>According to almost all statistics, Go is already orders of magnitude more popular than Rust. If any language is more likely to replace C it's Go, simply because no one is using Rust. </pre>disintegore: <pre>To this day I still don't understand the "rivarly" between Go and Rust. As far as I'm concerned, they are vastly different and can/should co-exist.</pre>goomba_gibbon: <pre>Hear hear. Why does everything have to be the next version of something else? They both solve different problems in different ways with differing opinions.</pre>elingeniero: <pre>Also the rust development team really care about their product and their community which certainly can't be said about Go. If Rust weren't so hard to learn I think that it would overtake Go in a couple of years, even for network programming.</pre>orbat: <pre>Don't you think that's unnecessarily harsh? Sure, I think there are several issues with both the language and governance in general, but I don't think it's really fair to say the Go team doesn't care about the product or the community just because the direction they've taken Go is not to your liking. I do agree about Rust, though. I've started learning it on my free time, and it's definitely on the challenging side of the spectrum. It's not quite Haskell, but Scala comes to mind pretty often.</pre>jeremiahs_bullfrog: <pre>What's wrong with the governance? I appreciate how open it is compared to Go. In Go, I proposed a change that was met with "that's not the direction we want to go", whereas in Rust I think I would have had a more thorough discussion as to why my change wasn't acceptable. Rust is developed by a core team like Go, but they are run as a true community project where language features are often proposed by members of the community. I think Rust also does a great job at keeping the community friendly and constructive. Newcomers are welcomed and guided to answers, not tersely dismissed. I love Go and I love Rust, but that fill two different niches for me.</pre>orbat: <pre>I specifically meant Go's governance</pre>jeremiahs_bullfrog: <pre>Ah, I misread. I guess we're on the same page then. I do think the Go project is well run, but the are lots of things I'd like to see that the Go team is unlikely to entertain, such as: <ul> <li>Destructors</li> <li>Genetics</li> <li>Required field values in interfaces</li> <li>Adding methods to types that you don't control (you can do this with type aliases)</li> <li>Default implementations for functions in interfaces (like Rust has with Traits)</li> <li>Subset of Go without a GC (e.g. for embedded work)</li> </ul> I have all of those things in Rust (well, they're still deciding on what to do about fields in Traits), and I feel like the core team is open to well reasoned arguments for inclusion, unlike the Go team, which seems really opinionated (which is good in its own way, but you need balance).</pre>elingeniero: <pre>Maybe it is overly harsh, but running a language for seven years without any effort towards a good, official dependency management solution because "Google uses GOPATH and <code>go get</code> just fine so f*** you guys" feels almost like disdain to me, I think its justification enough to suggest that the development team doesn't care that much about the community. I saw the recent blog post about it, its a bit late though, especially when you compare it with the Rust team's approach to it - cargo and crates.io is probably the best attempt at dependency management so far; it is officially supported and was introduced before 1.0.</pre>hugthemachines: <pre>I don't even program in Rust but judging from what reasonable people say on reddit and on the web in general it does seem like the difficulty level of Rust decrease the popularity alot. Perhaps it is hard to make the language easier and still have the important features still in the language.</pre>jeremiahs_bullfrog: <pre>They're actually working on that this year, as their focus is on user friendliness. This means they're working on: <ul> <li>IDE tooling (<a href="http://www.jonathanturner.org/2017/01/rls-alpha-release.html" rel="nofollow">just released an alpha of the Rust Language Server</a>)</li> <li>Documentation (already far better than most languages, but still can be better)</li> <li>Faster edit-compile-reload process</li> <li>Making the compiler smarter so lifetimes aren't needed as often (since 1.0, this has gotten a lot better already and I rarely use them now)</li> </ul> I really wish the Go team made a roadmap or similar.</pre>hugthemachines: <pre>It sounds great and I really hope it will be better and better. I was a little dissapointed when I tried to set up IDE using eclipse and Rust plugin and it did not work to add projects using it. But what I have heard about is trouble with the borrow stuff. Perhaps it could be changed a bit to make it easier for people to grasp it and use it. It is just my thought though, perhaps it is good, just as it is.</pre>jeremiahs_bullfrog: <pre><blockquote> I was a little dissapointed when I tried to set up IDE using eclipse and Rust plugin and it did not work to add projects using it </blockquote> And that's precisely the problem the Rust team is working on this year. In fact, if you're adventurous, you could probably use it today, though I'd wait for a little while to make sure the documentation is there for Eclipse. <blockquote> But what I have heard about is trouble with the borrow stuff </blockquote> Yeah, and this is a two way street. If you want safety, you have to pay the price. However, the focus recently has been in making the compiler smarter so it understands your code better so it can figure out borrow issues. When Rust first came out, I had to throw lifetime annotations nearly everywhere, but recently, adding in lifetimes tends to signify a flaw in my design and is often a reminder that a struct if doing too much. It's important to note that it's getting better, though you'll always have to learn about them since it's a concept so fundamental to Rust. And one huge benefit is that it's essentially a one time cost in learning the language and you get true memory safety (compete with data race checks) in return. I'm grateful that it's there since I've run into all sorts of problems in the past with lifetime errors, though not as much with Go, where my problems are mostly race condition type issues.</pre>kalekold: <pre>Go is the next C, Rust <del>is</del> may be the next C++</pre>jeremiahs_bullfrog: <pre>Show me a microcontroller or OS running Go. The GC alone disqualifies it in many cases, much less the threading. If you can't use goroutines or the GC, Go doesn't make sense.</pre>jeremiahs_bullfrog: <pre><blockquote> safe </blockquote> For some definitions of safe, but it doesn't help prevent some of the more common (and more subtle) classes of bugs, like race conditions (though the race detector is helpful here) and nil pointer errors. Rust does, so I think it'll find its niche among the crowd for whom "safe" is more important than simple. That being said, I think you're completely right about DevOps. I needed to write a simple port forwarding program in Go and it took maybe 30 minutes to build, test and deploy. Making simple, concurrent and safe programs is very easy in Go. My issues stem from scaling where it's difficult to ensure correct data access across tens of thousands of lines of code. This is why I'm considering Rust for my future projects that will be large and make heavy use of threading, like games.</pre>karma_vacuum123: <pre>can anything be the "next C"? its one thing to write the tools themselves....another to produce something from them like the Linux kernel, Postgres, etc etc i predict a hugely lucrative market in maintaining C code that the world simply cannot replace as all the kids move on to their Better Languages likewise for Java...thirty years from now it will still be providing Null Pointer Exception job insurance</pre>tmornini: <pre><blockquote> the inheritance by composition </blockquote> Go has no inheritance.</pre>frogmouse: <pre>Yes that's true, i meant they tackle the same feature by using composition instead. A more accurate saying would be "use of composition and interfaces instead of inheritance"</pre>orbat: <pre>How about instead of downvoting <a href="/u/tmornini" rel="nofollow">/u/tmornini</a> you read <a href="https://golang.org/ref/spec" rel="nofollow">the spec</a> and show us where it talks about inheritance or object orientation or classes. We'll wait. And no, the sentence starting with "The declared type does not inherit any methods bound to the existing type" is not it. Go does not have inheritance. Everything is about <a href="https://golang.org/ref/spec#Method_sets" rel="nofollow">method sets</a>; with composition you don't have is-a relationships – more like "does-this" (<code>io.Writer</code>), if that makes any sense. Interfaces (i.e. method sets) declare what something can do, not what it is.</pre>onwuka: <pre>Taking "punting the diamond inheritance problem" to the next level!</pre>__crackers__: <pre>I think of interfaces as formalised duck typing. Go doesn't care what the struct is, only whether it has, say, a <code>Read()</code> method that returns a string.</pre>comradeswitch: <pre>Whether the language spec uses that language or not isn't really relevant. The language spec could call structs "classes" and go would still be struct-based. These descriptors are just a way to think about languages in terms of common concepts. You knew exactly what OP meant, and so did most likely everyone else here. Maybe it's not perfectly technically correct, but it conveys the idea just fine, and it's hardly going to cause any sort of practical problems. This is just pedantry. Handwaving is bad when you're trying to enumerate a proof. It's really not an issue when describing the gist of a proof so that someone follows the general argument. It's really not a big deal. Especially sinxe OP clearly knows what they're talking about. </pre>tmornini: <pre>:-)</pre>golanger1: <pre>Even C has no inheritance, so whats your point?</pre>tmornini: <pre>Not sure what C has to do with this conversation, but to answer your question, my point was that -- wait for it -- Go doesn't have inheritance and instead relies entirely upon composition, which I consider to be a very good thing.</pre>dankoradora: <pre><blockquote> Go doesn't have inheritance and instead relies entirely upon composition </blockquote> This is the same meaning as the OP's the inheritance by composition means in his context. People didn't downvote you because you were wrong, they did because you're nitpicking.</pre>tmornini: <pre>I'll happily be downvoted to avoid a single person believing Go had inheritance.</pre>mbyio: <pre>It's not really nitpicking though, is it? Go doesn't have inheritance. Suggesting that it simulates inheritance somehow is just wrong.</pre>dankoradora: <pre>The inheritance by composition is very often used in this context as "solving a problem, that you would usually rely on inheritance, by composition". But I agree "the inheritance by composition" is quite unclear statement and can by easily misunderstood.</pre>onwuka: <pre>I'm no expert but even I've heard of composition over inheritance. Inheritance by composition is just wrong. </pre>__crackers__: <pre>Technically incorrect, but perfectly legit rhetorically. Frankly, it's little different to Go's own "share memory by communicating" mantra. "Inheritance" and "sharing memory" aren't meant to be taken literally, but stand for the ends you normally achieve via those means.</pre>comradeswitch: <pre>I'm a mathematician/QA specialist turned developer. I worked with MATLAB when studying applied math and used Python for several years doing machine learning research. You may not be typical but you're definitely not alone! I love go. There are some things it doesn't do well. There are some areas of the ecosystem that are not as developed as I'd like and some areas where it just isn't suited. But almost every time I start thinking about a project that isn't heavy on math, I turn to go. Sometimes I end up rewriting a project in another language, but for most applications? Go is just fine. The simplicity is the biggest feature for me. I like the idea of, say, Rust. I've done some big projects in C++. Hell, even Python is pretty complex once you get past the basics. I've learned, however, that unless that complexity provides a significant benefit because of a particular constraint, I would much rather work with a language that has a low cognitive load. When I'm writing Rust or C++ code, I'm often thinking more about the language and its ins and outs than the application I'm writing. That significantly slows down development and requires more effort. if I'm going to deal with a language spec the size of War and Peace, I better be getting a big benefit to my application for that And most of the time, I'm just not. I don't want to have to remember more about constraints imposed by the language than constraints imposed by my problem unless I have to, and I rarely have to. Certainly much less often than many go critics might lead you to believe.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题