Go (language)

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org wrote:
> I took a look at Go, and was REALLY disappointed.

Can you be more specific?

> Love it or hate it, C and C++ are the most used languages because of their
> ability to write generic software. I love C++ but its gets a bad rap from
> all the unspecified edge cases around the programming syntax. Using C++ as
> basically an object oriented C and exercising restraint on heredity can
> create pretty readable, efficient, and maintainable code.

I like C++, but cross-platform is very important to me, and the C++
standard doesn't cover enough of what's needed for a real app, which is
why I spend most of my time in Java or Perl or PHP.  Most of what's
missing is platform/OS independent IO.

> Java, love it or hate it, and its ugly evil clone C#, are good steps
> toward a language but are too tied to the VM paradigm to be able to be
> used to write device drivers or low level application code. Not to mention
> you have to make sure you bundle the VM environment with your app, no
> matter how small.

To be fair, the VM is either included, or easy to install, on most major
OSes.  And if you deploy using something like InstallAnywhere, it takes
care if the VM for you.

I wonder if it would be possible to build a pure Java compiler.  I think
enough evaluation has to happen at runtime that at best it would be
"mixed mode".

> Garbage collection, I'm not a huge fan. It is good for higher level stuff,
> but every non-trivial project in which I have been involved, has had
> issues with GC memory not going away fast enough or application memory
> footprint growing too fast. I'm not saying that it doesn't have a place,
> but the idea that it removes ultimate control is not a good thing.

That's a feature, to some.  I agree that it would be nice to have a way
of telling the GC to cull something at that time, though.

> If I could "fix" C++, I would clean up the inheritance issues and be more
> rigid and make things like inheriting from two or more of the same base
> class an error. I would introduce the notion of an "interface" which is
> different than a pure virtual base class. I would make all objects
> allocated with new a "subclass" of a common base class. lastly, I would
> incorporate Java's "finally."
> 
> If I couldn't fix C++, but could fix java, I would add an explicit
> "delete" operator as well as a class destructor. I would add an unsigned
> char so that you could actually read "E0" into an 8 bit space. I would add
> a real "pointer" class that would operate on real memory. I would add the
> ability to generate, using the GIT in some fashion, a os specific binary
> that can be shipped as an application without the whole bulk of the VM.

Why do you want real pointer math?  What can you do better with pointer
math than existing Java functionality?  I'm very curious on this one.
OTOH, I feel getting rid of pointers saved a lot of developer's rear
ends.  OTGH, I don't feel they went far enough, since you still have
NullPointerException, etc.

> So, back to Go. It is yet another language introducing yet another syntax
> with yet another set of assumptions about how software "should" be done in
> the eyes of people who wrote it. When, what I think the industry really
> needs, and maybe you'll agree, is to fix the languages we do use that will
> allow us to capitalize on our knowledge and experience, rather then the
> de-constructionist replacement of one flawed language with another equally
> or more flawed language.
> 
> C/C++ is flawed but could be improved. Java is flawed but could be
> improved. Go, flawed and may be improved. Where should we focus time and
> effort? What do you guys think?

For a general purpose language, it's Java for me because it allows you
to do the most things portably.  Things might have been different if C++
minions had elected a third-party GUI/OS wrapper/platform wrapper (QT,
wxWidgets, etc) as a standard, but it's a bit late for that now.

What I want to keep my eye on is how well Go takes over it's real
intended target market.  For instance, a hell of a lot of the
functionality in the average Linux distro is implemented in Python.
When *that* gets replaced with Go, then I'll start listening.