πŸ‘€MrBuddyCasinoπŸ•‘12yπŸ”Ό238πŸ—¨οΈ273

(Replying to PARENT post)

I find it amusing that there isn't a single word about runtime performance in the whole essay.

In the end, when I code in C++, it's because I believe my code will run faster and generally use less resources, and I'm ready to accept the sacrifices it takes (in terms of my own time) to get there. Does it make me someone for whom software is about "doing it in a certain way" ? Probably. If that certain way is "performance" for problems where it matters, I'm even proud of it.

C++ programmers don't come to Go because it turns out Go doesn't shine on problems where C++ was the answer. Simple as that, and there's nothing wrong with that, as long as Go found its niche and solves some problems relevant to him. I'm not sure I see why Rob Pike needs to be so dismissive.

πŸ‘€WilyaπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way.

The issue, then, is that Go's success would contradict their world view."

This, "they can't handle how awesome it is" is kind of a fun rationale and strikes me as plausible, but it would be more interesting to me to hear from some of the stellar c++ programmers at google as to why they aren't interested in switching.

C++ was the first language I really invested in mastering during and after college - it was like, "all I need to do is read these 5 books about how to avoid the pitfalls and use all the powerful tools, and it's amazing!" What really changed my mind was trying other languages (first python) and seeing how immediately productive I could be without so much as skimming through the "dive into python" website. So specifically, I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea.

πŸ‘€krosaenπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

If C++ programmers were attracted to making their language more elegant and safe yet more powerful at the same time they would have switched to any of the statically compiled, typesafe, managed languages years ago.

If Rob Pike was doing things in C++ that Go could also solve, that means he could've done them in C# or in Haskell too, which means he shouldn't have been doing them in C++ in the first place. (Strousup explains why in his recent GN keynote if you doubt that)

Of course solving that problem by inventing a new interesting language without any of the (psychologic) baggage those other languages is awesome. It seems to be rather succeful, but it's naieve to think that it would attract C++ programmers, there's just nothing in there for them. The C++ programmers who are looking for change have more to hope for in for example Rust.

πŸ‘€tincoπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. ... The issue, then, is that Go's success would contradict their world view."

No it won't! I'm excited about Go. What I've read about it makes it look like a language I would love to work in, some day. However, I don't think the problems I'm solving now are the problems Go is good at solving. The programs I'm writing run on one machine with restricted memory, and they need to be highly, highly performant. The execution time is measured in tens of milliseconds, and during that time we do a lot mathematics and processing. SIMD is our close, beloved friend. In that context, I don't think Go is an appropriate language, due to its garbage collector, its lack of precise control over where objects go in memory, and the overhead of method calls. But if I ever write code similar to that written by Google, C++ would be a terrible choice.

I was all on board with what he was saying until that last little jab. I'm not migrating to Go because I have problems that Go doesn't set out to solve, but I'm not threatened by Go, because it's just another tool. Having more high-quality, carefully-designed tools is never a bad thing, and I can't imagine ever being threatened by a new tool's success.

Honestly, this smacks of more divisive bullshit. Pythonistas vs Rubyists, VIM vs Emacs, and now, Go vs C++. Blurgh.

πŸ‘€epi8πŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Well, he admits he was never very at ease with C++, so I guess he can be forgiven for not understanding very few C++ programmers are going to jump into a garbage collected language. If they were, they would have moved long ago. Most of the times you need C++ nowadays are because a GC language simply won't do.

Kind of silly he drew up his language based on one Google need and thinks everyone using C++ should just jump aboard, though. He acts like he studied why people were writing in C++ and took their use cases into account instead of just his own. Kind of a stereotypical engineer who writes an app for themselves that utterly fails in the consumer market because it is written by coders for coders with weird controls.

πŸ‘€lnanek2πŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

For those who don't know who Rob Pike is, he's pretty awesome, helped create UTF-8 among other things, and now works on Go.

http://en.wikipedia.org/wiki/Rob_Pike

He has given some really great Go talks which are available on youtube, about an hour each:

Origins of Go Concurrency Style - http://www.youtube.com/watch?v=3DtUzH3zoFo

Lexical Scanning in Go - http://www.youtube.com/watch?v=HxaD_trXwRE

Go Concurrency Patterns (One of my favorites) - http://www.youtube.com/watch?v=f6kdp27TYZs

