f*ck you, golang

[Roberto Zanotto]

I have to work on a project for an university exam and the professor highly recommends doing it in C++ with (his) FastFlow library. Now, because of Go, I can't stand looking at object oriented code anymore. The way the code is structured... class hierarchies... you can't even tell what the program _does_. My eyes cross and I feel like crying.

I was meant to be a successful C++/Java programmer, now that is ruined forever. And nobody listens to me! A friend of mine recently graduated, we bought him "Design Patterns: Elements of Reusable Object-Oriented Software" and "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14". He wanted those books and said that they are what he needs to learn for job interviews. And everybody agreed.

My life is ruined and it's on you.

[andrewc...@gmail.com]

I know that feel my friend.

[Bakul Shah]

On Thu, 23 Jul 2015 15:19:28 PDT Roberto Zanotto <roby...@gmail.com> wrote:
>
> I have to work on a project for an university exam and the professor highly
> recommends doing it in C++ with (his) FastFlow library. Now, because of Go,
> I can't stand looking at object oriented code anymore. The way the code is
> structured... class hierarchies... you can't even tell what the program
> _does_. My eyes cross and I feel like crying.
>
> I was meant to be a successful C++/Java programmer, now that is ruined
> forever. And nobody listens to me! A friend of mine recently graduated, we

> bought him "*Design Patterns: Elements of Reusable Object-Oriented
> Software"* and "*Effective Modern C++: 42 Specific Ways to Improve Your Use
> of C++11 and C++14".* He wanted those books and said that they are what he

> needs to learn for job interviews. And everybody agreed.
>
> My life is ruined and it's on you.

Go too considered harmful?

[andrewc...@gmail.com]

I get raised eyebrows at my work if I mention Go, Clojure or upgrading our tools in general.

[Roberto Zanotto]

I remember a talk about how Go is used at CloudFlare. The guy was assigned a task and he realized it secretly in Go and the colleagues found out only when it was too late :D

[jammi...@gmail.com]

That was this talk from John Graham-Cumming from the London Go Gathering. He gave another interesting talk at Gophercon 2014 that is also worth watching.

[Egon]

Use/learn pure C, it's closer to Go. Or use only C features from features in C++. Also, try to learn it from games, e.g. "Game Programming Gems" series -- I've found code from game programmers (usually) much easier to read.

If you don't use inheritance you'll avoid a lot of the complexity. Also few additional interesting reads:

http://objology.blogspot.com/2011/09/one-of-best-bits-of-programming-advice.html

http://www.carlopescio.com/2011/04/your-coding-conventions-are-hurting-you.html

+ Egon

[aurelien]

You should keep the things simple. You are able to write in go? ping Google to works for Google :)

+ aurelien

[Skip Tavakkolian]

While suffering may lead to enlightenment, enlightenment guarantees having to suffer fools.

... BTW, the gopher says "you're welcome"

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniël de Kok]

On Fri, Jul 24, 2015 at 12:19 AM, Roberto Zanotto <roby...@gmail.com> wrote:
> I have to work on a project for an university exam and the professor highly
> recommends doing it in C++ with (his) FastFlow library. Now, because of Go,
> I can't stand looking at object oriented code anymore. The way the code is
> structured... class hierarchies... you can't even tell what the program
> _does_. My eyes cross and I feel like crying.

You don't have to write C++ like that. In fact, most (all?) STL
containers do not use inheritance and STL algorithms are implemented
as freestanding functions. Moreover, C++ templates use structural
typing :).

If you want to criticize C++, it should be about language complexity,
undefined behaviour, being able to shoot yourself in the foot, etc.

Kind regards,
Daniël de Kok

[⚛]

In my opinion, the process of you learning Go made your brain forget how to efficiently see through the rules of C++ in order to express computation.

You generally aren't to supposed to learn like that!

All programming languages are just ways of expressing the very same thing: computation.

Programming is also an incessant process of encoding and decoding.

Playing with rules built into Go is fun - playing with rules built into C++ is also fun.

