Does Go 2.0 still aims to take on C++?

As far as I understood initially Go was designed to replace C++ (at least at Google) but proved better fit to replace python and its friends(great thing for some of us). Is this noble goal still valid for Go 2.0? Any chance we can develop real time high performance apps, drivers, codecs, transcoders etc in Go 2.0 instead of C/C++? I know we should provide real use-cases if we want features into Go 2.0 but who would start a project that requires real time capabilities if it know for sure that's not possible with Go? The current answer is usually os.Exec a c/c++ program/library. Nevertheless for what is does now(network/web services) go is good enough for me with all its quirks(i.e. multiple ways to define a variable) and lack of features(i.e. generics). <hr/>**评论：** nagai: <pre>To replace C++ and to replace C++ in one specific company are two very different things. Go is pretty much the exact opposite of C++. And for a lot of applications, a garbage collected language can never replace C++.</pre>Ainar-G: <pre><blockquote> As far as I understood initially Go was designed to replace C++ (at least at Google) </blockquote> When mentioning this, you should keep in mind, what C++ was used for at Google at the time. AFAIK, it was mostly services, systems of services (which is one of the reasons Go used to be called a systems language). In this regard, Go did replace C++. I don't think the Go creators ever saw Go as a replacement for C/C++ in anything low-level, although it can be done.</pre>jrwren: <pre>what about desktop apps? The chrome, google earth, google talk, etc?</pre>VivaceNaaris: <pre>Go has no language-native solution for building desktop user interfaces. There are projects out there that aim to be cross platform, but they all interface with C/++ APIs and libraries of the operating system. Though, this has been the case for many other languages. Now if you're talking in terms of performance, when using Go and these UI projects effectively, the language can work quite well. But this depends on a lot of things in your software requirements. At the end of the day, the two languages are hard to effectively compare as is the case for most other languages out there.</pre>Sythe2o0: <pre>There are several desktop graphics projects in Go that do not use C++ APIs.</pre>albgr03: <pre><blockquote> I don't think the Go creators ever saw Go as a replacement for C/C++ in anything low-level, although it can be done. </blockquote> Depend on what you call “low-level”. A managed, garbage collected language such as Go can be a no-go in a lot of domains.</pre>jerf: <pre>Rust is already a better C++ replacement than anything that could be called Go 2 would ever be. This is because of a difference in goals, not "goodness" or something. Every language designer must face tradeoffs between the costs of a new feature and the benefits it will bring to the language. C++ and Go sit on opposite ends of the spectrum. Go is quite possibly the language that demands that all of its features give the most before being included in the language of the entire set of "commercially viable languages" out there; I literally can not think of any other designers that demand more from their features before putting them in. And C++ is all the way on the other end of the spectrum; C++ is probably the most complicated "commercially viable language" in existence after repeated releases of standards that introduce new features upon new features that interact with all the old features in insane ways, and even more surprising, I see no evidence that the C++ designers intend to stop anytime soon. There's no way something from the Go process could "replace" something designed by the C++ process. I mean, obviously I like Go for some purposes or I wouldn't be here. But it's never going to be like C++. I consider the C++ designers at this point as basically insane for not either freezing C++ or admitting that they really want to design a C++++. (Call it C+4.) Rust is not that crazy. They are more willing to put things in, but they use a sane standard. Still, they're a lot more willing to try things out than the Go designers, because, well, that's true of just about everybody. I don't expect that the very highest performance code is going to be in Go. If you look at performance per developer effort, Go has a really sharp takeoff on the curve compared to a lot of languages (the "dynamic" language's best performance at the high effort end is below Go's "initial prototype" in a lot of cases), but part of the price it pays for that is that it does plateau out before C, C++, Rust, etc. on the high-effort end of the curve. Fixing that would pretty much inevitably require making the early part of the curve much less performant, and that would eliminate one of Go's big selling points. The early part of Go's performance-per-effort curve is unique among the "commercially viable languages" right now. (I've seen other languages that IMHO have similar curves but none of them have ever gotten Go's level of support to where I can say to my boss "Hey, I'm going to work in X" and he's not going to blink. YMMV.)</pre>brokenprogram: <pre>Rust lacks simplicity so I would expect a different approach from Go. I actually want Go<2> to replace C not C++ if that makes sense. I want to use Go on low level stuff...that's all. I don't want templates, concepts, generics and other fancy stuff from C++. I'm fine with the current Go abstractions. I'm sure that if there would be a good enough replacement for C very few would use C++ or look for a C++ replacement. </pre>jerf: <pre>It's going to be tough for Go to replace C for some of those things, because Go has a more complicated runtime than C (which, contrary to popular belief, does have a runtime environment which is very much not neutral, but it is still simpler than Go, plus it tends to be the "default" for almost all OSes) and the garbage collection also implies it is relatively difficult to plug things in. But if you mean "low-level" executables rather than device drivers, I do expect it will get there.</pre>programming_acct: <pre>A garbage collected language cannot replace C. Go's abstractions are built around it being garbage collected. The thing you want is impossible. Now if you said you wanted a "Go-like simplistic language with manual memory management" you'd probably be onto something. But that language already exists: it's called C. </pre>brokenprogram: <pre>What about a Go dialect/subset that can be isolated and works perfectly with the rest of Go code? Something better than Go to C via cgo...i.e. something like the Go 2 -> Go 1 integration(that from what I hear will be seamless).</pre>programming_acct: <pre>It's funny you same that because I had the same thought after I posted my comment. A really excellent C interface would go a long way. </pre>drvd: <pre><blockquote> As far as I understood initially Go was designed to replace C++ [...] </blockquote> What lead you to this understanding? Go addresses several pain point C++ has, but I doubt anybody really thinks of Go is the language to replace X (for whatever X). Use Go where it fits, use C++ where appropriate, use FPGA where sensible, use Python if it offers benefits, etc. pp. Same for Go 2.0 (whatever that means to you).</pre>brokenprogram: <pre>Sure but it wouldn't be that bad if Go 2.0 would address a bit more use cases and implicitly pain points of C++. cgo is not that great, you know? Neither os.Exec. It is just better than writing the whole thing in C++ but I would definitely to replace that c++ program with a pure Go package if the language would allow it. </pre>shovelpost: <pre><blockquote> As far as I understood initially Go was designed to replace C++ (at least at Google) but proved better fit to replace python and its friends(great thing for some of us). Is this noble goal still valid for Go 2.0? Any chance we can develop real time high performance apps, drivers, codecs, transcoders etc in Go 2.0 instead of C/C++? </blockquote> I am afraid you have misunderstood the design goals of Go. Please read these two articles: <ul> <li><a href="https://talks.golang.org/2012/splash.article" rel="nofollow">Go at Google: Language Design in the Service of Software Engineering</a></li> <li><a href="https://commandcenter.blogspot.gr/2012/06/less-is-exponentially-more.html" rel="nofollow">Less is exponentially more</a></li> </ul></pre>faiface: <pre>I think Go is already suitable for high-performance, real-time stuff. Garbage collector is blazingly fast, at most 100 microseconds of pausing. I'm working on a real-time audio low-latency audio library. We have MP3 audio codec, and on-the-fly audio processing, such as resampling (which is not the least expensive thing). No problems with Go so far. Actually, all of the performance problems we are facing come from C/C++ libraries, such as OpenAL (it's slow with real-time). We are incrementally switching to lower-level audio backends, such as ALSA and with that, there are no performance problems whatsoever.</pre>albgr03: <pre>GC pause is not the only characteristic to consider. </pre>Sythe2o0: <pre>What else would you consider?</pre>albgr03: <pre>I recommend you to read <a href="https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=b965bfa03ee7" rel="nofollow">this article</a>, which explains it better than I could.</pre>brokenprogram: <pre>The go routines scheduler among other things...?</pre>Sythe2o0: <pre>Stop, please don't go on another tangent about some other thing, I don't want to read your same arguments a ninth time. I am asking the person I am replying to, not you.</pre>brokenprogram: <pre><blockquote> I think Go is already suitable for high-performance, real-time stuff. Garbage collector is blazingly fast, at most 100 microseconds of pausing. </blockquote> Obviously 100 microseconds of pausing is not real-time. At least not in the low level world. I don't think you will see vendors such XMOS providing Go SDKs with "high-performance, blazingly fast" ~100 ms pauses. Right now if you are using Go for a/v stuff most will tell you're using the wrong tool for the job. Even the bindings (i.e. to ffmpeg) are quite costly if performance and resource usage is a major concern(not to mention that cgo is not Go). I found this the hard way and ended-up with os.Exec to ffmpeg cli. And yeah you can be sure that the requirements for the next ethernet driver won't include a "blazingly fast 100 ms pausing". </pre>egonelbre: <pre>ms != microsecond</pre>brokenprogram: <pre>It doesn't really make a big difference as far as the domain problem is concerned. It's either real time or it's not. <code>Blazing fast ~x pause</code> it's not real time at all. Go make the case to use Go instead of C for the next video codec (i.e. AOMedia Video 1) and let me know how it goes...</pre>egonelbre: <pre>100ms vs 100us, is the difference of it being usable in real-time audio and not being usable in real-time audio. Probably still not suitable for professional/high-end use, but 100us makes it usable in hobbyist scenario.</pre>brokenprogram: <pre>My main concern is that you have no guarantee on that 100ms or 100us latency. Nevertheless in a hobbyist scenario it could work just fine. It's all about the requirements but when I think about real time I usually think about constant or at least bounded delay. </pre>faiface: <pre>microsecond and millisecond is a big big difference</pre>faiface: <pre>Our MP3 decoder is pure Go and we are able to play while decoding and resampling on the fly with <1/100s latency with 0 underruns. EDIT: and even simulating doppler effect... all on an 1.9GHz i3 CPU without using parallelism</pre>brokenprogram: <pre>Ok then, but can you play it at zero latency?Or is there even a guarantee it will always play at 1/100s latency? I feel this discussion can't end well so I won't argue with you anymore! After all there are java a/v libraries too and it seems they work just fine for some people so good luck with your pure real-time blazing fast ~1/100s pause Go audio decoder! <blockquote> <blockquote> EDIT: and even simulating doppler effect... all on an 1.9GHz i3 CPU without using parallelism </blockquote> </blockquote> Edit: Well if you use Go "parallelism" you will get real time for sure!</pre>faiface: <pre>You can't really do zero latency, not even with C. Btw, we can also do 1/200s, or even 1/1000s if you don't do much audio processing. (Latency depends on the buffer size, with too much processing, you need to increase buffer size to avoid glitches.) This latencies are really good, even compared to what you can do with C. OpenAL could barely do 1/20s when streaming on-the-fly. (But OpenAL is not really designed for streaming.) Btw, you can try it for yourself here: <a href="https://github.com/faiface/beep" rel="nofollow">https://github.com/faiface/beep</a> Notice: such good latencies are currently only on Linux, but we are working on other platforms.</pre>brokenprogram: <pre><< Buffer size determines the stability and responsiveness of the playback. With smaller buffer, you get more responsiveness and less latency. With bigger buffer, you get more stability and reliability. Just read the repo doc and it seems that the real-time and low latency is kind of variable... That's the issue with GC... you don't know the latency...you may test it but you never know it. So the ~1/200s, or ~1/1000s latency you advertise is actually a ballpark figure based on different factors including the Go runtime mood. Can you get a certificate such AVB / AVB TSN [0][1] with this kind of numbers? Would you sell stuff bundled with Go a/v processing? Why would I buy your a/v processor with variable latency instead of something with fixed latency? It won't even be cheaper than the C processor because Go required more expensive hardware than C. I never said that you can't do audio processing with Go. I've just said that Go is not the language to use if you want to make money out of A/V stuff(i.e. processing). Better said it's the wrong tool if you are using it for commercial applications. No sane company would put Go in a a/v box. [0] <a href="https://en.wikipedia.org/wiki/Time-Sensitive_Networking" rel="nofollow">https://en.wikipedia.org/wiki/Time-Sensitive_Networking</a> [1] <a href="https://en.wikipedia.org/wiki/Audio_Video_Bridging" rel="nofollow">https://en.wikipedia.org/wiki/Audio_Video_Bridging</a></pre>faiface: <pre>The claim about buffer size and stability / responsiveness is valid both in C and Go. It has nothing to do with the GC or the language. Once you set the buffer size to 1/100s and you get no underruns, you have 1/100s latency, it's a precise number. Once you get underruns, of course, this doesn't hold, but, you get underruns when you do too much processing with too low buffer size in both C and Go, it's really not the GC problem.</pre>Sythe2o0: <pre><blockquote> I never said that you can't do audio processing with Go. I've just said that Go is not the language to use if you want to make money out of A/V stuff(i.e. processing). Better said it's the wrong tool if you are using it for commercial applications. No sane company would put Go in a a/v box. </blockquote> You never said what you claim to have said here. Why should we think you are being legitimate in your concerns?</pre>brokenprogram: <pre>Well all I said is that as it is now you can't have guaranteed latency with Go and as you might be aware real time a/v processing is about latency. That being said a language which cannot provide any mechanism to control the latency cannot be considered a good candidate for real time a/v processing. It is a no brainer. If your product features "real-time" it is supposed to also feature a fixed latency or in the worst case a guaranteed latency range. In multi-channel systems you usually deal with a lot of stuff such transcoding, dsp, switches etc...all of them add some latency. My personal opinion is that the system will not sound/play nice if is developed in a language which cannot provide predictable performance/latency. I don't think any recording studio would tolerate such stuff. I actually think the issues would be visible for consumer products too (e.g. the speakers/channels will run out of sync and chances are you will get a/v lip sync issues too or just buffering pauses<whatever you prefer to trade off> ) Now about legitimacy, I'm not sure I understand what you mean. Do you think Go is great for real time stuff and I just make up arguments because of some mean reasons? Do you know any way to achieve fixed/predictable latency in Go? I feel I should have better kept this question/concern for myself as it was received with repulsion. The bottom line is that you can do some a/v stuff in Go (i.e. webrtc) just like you can in JavaScript, python or any other language but you can't compete with C/C++ or dialects(i.e. XC). </pre>Sythe2o0: <pre>You never mentioned anything about money before this post I quoted. Why are you saying you did.</pre>brokenprogram: <pre>I don't know what you are talking about. The point is that any solution developed with Go right now is subpar compared with a C solution. That's because you can't get any predictable latency in Go. You are dealing with a GC which pauses and collects as it pleases. The behaviour of the GC can change from one version to another. The money argument was there just to reinforce the fact that in order to make Go competitive in the A/V industry it requires changes so that it can compete with other languages(i.e. C/C++). If we talk about your hobby project then any language is good enough for a/v stuff.</pre>bupku5: <pre>there is no such thing as guaranteed latency in any popular operating system</pre>brokenprogram: <pre>I believe one such OS is linux which may be quite popular(depending of what popular means to you) and it provides predictible latency<with some patches of course> <a href="https://wiki.linuxfoundation.org/realtime/start" rel="nofollow">https://wiki.linuxfoundation.org/realtime/start</a></pre>Sythe2o0: <pre>Why are you continuing to edit this post, repeating yourself, and still not answering my question? This just reinforces that I should think you are a troll.</pre>brokenprogram: <pre>heh? Now I think you are not worthy of an answer. Even so whatever question you had I already answered. Why should I repeat myself one more time? </pre>WikiTextBot: <pre>Time-Sensitive Networking Time-Sensitive Networking (TSN) is a set of standards under development by the Time-Sensitive Networking task group of the IEEE 802.1 working group. The TSN task group was formed at November 2012 by renaming the existing Audio / Video Bridging Task Group and continuing its work. The name changed as a result of extension of the working area of the standardization group. The standards define mechanisms for the time-sensitive transmission of data over Ethernet networks. <hr/> Audio Video Bridging Audio Video Bridging (AVB) is a common name for the set of technical standards developed by the Institute of Electrical and Electronics Engineers (IEEE) Audio Video Bridging Task Group of the IEEE 802.1 standards committee. This task group was renamed to Time-Sensitive Networking Task Group in November 2012 to reflect the expanded scope of work. The charter of this organization is to "provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks". These consist of: IEEE 802.1BA: Audio Video Bridging (AVB) Systems; IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications (gPTP); IEEE 802.1Qat: Stream Reservation Protocol (SRP); and IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams (FQTSS). <hr/> [ <a href="https://www.reddit.com/message/compose?to=kittens_from_space" rel="nofollow">PM</a> | <a href="https://reddit.com/message/compose?to=WikiTextBot&message=Excludeme&subject=Excludeme" rel="nofollow">Exclude me</a> | <a href="https://np.reddit.com/r/golang/about/banned" rel="nofollow">Exclude from subreddit</a> | <a href="https://np.reddit.com/r/WikiTextBot/wiki/index" rel="nofollow">FAQ / Information</a> | <a href="https://github.com/kittenswolf/WikiTextBot" rel="nofollow">Source</a> ] Downvote to remove | v0.26</pre>faiface: <pre>And regarding the guarantee. If the processing doesn't keep up with the playback, underruns occur. We can detect them. Since 0 underruns occur (if you don't do anything too crazy), 1/100s latency is "basically guaranteed", I can't prove it, but it just works.</pre>brokenprogram: <pre>It just works until it stops working...I know how it works :). Good luck with your project though! I may use it as I love Go but I'm just saying it will never be able to compete with C/C++ in real time a/v processing<unless Go changes/improves> . It may compete with some badly written C/C++ but not with the top notch. It just can't. Without guaranteed latency it's just a guessing game and sometimes you want/need things to work perfectly without Pops, clicks, crackles, dropouts, distortion or latency between channels. I don't think you can afford that guessing game if you organise concerts or run a movie theater and to be frank I don't think you want that on a home theater either especially when you have alternatives. A Go solution is good up to the point when you need to sell it in a product and compete with the alternatives. Even C lacks some stuff to be great for a/v (see XC[1]) so you can just forget Go1.x. Can Go play some mp3 on your desktop...? maybe... but let's not argue that makes Go a good fit for real time a/v processing. [1] <a href="https://en.wikipedia.org/wiki/XC_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/XC_(programming_language)</a></pre>shazow: <pre>This is kind of a super-deep subthread but I wanted to sneak in one more point to further support <a href="/u/faiface" rel="nofollow">/u/faiface</a>'s side: The GC only really applies when you have memory that needs to be collected. It's perfectly possible (and fairly easy) to write low-level code that avoids allocations and re-uses buffers which makes the GC pauses practically non-existent.</pre>brokenprogram: <pre>You can write low-level code that avoids allocations and re-uses buffers but they won't make the GC pauses practically non-existent because even for these buffers you re-use you have no guarantee provided by Go compiler/language(AFAIK) that they won't be collected. Correct me if I'm wrong<citation/spec required>. Most likely your decoder will have multiple go routines scheduled as the go runtime pleases so your decoding routine with the perfectly reusable buffer may be paused by the runtime and you can't do anything about that. So if there is will to make Go a better fit for A/V processing we need some guarantees/real time "features" thus my request to make Go better fit for low level ops such a/v processing and driver development.</pre>shazow: <pre>The 100 microsecond benchmark is supposed to be worst case—cases where GC is longer than that are generally considered bugs. Here's the announcement: <a href="https://groups.google.com/forum/m/#!topic/golang-dev/Ab1sFeoZg_8" rel="nofollow">https://groups.google.com/forum/m/#!topic/golang-dev/Ab1sFeoZg_8</a> With minimal allocations and buffer re-use, in practice, the GC pauses are at least an order of magnitude shorter than that. Anyways, if you can't tolerate the GC and you're reusing all of your memory, then you can disable it: <a href="https://golang.org/pkg/runtime/debug/#SetGCPercent" rel="nofollow">https://golang.org/pkg/runtime/debug/#SetGCPercent</a> My point is that multiple people are using Go in practice in low-latency scenarios and it's largely fine. I'm sure there's always room to improvement, but it doesn't help to debate this from some hypothetical not-enough-guarantees position. If you'd like to provide some code examples where Go doesn't perform well enough, we can talk about how to improve the scenario or file some bugs against Go.</pre>brokenprogram: <pre>My point is that if you don't have any guarantee about the GC latency then you can't provide any guarantee on your program latency either. It's just like you would deploy a web service on a cloud platform with no SLA and you would try to provide a SLA to your end customer based on the usual uptime/latency. It's not about hypothetical scenarios it's just that the lack of any guarantee. Sometime around go 1.4 the GC and scheduler gave me enough troubles to loose any any confidence in its "average latency" and I don't see any reason to trust this latest version of GC more. It has better latency for sure but any guarantee on that latency? The story is same as far as I'm concerned. I would love to see a project that works with the GC disabled. Can you provide a link to any public one? Never knew that you can actually disable the GC<except for debug>. Can you use Go routines? I can't hardly see Go working without GC considering that at some point you need to release memory in your program. Ideally you would like to disable GC on package/lib level. </pre>ctcherry: <pre>For non existent GC pauses, the GC system can be turned off entirely with env variable GOGC=off <a href="https://golang.org/pkg/runtime/" rel="nofollow">https://golang.org/pkg/runtime/</a></pre>brokenprogram: <pre><blockquote> For non existent GC pauses, the GC system can be turned off entirely with env variable GOGC=off </blockquote> I think this argument has been made before but I never seen a program with the GC off. I actually don't think it's feasible to write a such program. I think the option is for debugging only. </pre>faiface: <pre>I still disagree. You flush audio data 100x per second. GC pause takes at most 1/10000s. That's at most 1/100 of the time you have to process the audio data before flushing. Now, if you actually only use 5-10% of that time and you're sleeping/waiting for interrupts for the rest (which is the usual scenario if you do decoding), it's kind of guaranteed that you'll make it. I don't know the definitions of guaranteed, but this seems quite guaranteed to me. EDIT: there are different kinds of real-time requirements. Of course, Go is not suitable for the strictest. But audio and video are not the strictest.</pre>brokenprogram: <pre>I need to correct you again that you have no guarantee on the GC latency. You have a ballpark figure on a specific input. You can't get any time sensitivity certificate when you have no latency guarantee on the GC so let's keep Go at the hobby status for a/v for now and everybody is happy. Without latency guarantees you can't sell PRO stuff. That's a fact. Would someone buy your a/v processor with unknown latency or something like this[0] with <code>network latency is an astonishing 0.625ms(fixed), even over 7 "hops"(switches)</code> ? (btw this kind of stuff can stream 500 channels simultaneously). I'm warning you that even the entry-level/low grade a/v processors have fixed latency so in a/v industry fixed latency is not really a luxury item anymore, it's a must. Audio and Video are some of the most sensitive things when it comes to latency. Latency can basically ruin any multi-channel experience and so the lip sync. You can try to sell a/v solutions developed in Go but I'm warning you that they won't sell that well. Btw some time ago I've tried to develop a roku-like player with improved a/v capabilities in Go... now it's a mix of Go and os.Exec so you can be sure that I want to believe you can do a/v processing in Go but it's just not the case. [0] <a href="http://motu.com/products/avb/16a/networking.html" rel="nofollow">http://motu.com/products/avb/16a/networking.html</a></pre>faiface: <pre>I'm not selling anything, I'm making an open source software, and it's working better than OpenAL for what I'm doing (which includes some preliminary 3D audio too), and I'm confident it will continue to work better than OpenAL. OpenAL is pretty successful.</pre>brokenprogram: <pre>If it works for you then it's already a success and I wish you the best. More people working on stuff like this will definitely push Go in the right direction. If you think your project would benefit from any change/improvement to the language try to put it on Experience Report[0] as now there is a rare chance to propose language changes. [0] <a href="https://github.com/golang/go/wiki/ExperienceReports" rel="nofollow">https://github.com/golang/go/wiki/ExperienceReports</a></pre>Kraigius: <pre>And me who thought that they initially only wanted to make it as fast as C++, not replace it.</pre>brokenprogram: <pre>What can be faster than C++?</pre>Sythe2o0: <pre>Fortran</pre>Kraigius: <pre>Well, I said as fast so it's more of aiming to be very close in term of performance if not equally fast, not faster.</pre>ruertar: <pre>Do you have a reference to that notion that Go was supposed to be a better C++? I think that is actually a pretty low bar in either case.</pre>brokenprogram: <pre>The story is somewhere if you google it. I think the bottom line is that Go was designed as a better alternative to C++ for stuff its designers did in C++ at Google. One major problem they had with C++ was the compile time, another was the complexity of the language.</pre>tty5: <pre><blockquote> As far as I understood initially Go was designed to replace C++ (at least at Google) </blockquote> Go was designed to replace C++ in places where C++ was only used instead of Python out of necessity. They haven't designed an all purpose C++ replacement, they designed a Python replacement good enough they don't have to write C++. If you're looking for a potential C++ replacement as a system programming language then Rust fits the bill better.</pre>brokenprogram: <pre>Rust can definitely replace c++ though I think the issue I have with Rust is that it looks too much like C++(complexity like). I would rather prefer a Go dialect with powerful/low level features as C. That would check all the checkboxes: simplicity, abstractions and power. Most people hate C++ for its complexity. I don't think that they will all be happy developers if C++ committee will release a barrow checker with guaranteed memory safety(a`la Rust) in the next version( C++20 ). </pre>aboukirev: <pre>D might be something to check out. Does not have a large community but supports both GC and non-GC applications, has a fast compiler (dmd), is powerful (check its metaprogramming capabilities), and is simpler than Rust. I still prefer Go for what I do.</pre>tty5: <pre>Go is garbage collected, which effectively rules it out as a low level systems language.</pre>brokenprogram: <pre>So we are back to square one...</pre>tty5: <pre>well, AFAIK go was never meant for system programming (such as drivers)</pre>kaeshiwaza: <pre>It's in fact an easy valid problem to report !</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题