πŸ‘€canthonytucciπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Actually I've looked at Go and it seems like a really shoddy step forward (as opposed to say D), but thanks for being so condescending about it.
πŸ‘€nfozπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

We are all waiting for Mozilla's rust to mature. Rust seems more in-line with C++'s "you only pay for features you use" and more general purpose.

I wouldn't use go for numerical simulations but it certainly shines for writing network servers.

πŸ‘€nimrodyπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

There is one feature of go that prevents me for considering it when I want to write "low level" code: garbage collection.

It's probably very silly but in my mind that puts it next to Java, above C and C++ in the "grand scale of programming languages".

Oh, and also I don't like garbage collection, so there's that. I'm sure some day someone will explain to me what's the point of it because I still don't get it.

πŸ‘€simiasπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

C++ programmers don't go to Go because Go occupies the space otherwise taken by Java.

The only real, modern alternative to C++ is Rust, but it's not at 1.0 yet, meanwhile C++ is still getting new features, all the while preserving compatibility.

πŸ‘€Mikeb85πŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

What really gets me about go is that it's lame, manual error handling sucks, causing it to be smack dab in a middle area between my current languages of c++ and python. If you don't believe me, note that golang.org's home page example lacks error handling (huge fail).

In c++, I like the predictable destructor model of memory cleanup, and am willing to pay the manual error checking price (too scared to write exception safe code in c++). But I like to put as much complex logic in python code, due to its nice exception handling and GC.

If GO had a more flexible exception model, which by the way does not require forward jumping try/catch constructs, making it easier for people to write 'crash only' error handling without boiler plate, I might consider it. But for me, it's currently typecast as a firmly middle of the road feature set.

πŸ‘€penguindevπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Once again, Rob Pike speaks about generics and types in terms of C++ and Java, without acknowledging any other languages with static type systems, some of which are more expressive, less verbose, or both.

Surely Rob Pike is not ignorant of ML (1973), Ada (1980), Eiffel (1986), Oberon (1986), Haskell (1990), OCaml (1996), C# (2000), and F# (2005)?

See also the comments on http://research.swtch.com/generic

πŸ‘€mietekπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Most programmers aren't in the latest-language bubble. Hell, my main earning language right now is PL/SQL, which limped out of the shadow of Ada, minus all the interesting bits, clutching hideous licence fees.

The reason Ruby and Python programmers have embraced Go is because they tend to be in the latest-language bubble.

The actual properties of the language are probably nearly totally inconsequential, except as bright lights that attract a certain sort of mind to it.

πŸ‘€jacques_chesterπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Less is more, but my ideal 'less' probably isn't your ideal 'less'. That's why we need more... so we can all have less.

C++ covers many domains and programming styles really well. Just because it doesn't cover some as well as some other language, it doesn't mean C++ as a whole is a lost cause. This is true no matter how many domain experts and language advocates attack it. It's C++s huge scope that opens it up to attacks from every corner in the first place.

Frankly I'm getting tired of reading articles from people who think they can proclaim "what C++ is about" any more than I can proclaim "what Go is about" or "what Python is about". Even Bjarne himself admits he doesn't know all the ways in which people use C++, and that's how he likes it.

πŸ‘€nlyπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I think a lot of programmers don't come to Go for the same reason that I don't see myself ever using the language - it's far enough from a C-like language in syntax and ideology that it's not easy to move from the C family to it, and it has some "features" that I do not consider features. Those features make it taste like an academic language, what isn't what I'm looking for in a programming language.

Rust seems very different in that regard, and I look forward to being able to use it in production when the time is right.

πŸ‘€debacleπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I'm a serious C++ programmer, and I'm also in the Rust boat, rather than the Go boat. I've tried Go. More than once. And each time, I feel really restricted. I feel like I have to solve problems a certain way, rather than the way that fits the problem. With C++, I have multiple approaches to solve a problem, and can choose the one that offers the best trade off of performance and maintainability.

For now, if I'm really wanting concurrency, and don't feel like C++ is doing what I need, I'll grab Java/Scala with Akka. They allow me to create a solution tailored to a problem, rather than tailoring a problem to a solution.

πŸ‘€dbcfdπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