C++ is here-and-there more efficient than Go in expressing what you want to achieve - Go is here-and-there more efficient than C++ in expressing what you want to achieve.

Challenge yourself: read "mov is Turing-complete" (http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf https://news.ycombinator.com/item?id=9751312). It's just another (albeit ultra-inefficient) encoding of the very same thing: computation.

[Lucio]

My life is ruined and it's on you.

It's temporary, don't let it worry you.  I can still drag up some fond memories of APL, even though I wouldn't think of using it today.  All languages and all literature (read programming notations and other people's code) have something to teach you.  :-)

Lucio. 

[thwd]

On Friday, July 24, 2015 at 10:17:59 AM UTC+2, ⚛ wrote:

In my opinion, the process of you learning Go made your brain forget how to efficiently see through the rules of C++ in order to express computation.

I also had a C++ professor. An academic with a passion for "performance." His classes are full of friends and inheritance is just another tool to touch other classes' privates. "Because abstraction is expensive."

I showed him Go, he dismissed it and said that I wouldn't understand how inefficient the idea of a garbage collector is.

I hated that class and i can relate to OP.

[andrewc...@gmail.com]

On Friday, July 24, 2015 at 11:05:36 PM UTC+12, thwd wrote:

On Friday, July 24, 2015 at 10:17:59 AM UTC+2, ⚛ wrote:

In my opinion, the process of you learning Go made your brain forget how to efficiently see through the rules of C++ in order to express computation.

I also had a C++ professor. An academic with a passion for "performance." His classes are full of friends and inheritance is just another tool to touch other classes' privates. "Because abstraction is expensive."

That sentence is overloaded with so many different (and rude) interpretations, it is great.
 

I showed him Go, he dismissed it and said that I wouldn't understand how inefficient the idea of a garbage collector is.

A teacher who assumes he understands things his students are incapable of understanding. What an ass. 

[Henry Adi Sumarto]

Like its C predecessor, C++ too has shown it's age. It was meant to solve problems that occur at a specific point in the past which is slowly becoming irrelevant today. It's a 32 years old piece of technology and much has changed since then. The committee has tried to prolong its lifespan by extending it's features, but there is only so much you can stretch. There will come a point where they must start from a clean slate and introduce some breaking changes.

This is no time to make fun of C++ and laugh at it. Like any other technology, one day Go too will become obsolete. When that day come, I hope gophers will have the courage to screw backward compatibility and to start over.

[⚛]

On Friday, July 24, 2015 at 1:05:36 PM UTC+2, thwd wrote:

On Friday, July 24, 2015 at 10:17:59 AM UTC+2, ⚛ wrote:

In my opinion, the process of you learning Go made your brain forget how to efficiently see through the rules of C++ in order to express computation.

I also had a C++ professor. An academic with a passion for "performance."

There is no causal relationship between [person A using C++] and [person B learning Go and loosing his ability to use C++ because of Go].

 

His classes are full of friends and inheritance is just another tool to touch other classes' privates. "Because abstraction is expensive."

In many cases, the C++ compiler should be blamed for making abstractions too expensive, not the C++ language.

I showed him Go, he dismissed it and said that I wouldn't understand how inefficient the idea of a garbage collector is.

It is true that current garbage collector implementations are somewhat inefficient. Nobody has been able to crack this problem yet and establish a new norm in garbage collection performance.

By itself, there is nothing inefficient in the idea of a garbage collector. It just happens that we live in an era in which programmers using manual memory management can easily beat all current GC implementations.

[Roberto Zanotto]

Guys the post was kinda a joke, I'm not blaming Go for anything and I didn't forget how to program in C++, I just find it uglier than ever :)

[Dmitri Shelenin]

Oh, that sounds just about how I did it - and almost got fired afterwards.

Left the jobs anyways, due to ruined life -- there's no more programming in C++ after Go :-)

[⚛]

On Friday, July 24, 2015 at 3:10:14 PM UTC+2, Roberto Zanotto wrote:

