cy_hauser

Or it's _almost_ the correct hammer! If they'd just fix those damn

So I went to the next link down, "Unexported fields from an exported struct". Figured this would be the clever way to access the "message" field. But again I don't get it. It seems it's the same code as the last example.

This either says something about my ability to understand Go code or that maybe a bit more exposition would be useful for at least some of the examples.

No there are not. It's extremely frustrating that Free Pascal and Delphi's Pascal are stuck with all the annoying baggage that more modern languages have been able to skip.

By this definition is there a language that doesn't have "error handling?"

You and I must experience time differently. I read a couple days ago that the end of 2022 would be the earliest they might appear but probably further out than that.

I understand what you're saying but I think (hope?) you're going to be found wrong here. I think that:

(1) very quickly "generic" code will come to be written in a fairly standard way that's accessible to any who cares to spend just a bit of time to know it.

(2) there will be a lot less generic code than concerned Gophers think. I think the generic code will end up in libraries but not so much in application code. Except, of course, in code that uses generic libraries. But using generic code is much more understandable than writing it.

Should be interesting to see how it all shakes out if this latest proposal passes muster. But I think Go will still be much more like "Go" rather than turning into what you dislike about other languages.

I took that as saying D could compile itself in 5 seconds too. I was impressed. Bubble bursted.

But it will never be as fun as it could be if there were no in-app purchases and no ads. That always sits in the back of my mind and prevents me from even trying a game with in-app purchases.

I'm stealing that line. (And thus contributing to your continuing to be poor. Sorry.)

Because it's too expensive for me to afford. More than an order of magnitude too high for me. As side projects I write closed source software so they do pull in a a bit of money. But this is typically only a few hundred to a few thousand per year per app. I think they target corporations rather than individuals or small shops.

FWIW, before there was Delphi there was an entire language (and consulting industry) built around this: PowerBuilder. Its primary component was a "DataWindow" which was a fancy presentation object around basic CRUD SQL. Good times were had by many.

I'm not advocating against inheritance. If it works then go for it. I do when I'm coding in languages that have it. This stemmed from a thread discussing whether the lack of inheritance in Go was sufficient to exclude it from being an object-oriented language.

Going back to the "old days" you'd reach for a pattern. Adapter pattern was the most common. Bridge or Facade maybe? But patterns fell out of favor a while back (imo) because they were tough on the coder's mind. A lot of languages added useful bits to create these pattern behaviors more naturally and without reaching for a book. I'd need to see code to be more specific.

I don't consider inheritance an important feature for a language to be an "Object Oriented Language." Inheritance: none, single, and multiple have been bandied about in the OO world for quite some time now so I understand where you're coming from.

I break out design from the language. While I wouldn't design very deep without knowing the language I was targeting I do consider Go as having a natural bias towards driving me to OO design over, say, functional or procedural. For me Go lends itself naturally to OO design. Sans inheritance, of course.

> "if you don't have these, then OOP is indistinguishable from FP or DOP. If Go is OOP, then which languages aren't, and why?"

Haskel, some Lisps, some Forths, etc. would be more non-OO languages in my mind. C is also a non-OO language to me even though you can certainly code it in an OO style.

I guess I agree with the blog author, OO is simply part of the language landscape these days and isn't going to be supplanted by functional any more than procedural was supplanted by OO. And with my mind-set then I'll say most all of Algol's recent children can be considered OO languages. So for me Go is definitely an object oriented language. But I now understand why you don't.