A language which had aimed for system programing but not fast compared with C++, now aims for web programing but still harder to use than script languages, static typing but no generic types, forces boilerplate in several aspects (exception, assertion) but no meta programing ability to help fix it, weird design decisions dictated by personal experience, has Google helped marketing but still not widely accepted.
πŸ‘€luikoreπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Imho the main thing C++ offers are cheap abstractions. In C++ you can easily build abstractions that do not have any runtime overhead at all. You can write beautiful and general code and still not sacrifice a single cycle for it. Go doesn't offer that, not in the least. As such I think that Go and C++ simple have a very small intersection when it comes to use-cases.
πŸ‘€nikicπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"Less is More" works when you have fewer components but you can assemble them together in various combinations to do everything you could otherwise do with more components.

However, when you have fewer components which can't be combined to achieve certain things that you could do earlier, it is hard to see how you can then say "Less is More".

Coming from game development RAII is a blessing. Not having control of memory deallocation is will not sell. This is definitely not a case of "Less is More", it's a case of "Less is Less".

πŸ‘€bloodorangeπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

So it seems that C++ programmers are a bunch of silly self-centered people who cannot think as good engineers because somehow they have all been brainwashed (probably by Stroustrup). That is how I read it.

Ah, by the way, did anyone mention garbage collection?

πŸ‘€pfortunyπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"It seems almost paradoxical that other C++ programmers don't seem to care."

It probably doesn't scratch their itch.

πŸ‘€sigzeroπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I've tried Go for some small stuff and read through "Programming in Go". I want to like it, but it just doesn't work for me. It's at an awkward position half way between C++ and Python. Knowing both C++ and Python, I don't see a convincing reason to use Go.

IMO, part of the reason C++ programmers aren't interested in Go is that C++ is, arguably, the most difficult language to learn. If you're really good with C++ you'll figure out most other languages fairly easy, and probably already know a few languages before going to C++. So I would expect most C++ programmers already have a "go to" scripting/interpreted, high level language that they know and like. And in that case Go just doesn't offer anything they don't already have.

πŸ‘€jlaroccoπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I'm not a C++ guy, but I will say the most interesting thing about Go to me is that it's a smallish, clean, staticly-typed language that gives a great day-to-day development experience. It also comes with a lot of nice tools for formatting code, documentation, dependency management, etc.

Switching from Ruby or PHP is pretty easy because you get the same (or better) developer experience with excellent performance and nice built-in libs. For writing web services, Go is pretty much ready to roll out of the box.

I think writing Go is fun. I'm not sure that it matters why other programmers do or don't like Go. I think it's great.

πŸ‘€programminggeekπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

πŸ‘€akkartikπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

TL;DR - Rob finally realized Go is a flop, and nobody wants to use it for serious programming work. So, he whines about it, and blames C++.
πŸ‘€aureliusπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

For me it's not about the language. It's about pragmatics.

With C++ I can write code that builds natively using standard tool chains and libraries on Linux, Mac, Windows, iOS, Android, and dozens of other less common platforms.

With C++ I can write something once and then ship it on all those things without worrying (much) about the availability of tooling. If I write it using portable programming techniques (mostly acquired through hard experience) I will not have to do very much porting, and the #ifdef mechanism provides an acceptable way to accomplish alternate code paths on different platforms without compromising cleanliness of the build or performance.

C++ has its uglies, but it's not too bad if one knows it well and avoids various also-learned-through-experience antipatterns.

Go is in fact better than C++, but it's not better enough to justify the hassle or the impact in my ability to ship across umpteen platforms.

This is why everyone still does systems programming in C/C++. Write (a bit painfully) once, ship everywhere.

Other languages like Go, Ruby, Python, Rust, server-side JavaScript, various functional dialects, D, whatever, always achieve success in two areas: specific ecosystems/platforms (e.g. ObjC on Apple, Haskell in the world of high-speed algorithmic trading), and server-side coding. With server-side coding who cares if you can ship, cause you don't. But all the world is not a server, and sometimes you want to hit multiple user bases. For that, only C will do.

I actually think a Go (or any other language) compiler that builds to cross-platform C code with a configure script and a Windows build script would be a worthy development. I know many people hate language-to-language compilers, but this would enable one to write in nifty new language X, build intermediate code, then build that intermediate code with the native tooling of every other damn thing.

The other alternative would be for Google -- if it really wants to push Go -- to put a lot of effort behind porting it to offer good high-quality native tooling for everything and everyone's toaster oven. But Google thinks all the world's a server or a browser (and it is for Google for the most part) so that doesn't seem to be a priority for them.