Guys the post was kinda a joke, I'm not blaming Go for anything and I didn't forget how to program in C++, I just find it uglier than ever :)

There is little difference between [forgetting how to program in C++] and [refusing to read and write C++ programs because C++ is subjectively ugly]. The end result is the same.

[kor...@gmail.com]

I wouldn't be worried. I had the same thing with Java... and I spent 4 years working in Java before discovering Go. Your friends are right - Design Patterns and Effective X are gonna help your friend prepare for the interview, but he will land a job in a boring, stale enterprise company. Where he will then have to relearn everything because enterprise always has everything built in-house. And after he does, he will be a successful screw in that big machinery while doing maintenance on legacy systems.

You, my friend, are blessed. You will have the chance to experience wilderness of startup life in one of many companies that will employ Go. You will get to do the fun stuff, you will have an impact in how something is made, you will have the opportunity to build systems from scratch. Nothing is ruined, it's actually better for you, you just have to realize it. Value isn't in your friends opinions - it's what you make of it.

Good luck, fellow Gopher!

[will.r...@gmail.com]

> I have to work on a project for an university exam ...

Interesting. I don't know why but I had always assumed from my narrow circle that Go's uptake was primary with, how do I put this ... experienced programmers (like myself). Just in this thread there's a couple posts in here about students using Go outside of classes. Wonder what the age rages of coders in various languages are? And if it has any impact on update.

[David Chase]

On Friday, July 24, 2015 at 7:05:36 AM UTC-4, thwd wrote:

I showed him Go, he dismissed it and said that I wouldn't understand how inefficient the idea of a garbage collector is.

I have an extended model of "efficiency".

The program I don't trust to run on my computer is modeled as being "infinitely slow". 

Most languages lacking a managed runtime don't do too well under that metric.

[Kiki Sugiaman]

> I showed him Go, he dismissed it and said that I wouldn't understand
> how inefficient the idea of a garbage collector is.
>

Well that prof wouldn't understand that in many cases, nobody gives a
rat's rear about efficiency. And go is not even inefficient.
Case in point: ruby, javascript.

[adam willis]

I recently watched this video: https://www.youtube.com/watch?v=BBbv1ej0fFo

not every language is perfect. golang made trade-offs. garbage collection is a trade-off that under certain circumstances an environment can't accept, to others its a non-issue.

I'd like to see different garbage collection strategies pluggable at build.

[Yongjian Xu]

I've interviewed quite some developers who claimed to have Go programming skills and my generally feedback is that they seem to have stronger than average programming skills and disciplines. Another interesting observation is that these programmers who can program in Go also seem to have better understanding of the operation system internals...

--

[Simon Ritchie]

> Guys the post was kinda a joke,

Joking in a Go forum.  Hmm.  Can't allow that.  For your penance I consign you to be a COBOL programmer.

Simon

[Simon Ritchie]

> {Go developers} seem to have stronger than average programming skills and disciplines. Another interesting observation is that these programmers who can program in Go also seem to have better understanding of the operation system internals

My guess is that the kind of people who take the trouble to acquire those sorts of skills are also attracted to Go in its present state of development.  Its all about an interest in the current version of rocket science, whatever that happens to be.

Simon

[adam willis]

It has nothing to do with a persons skill set. some environments simply can not accept the trade-offs. this is not an attack on go - just a defense for why most languages exist. An example is one of the trade-offs for assembly is a persons sanity. But most trade-offs are hardware related. no language is perfect for every possible task

[Daniël de Kok]

On Fri, Jul 24, 2015 at 1:05 PM, thwd <sedevel...@gmail.com> wrote:
> I showed him Go, he dismissed it and said that I wouldn't understand how
> inefficient the idea of a garbage collector is.

Any language will have its blind followers (including Go). There are
applications where exact memory management, easy (non-assembly) access
to SIMD primitives, or expression templates are exactly what you want.
Of course, for the far majority of applications you will do fine
without (or simply bind to a C or C++ library).

In the end, you write down your requirements and choose. Or you are
simply stuck with whatever your employer uses ;).

[Lex Sheehan]

Go just keeps getting better.  Check out the performance gains in Go 1.5:  https://talks.golang.org/2015/state-of-go-may.slide#8

It'll take the large companies much longer to catch on.  In the meantime, the smaller companies will build better software, faster in Go.

Like was said previously, if you want to be another cog in the machinery of a large corporation, there are lot's of C++ and Java jobs available.

Thank you, Go!  What other language has it's own song?  http://lexsheehan.blogspot.com/2014/12/javas-verbose-python-is-too-slow-its.html

[Gautam Dey]

On Fri, Jul 24, 2015 at 11:03 AM, Lex Sheehan <lex.s...@gmail.com> wrote:

Go just keeps getting better.  Check out the performance gains in Go 1.5:  https://talks.golang.org/2015/state-of-go-may.slide#8

It'll take the large companies much longer to catch on.  In the meantime, the smaller companies will build better software, faster in Go.

Like was said previously, if you want to be another cog in the machinery of a large corporation, there are lot's of C++ and Java jobs available.

Thank you, Go!  What other language has it's own song?  http://lexsheehan.blogspot.com/2014/12/javas-verbose-python-is-too-slow-its.html

Perl does: (2 of them)

https://youtu.be/eT6yjrLe4_U

https://youtu.be/Mxk5RMQF6Js

 

On Thursday, July 23, 2015 at 6:19:29 PM UTC-4, Roberto Zanotto wrote:

I have to work on a project for an university exam and the professor highly recommends doing it in C++ with (his) FastFlow library. Now, because of Go, I can't stand looking at object oriented code anymore. The way the code is structured... class hierarchies... you can't even tell what the program _does_. My eyes cross and I feel like crying.

I was meant to be a successful C++/Java programmer, now that is ruined forever. And nobody listens to me! A friend of mine recently graduated, we bought him "Design Patterns: Elements of Reusable Object-Oriented Software" and "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14". He wanted those books and said that they are what he needs to learn for job interviews. And everybody agreed.

My life is ruined and it's on you.

--

[Micky]

Ironically, that's how exactly I feel.

After you go Go, other things go south.

And after a month or so, they start look hazy and fugly.

On Fri, Jul 24, 2015 at 6:10 PM, Roberto Zanotto <roby...@gmail.com> wrote:

Guys the post was kinda a joke, I'm not blaming Go for anything and I didn't forget how to program in C++, I just find it uglier than ever :)

--

[emap...@gmail.com]

Common Lisp has a song, a folk song yet: The Eternal Flame

[Mike Ossareh]

On Thu, Jul 23, 2015 at 4:51 PM, <andrewc...@gmail.com> wrote:

I get raised eyebrows at my work if I mention Go, Clojure or upgrading our tools in general.

Ugh, it pains me that we in the technology space react to things in this manner! We're supposed to be cutting edge and good at adapting to change :)

I realize I'm so lucky to work where I do, we embrace change, and deliver high scale systems using whatever makes the most sense to do it in. Go is becoming more of that.

[Roberto Zanotto]

Wow, cool people in the video, I'm gonna watch it right now.

I know a language can't be perfect, but I think that the designers of Go always made wise choices where important tradeoffs had to be made. GC is definitely good to have. As for those circumstances and environments you are talking about, I see it more as an implementation issue than a design one. It would be definitely cool to see different implementations of Go for different systems.

[bejaran...@gmail.com]

El jueves, 23 de julio de 2015, 17:49:29 (UTC-4:30), Roberto Zanotto escribió:

I have to work on a project for an university exam and the professor highly recommends doing it in C++ with (his) FastFlow library. Now, because of Go, I can't stand looking at object oriented code anymore. The way the code is structured... class hierarchies... you can't even tell what the program _does_. My eyes cross and I feel like crying.

I was meant to be a successful C++/Java programmer, now that is ruined forever. And nobody listens to me! A friend of mine recently graduated, we bought him "Design Patterns: Elements of Reusable Object-Oriented Software" and "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14". He wanted those books and said that they are what he needs to learn for job interviews. And everybody agreed.