πŸ‘€apiπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Rob Pike did not aim to replace "C++", but "C++ as he used it at Google". Looks like he succeeded at that. For those problems garbage collection is a good idea (did the C++ guys try Boehm?) and compilation time is critical. From the article: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

I agree with most of what Pike says until the end, where he derides C++ programmers:

"C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way. The issue, then, is that Go's success would contradict their world view."

This is just wrong. They do not come, because Go simply does not fit the requirements. Go is more opinionated and targets a smaller niche than C++. Nothing wrong with that. If Go and C++ both fit your requirements, Go is probably the better choice.

The only language I know, which explicitly targets C++ is D, but it is not there yet completely. Though, depending on your needs it might enough and it is an improvement over C++.

πŸ‘€qzncπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Sometimes I feel like I'm the only guy that likes and works in C. Then I see TIOBE index and alike and see C on top always. Are we, C programmers, not vocal or are those metrics skewed in favor of 'legacy' and existing code?
πŸ‘€KeyframeπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

In a corporate environment (particularly that corporate environment), the option of enforcing "we don't have to use the whole buffalo" exists. That is, you can say "these parts of C++ are off-limits for this code base", and be reasonably sure it will stick. See also: exceptions.

You could do that. Or you could go write a new language and further scatter the masses.

πŸ‘€rachelbythebayπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I'm currently a C++ programmer that does not intend to change to go because I want to have exquisit control.

However, this is not because of my views or something like that but because I'm only a C++ programmer at the moment, because I need that kind of control for my current work. If I want to publish a paper or argue on specifics of algorithms and data structues, e.g., like cache efficiency, it is highly convenient to know as much as possible about what your code does in detail and to have the opportunity to force a particular behavior.

The next time I'll be asked to get a complex problem solved somewhat efficiently (I did write a lot of java code before starting to dive into C++ 3 years ago), I might look into go. But as long as the specifics of my solution are "the job", I can still focus on getting the job done but choose C++ over Go.

New C++ features are always nice, because I don't have to use them all and can cherry-pick whatever is more convenient to achieve what I want