My life is ruined and it's on you.

Yep, same thing happen to me when I move from Golang  to Clojure.

[Tim Hawkins]

The biggest argument against GC comes from folks who have exacting timing requirements, such as video playback, encoding, real time applications, animation and games, where there is a need to be able to have each algorythm used have exactly known run time budgets. GC introduces a non-deterministic element to the execution time. Java is famous for its GC initiated "pauses" while the garbage collector runs off and cleans up memory.

[Andrew Chambers]

There are garbage collectors that have hard real time worst case delays. C++ programs tend to use things like smart pointers which are pretty unpredictable themselves. There is no guarantee a ref count decrement frees one or a thousand items if it triggers a chain reaction.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/ghu1Zpc88io/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Daniël de Kok]

On Jul 25, 2015 05:20, "Andrew Chambers" <andrewc...@gmail.com> wrote:
> There are garbage collectors that have hard real time worst case delays. C++ programs tend to use things like smart pointers which are pretty unpredictable themselves. There is no guarantee a ref count decrement frees one or a thousand items if it triggers a chain reaction.

There is - you as a programmer can or should anticipate that. Also nothing holds you from using a custom allocator with a shared pointer that has different behavior.

This touches exactly on the difference: C++ provides fine-grained control over construction and destruction, whereas Go, Java, etc. try to provide sensible defaults. You can write GC-friendly code, but it pretty much ends there.

(In principle a GC could be faster, because it can optimize for the allocation patterns that actually occur at runtime, rather than those anticipated by the programmer.)

Daniël

[David Cittadini]

There seems to be a pattern to what you are saying....

[rei...@gmail.com]

Following the post of curiosity about age ranges of developers in various languages, note this originator of this thread is discussing school.  He is likely far too young for consignment as a COBOL programmer.
Anyway, most of that runs on mainframes, and he is still enjoying main.go!

[Haddock]

On Friday, July 24, 2015 at 6:04:57 PM UTC+2, adam willis wrote:

I recently watched this video: https://www.youtube.com/watch?v=BBbv1ej0fFo

I really like the section where Bjarne Stroustrup points at Scala for having even worse a build time scalability problem as C++ ...

[Samuel Lampa]

On Friday, July 24, 2015 at 12:19:29 AM UTC+2, Roberto Zanotto wrote:

I have to work on a project for an university exam and the professor highly recommends doing it in C++ with (his) FastFlow library.

I love Go for writing concurrent and parallel applications ... and I shun C++ like the plague.

Having said that, I would ... not kill ... but surely pay for, being able to learn about FastFlow in uni :)

Citing from Googler and Go developer Dmitry Vyukov: 

"FastFlow is fast. We experimentally demonstrate that FastFlow is always more efficient than state-of-the-art multi-core programming frameworks in a set of micro-benchmarks and on a real world applications; the speedup edge of FastFlow over other solutions might be substantial for fine grain tasks, as an example +35% on OpenMP, +226% on Cilk, +96% on TBB for the alignment of protein P01111 against UniProt DB using the Smith-Waterman algorithm."

http://www.1024cores.net/home/technologies/fastflow

This kind of qualifies it as a very interesting tech IMO :) ... to me it even seems like the kind of thing that if you know it well enough, you might start seeing ways to improve Go itself? :)

Anyways, wish you all the best for your studies!

[Roberto Zanotto]

I didn't know that :) and I certainly couldn't imagine it form the documentation. It's full of "Todo", "Not currently used" and totally undocumented things. I was thinking about using the macro data flow executor for a certain task but, as you can see, you probably have to contact the author of the class to get an explanation of how it works (I know what the macro data flow pattern is and still I can't figure out how to use the class). And the course was on parallel programming, we didn't do fastflow in such detail that we don't need the reference manual. It's a shame if the library is so technically valid and the docs are so lacking, gives the impression that the library itself is half baked and not ready for production.

[⚛]

On Saturday, July 25, 2015 at 8:16:55 AM UTC+2, Daniël de Kok wrote:

(In principle a GC could be faster, because it can optimize for the allocation patterns that actually occur at runtime, rather than those anticipated by the programmer.)

That is impossible.

Even in case the program is hitting the halting problem (aka performing emulation), the best case scenario is for the top-level GC to be at most as fast as the emulator's hand written memory management code for managing memory allocated by the emulated code. (For example, if the emulator is written in Go, the top-level GC is Go's GC.)

You are wrong. In principle, a GC cannot perform better than ultra-optimized explicit memory management. The GC can have at most the same performance, but it cannot have better performance.

[fatdo...@gmail.com]

I'd make the argument that a gc could consistently outperform above-average programmers. humans are clumsy and forgetful.

[Ian Dawes]

And you wouldn't be the first to make that argument... Jamie Zawinski --- back in 1998: http://www.jwz.org/doc/gc.html

[Lucio]

On Tuesday, 28 July 2015 07:31:25 UTC+2, Ian Dawes wrote:
> And you wouldn't be the first to make that argument... Jamie Zawinski --- back in 1998: http://www.jwz.org/doc/gc.html

Except that the essay assumes that the law of averages holds. I would counter-claim that "I" can do a better job of memory management, in "my" code or any well-documented code than "any" general-purpose GC, by treating each instance as a special code, something that a GC built into a runtime or compiler cannot be expected to do.

I guess the old-school of knowing not only what the language of your choice could do, but also what the underlying architecture was capable of (in other words, assembler programming) has been overtaken by Moore's Law.  Which, hopefully, means we can expect it to return to its rightful first place in the not too distant future when Moore's Law is itself overtaken by the need to provide all the frills we are used to without a corresponding continual increase in speed of computation.

Lucio.

[Egon]

On Tuesday, 28 July 2015 09:02:03 UTC+3, Lucio wrote:

On Tuesday, 28 July 2015 07:31:25 UTC+2, Ian Dawes wrote:
> And you wouldn't be the first to make that argument... Jamie Zawinski --- back in 1998: http://www.jwz.org/doc/gc.html

Except that the essay assumes that the law of averages holds. I would counter-claim that "I" can do a better job of memory management, in "my" code or any well-documented code than "any" general-purpose GC, by treating each instance as a special code, something that a GC built into a runtime or compiler cannot be expected to do.

Here's an interesting question -- can you do a better job in optimizing code than a superoptimizer? (http://superoptimization.org/wiki/Superoptimizing_Compilers)

So as a hypothetical -- what if we had a super-optimizing GC? One that ran a few days (compile-time) and automatically figured out how to layout the data such that it hits all the caches and didn't have to call free, instead it knew that some memory area can be used.

[Daniël de Kok]

On Mon, Jul 27, 2015 at 6:09 PM, ⚛ <0xe2.0x...@gmail.com> wrote:
>> (In principle a GC could be faster, because it can optimize for the
>> allocation patterns that actually occur at runtime, rather than those
>> anticipated by the programmer.)

[snip]

> You are wrong. In principle, a GC cannot perform better than ultra-optimized
> explicit memory management. The GC can have at most the same performance,
> but it cannot have better performance.

You didn't read all of my message, specifically 'rather than those
anticipated by the programmer'. Your assumption is that the programmer
has the time and knowledge to make 'ultra-optimized explicit memory
management'.

In practice, a lot of programs are written with some usage scenario in
mind and then never or barely optimized for actual usage patterns. Or
in the case of a library there may be a mismatch between what the
library writer expects and how the library is actually used.

I said 'in principle', because I found in practice that even ok-ish
manual memory management is typically faster than the average garbage
collector. But that's because most GCed languages don't have a great
GC (with the exception of e.g. various JVMs).

-- Daniël

[David Chase]

On Tuesday, July 28, 2015 at 2:02:03 AM UTC-4, Lucio wrote:

On Tuesday, 28 July 2015 07:31:25 UTC+2, Ian Dawes wrote:
> And you wouldn't be the first to make that argument... Jamie Zawinski --- back in 1998: http://www.jwz.org/doc/gc.html