πŸ‘€bjoernbuπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Somehow I miss the biggest advantage of C++ here: you can still maintain a 20 year old code-base without a complete rewrite.
πŸ‘€skriticos2πŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I don't see this as an 'anti' C or C++ article. I see it as an effort to explain (initially to himself) why the phenomena exists. Not sure I agree with all of it but being a C/C++ programmer on micro-computers from the very beginning, much of what is said resonates. I've pretty much be multi-lingual from my start with IBM360 BAL (the programmers version of 'been down so long everything looks like up :) ) That said when I was able to use C (actually a C subset called BDS C [yes BDS does stand for Brain Dead Software]) I immediately set aside PL1, Fortran, Pascal etc. Because I had found a HLA (High Level Assembler) and was as happy as a pig in mud (how happy is that?). That was in the beginning days of the S100 bus and therefore long ago. Since then I accumulated many languages, somethimes for the hell of it (it looked interested), sometimes because the client wished it and sometimes because it was clearly the right choice. The one pattern I've maintained over all of this time is to learn and test the language by writing a parser in it. Not a random one, but a particular problem I was deeply familiar with. The parsing of chess games. It usually winds up a middling tiny sized work of about a 1000 lines and when done I've a reasonable idea of the workings of the language and more importantly how hard it is to write parsers in. Why parsers? Because to paraphrase the wisdom of turtles, 'It's parsers all of the way down...'

This winds up being a windy version of 'I suppose I'll have to try go to see what's what'

πŸ‘€hsmyersπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Less is more. No data mutation. No ordered execution. Go Haskell.
πŸ‘€eonilπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I have similar minimalist sympathies, taking as an ideal Antoine de St Exupery's remark on aeronautical engineering, β€œPerfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

The problem with Pike's work, as I see it, is that what it calls 'simple' I see as unnecessary burdens layered on top. A text editor that makes you take your hands off the keyboard? No thanks. I want to edit text, not pictures of text.

πŸ‘€kpsπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Hopping on my soap box here.. I'd think that the word "exponentially" is used incorrectly in the title. The trend to use cool math terms in everyday language is a something that has been going on over the last few years. It can be very expressive, but it's annoying when it's done in the wrong way.

Something cannot be "exponentially more" than something else. Something can be a factor more than something else (if you have a measure). In this case, if you want to use a cool math term, then you could say something is an order of magnitude more than something else.

The correct way to use the adverb exponentially would be to apply it to a development or a progression. For example, "Moore's law predicts that we'll have exponentially more CPU power in the future", or "This problem gets exponentially harder if the input size increases linearly". It applies to something that changes with an ever increasing rate, not to any specific values in time.

πŸ‘€geertjπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I still use C++ since there still doesn't seem to be a better option for creating cross platform GUI apps than C++ with Qt. Desktop Apps are no longer 'cool' and other than Qt there doesn't seem to be much happening in the Desktop space. For scripting I use lua since it's a lot easier to embed than Python.
πŸ‘€FigBugπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

C++ (and Java in a sense) are kind of a "local optimum" in terms of languages. Go breaks from that, an it's good. It's not necessarily faster (or slower), it's a different way of seeing things.

So C++ programmers think they need "all the speed" of C++ (ignoring all the cases where it's being slower because of the added complexity that C++ programs end up having) and convincing themselves that's the "only true way"

In some aspects that's true, you really shouldn't go for something outside of C/C++ in the embedded world usually (even though embedded systems are getting faster, but there are several specialist systems slower than your smartphone)

But for most apps today? Thanks, but I would try alternatives first.

πŸ‘€raverbashingπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn't just about getting the job done, it's about doing it a certain way."

Nobody can speak for all C++ programmers, but I think the biggest drawback of a transition from C++ to Go is a lack of abstraction power. Not having Generics/Exceptions/RAII is just painful.

πŸ‘€detrinoπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"I believe that's a preposterous way to think about programming. What matters isn't the ancestor relations between things but what they can do for you."

Similarly I can say: "What matters isn't the composition of things but what they can do for you."

Also C++ and Java guys might be coming to Scala instead. Which is not owned by Google.

What is the killer feature of Go that makes it significantly different than C#/Scala or some other popular modern language?

πŸ‘€CmonDevπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Performance is important in another way (I'm referencing the C++ vs go performance discussions here, more than the OP). The more performant you are, the fewer watts you burn. This means phone batteries last longer, and google data centers require fewer power substations. It's a nontrivial concern at any scale. I find blithe 'throw more cores at it' statements rather questionable ecologically.
πŸ‘€RogerLπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

You cannot expect people to replace a language developed and polished over decades with one that barely hit version 1.0. Go is fun to write, has some good ideas, and is a little more readable (in idiomatic form) than C++. But it is new. Once Go has the necessary libraries, and has been thorough tested, then more people will look into it.
πŸ‘€blitiπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

What bugs me most about Go is that it is already filled with internal inconsistencies, and since it practically demands idiomatic usage, these aren't easily avoided. In C++ one can at least avoid using "bad" parts and patterns.
πŸ‘€craigykπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Sometimes you need complexity or extreme performance, and sometimes you need it to stay out of your way. Go sacrifices the latter value for the former value. D and Rust have far more potential to woo C++ programmers.
πŸ‘€saosebastiaoπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

"We didn't figure it all out right away. For instance, it took us over a year to figure out arrays and slices."

And that might be how long it takes me to fully understand the difference.

πŸ‘€transfireπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Didn't we discuss this already last year? https://news.ycombinator.com/item?id=4159703
πŸ‘€mseepgoodπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

There is cgo which allows one to call into C controlled code. That to me is best of both worlds, working in Go when I need to and memory control when needed as well.
πŸ‘€jamesmiller5πŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I'm very dissapointed in Go philosophy... Edpecially about RAII...
πŸ‘€EugeneOZπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

I personally don't like go, because it doesn't have language features, which must be included in any new programming language, I mean generics and exceptions.
πŸ‘€solomatovπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

Simple answer - if we wanted something slower than C++, then we already have Java. If we wanted some more dynamic we have Python. If we wanted something more Brogrammer style, we have Ruby, so what fit is Go good for?
πŸ‘€static_typedπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0

(Replying to PARENT post)

>Go is, I believe, more expressive than C or C++

Really? Why does it always seem like everything he says about go is designed to make people question his grasp on reality? There is no way to reasonably argue that go is more expressive than C++. You might very well feel that the huge increase in complexity that comes with C++ is not worth the comparatively smaller increase in expressiveness, but pretending go is more expressive is simply absurd.

πŸ‘€asdasfπŸ•‘12yπŸ”Ό0πŸ—¨οΈ0