Except that the essay assumes that the law of averages holds. I would counter-claim that "I" can do a better job of memory management, in "my" code or any well-documented code than "any" general-purpose GC, by treating each instance as a special code, something that a GC built into a runtime or compiler cannot be expected to do.

The counter-claims are (variously):

- how do we know that you aren't suffering from the Lake Wobegon Effect?

  (Are you not chronically depressed?  Then you almost certainly do).

- how sure are you that you don't suffer from the Dunning-Kruger Effect?

  (This is a trick question....)

- evidence of buffer overruns and other vulnerabilities over the years suggests

  that trusting people to program in non-managed languages is a bad bet.

  (We learned a lot from Robert Morris back in 1988, and haven't had any

   problems at all since then.)

The issue is largely one of scale.  I don't trust other programmers.  Unless

they're stupid, they shouldn't trust me.  At scale -- either large program scale,

or large risk scale (risk=widespread monoculture deployment, or safety critical)

nobody should trust anyone, and that's where GC and managed runtimes enter

the game (and maybe, someday, automated verification and/or proof?  please?)

And yes, when I program AVR microcontrollers all by myself, I use C, and there

is no GC.  I have a pet prediction that whatever the first computers injected into

our bloodstream will be, most likely the architecture will be AVR or AVR-based,

and I darn sure don't want them programmed in C.  Knowing not enough about Rust,

I think I want them to be programmed in Rust.

[Henry Adi Sumarto]

From the practical point of view, in today's context of software development where you have to develop larger-scale software and deal with deadlines, ever-elusive requirements, concurrency, parallelism, etc. it is more practical to use GC. You can insist to use manual memory management, but it would take some extra work to get to at least the same performance as the GC version of the program. That extra work is a luxury that not all of us have in today's competitive world. Forget micro benchmark language vs language results because today's software is not written with such efficiency (except perhaps if the project is small). People usually optimize only the major bottlenecks until a satisfactory performance is achieved and then ship the software. So, this argument about GC vs non-GC to squeeze some extra nanoseconds of performance is rather pointless. It is better to tackle the program from the design point of view than to worry about GC, unless of course if the GC actually causes problems in your software.

[Benjamin Measures]

> That is impossible.

The same has been said of asm vs C, static compilation vs JIT (and memory management vs GC).

Impossible in theory but true in practice. While you spend hours shaving microseconds others spend that time improving algorithmic complexity.

[Paul]

On Friday, July 24, 2015 at 12:19:29 AM UTC+2, Roberto Zanotto wrote:

I have to work on a project for an university exam and the professor highly recommends doing it in C++ with (his) FastFlow library. Now, because of Go, I can't stand looking at object oriented code anymore. The way the code is structured... class hierarchies... you can't even tell what the program _does_. My eyes cross and I feel like crying.

I was meant to be a successful C++/Java programmer, now that is ruined forever. And nobody listens to me! A friend of mine recently graduated, we bought him "Design Patterns: Elements of Reusable Object-Oriented Software" and "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14". He wanted those books and said that they are what he needs to learn for job interviews. And everybody agreed.

My life is ruined and it's on you.

'Forever' is a big word, I think things are moving too fast for that.  Once General Artificial Intelligence can be used to translate human languages to machine languages there will be a seismic shift. If you just think about security applications and General AI. Imagine a Deep learning algorithm that can detect malicious code by looking at the generated machine code. Its not as far fetched as it may seem because its mostly about pattern recognition.  Unfortunately not enough is being done to move faster in that direction. 

[Juliusz Chroboczek]

> I was meant to be a successful C++/Java programmer, now that is ruined
> forever.

[...]

> My life is ruined and it's on you.

You can only blame yourself. You should have studied for the exam
rather than doing extra-curricular stuff.

[David Collier-Brown]

The PHBs always want FORTRAN IV programmers, in any language. Just lie and say Go was written by FORTRAN experts. Lik Kernighan and Pike, for example.

--dave