"You Don't Like Google's Go Because You Are Small" !

[manasij7479]

Anyone agree with the points made?
Mikov's Blog: You Don't Like Google's Go Because You Are Small

I do not understand the 'go way' very well, but can't help but agree with the author on what Go does wrong.

[GReaper]

Sarcasm overload, that's what that article is... I don't want to even consider them being serious, because then I'd be like:
Kill it! Kill it with fire, before is lay eggs!!

[phantomotap]

I do not understand the 'go way' very well, but can't help but agree with the author on what Go does wrong.

O_o

I mostly still think of the Go language as I have for some time: the crippled offspring of the Javascript and Earlang languages.

*shrug*

Of course, I complain about all languages...

Soma

[Mario F.]

I really never understood what Go tries to achieve. It seems like just another ego language to show the world that you know LR grammars. Only it really wasn't. The inventors of the language themselves never made much of it. They were just fooling around with a different C. It seems that today all it takes is for someone to come up with a different way of opening a can for a group of people to start evangelizing it has the best way to open cans.

The whole principle of a simpler C seems like false prophecy, too. For veteran C programmers, they are already accustomed to the language to consider it simple. For newcomers, they were never exposed to C to consider it hard. For everyone in between Go is so riddled with idioms and so focused on best practices that any possible advantage a simpler syntax may provide is shadowed by the complicate knot that has become idiomatic Go.

God, when are we going to witness a truly unique language that really introduces new and useful concepts into the landscape of computer programming and doesn't come with the usual "easier and safer" punch line which never translates to anything meaningful.

[phantomotap]

[Edit]TL;DR: I'm just cranky because people keep trying to remove forms of polymorphisms from new languages.[/Edit]

God, when are we going to witness a truly unique language that really introduces new and useful concepts into the landscape of computer programming and doesn't come with the usual "easier and safer" punch line which never translates to anything meaningful.

O_o

What new concepts do you imagine which may exist that are also useful?

I'm not being sarcastic; I'm honesty curious.

What do you feel is missing?

o_O

You seem to view the modern landscape of languages almost the exact opposite from my perspective.

As far as I am concerned, we have all the useful features we may ever need in existing languages.

The problem, as I see it, is stripping (You may instead read "never including".) useful features for ridiculous reasons.

Look at the motivations for many of the differences between C++ and the Java, D, or C# languages.

[Multiple inheritance] is a complex feature of debatable value. [Multiple inheritance] is very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it.

I don't care if you (The quote is from the D language site.) can't think of a use for a multiple inheritance mechanism. Your limited imagination just prevents me from expressing my ideas without jumping through hoops. Wait. You do have in "template mixins" something of a multiple inheritance mechanism. You just didn't want to repeat the sins of the C++ language. Congratulations! You didn't repeat the sins of the C++ multiple inheritance mechanism. You managed to commit entirely new sins with the added damage of forcing me to specify routing in the context of the declaration instead of the context where a behavior is inherited.

Actually, you don't even need to look at other languages to see people stripping useful features.

All parameters passed by reference must be labeled const.

What? You (The quote is from the Google style guide for the C++ language.) understand the value of reference semantics but are going to force me to check a pointer even if the interface demands the output argument to be valid? Why? "References can be confusing, as they have value syntax but pointer semantics." Oh. I am expected to avoid useful features because of the easily confused? Nope.

You even see such nonsensical tendencies of removing features within revisions to existing languages by insane members of the community. The C++ community, for example, started arguing anew against the change in `auto' after the C++11 standard was published. Yeah. A few members of the C++ community actually wanted the newly minted `auto' mechanics deprecated for what would then be the new standard purely because of politic.

Come to think of it, I don't recall seeing any languages spawn in the last few years that couldn't be described with the generic "$("Language You Currently Use") plus $("Marketing Gimmick") without $("Useful Feature") because a modern language needs $("Buzzword").".

*shrug*

Look, I am not trying to rant. I'm certainly not ranting at the comments Mario F posted.

I have no patience for people stripping useful features from languages, and I see people stripping useful features all the time in $("Language What Claims an End to the C/C++ Language") language or $("Programming Is Hard So Follow This Misguided Standard") guidelines. How is this difficult to understand? I do not want to work harder to express my solution to a problem so making me jump through even more hoops is not going to make me change my language of choice. I don't like the current regimen; my distaste is greater still when required to do even more for less effect.

Yes. I absolutely do realize that not every programmer is like me. No. My desire to stop people from stripping language features isn't arrogant. I'm not trying to force everyone to use every feature every language has to offer. I just want the option to use all the features as I see fit.

Give me a clean expression of the features Ada and C++ expose with the collection magic of Scheme, I'll happily join your team in regurgitating the language killer. I don't need any new features, but I do expect all of those features. I don't even need a big standard library if you give me a standard expression of external linkage with the C language.

Soma

[Mario F.]

What new concepts do you imagine which may exist that are also useful?

I'm not being sarcastic; I'm honesty curious.

What do you feel is missing?

o_O

You seem to view the modern landscape of languages almost the exact opposite from my perspective.

As far as I am concerned, we have all the useful features we may ever need in existing languages.

I'm with you. But I'm not the one developing new programming languages. They are. They are the ones who feel something is missing.

I am questioning their motivations. If we are to have a new programming language, then let that be a programming language that actually introduces something new and useful that we haven't thought before. Not just a rehearse of known ideas because the author thinks he can do better than others have been doing. It's a waste of everyone's time and presents this false idea that these old, well documented and highly successful languages that predated them, with tons of useful software running on millions of computers or serving millions of customers, are somehow flawed.

What is flawed is their damn insistence that you make something better by making it simpler.

[Elkvis]

What is flawed is their damn insistence that you make something better by making it simpler.

Everything should be as simple as it can be, but not simpler.

- Albert Einstein

On topic, There are a few areas where I think Go excels, and in fact, could be seen as better than other alternatives. Goroutines are a really simple and intuitive approach to asynchronous operations. std::async Would be the C++ equivalent, and it's nearly as simple. Channels are nice too, because they are implicitly thread-safe, and make intra-process communication very easy. I haven't gone too deep into Go, but I appreciate what I've seen, and I'm always hoping to find the time to learn more about it.

[phantomotap]

What is flawed is their damn insistence that you make something better by making it simpler.

O_o

In my opinion, they as often don't even succeed in making an expression simpler.

Channels are nice too, because they are implicitly thread-safe, and make intra-process communication very easy.

Obviously, the library isn't standard. Thanks to politic, the standard will probably never have such a library.

That said, you can find a `std::?stream' wrappers around pipes for C++98 and C++11 which is very nearly the same beast.

Assuming you have the class `MyPacket' with the relevant overloads for basic stream insertion and extraction:

int main()
{
    try
    {
        auto sC = MakeChannel("name of pipe");
        auto sR = std::async(std::launch::async, [&]() -> bool {
            return(sC << MyPacket(/* ... */));
        });
        if(sR.get())
        {
            auto sT = ReadPacket(sC);
        }
    }
    catch(...)
    {
        // whatever
    }
}

MyPacket ReadPacket // I prefer commit/rollback semantics.
(
    std::istream & f
)
{
    MyPacket s(/* ... */);
    if(f >> s)
    {
        return(s);
    }
    throw std::string("whatever");
}

Soma

std::ostream & operator <<
(
    std::ostream & fLHS
  , const MyPacket & fRHS
)
{
    std::ostream::sentry sCerberos(fLHS);
    fLHS << fRHS.m???; // each
    return(fLHS);
}

std::istream & operator >>
(
    std::istream & fLHS
  , MyPacket & fRHS
)
{
    std::istream::sentry sCerberis(fLHS);
    fLHS >> fRHS.m???; // each
    return(fLHS);
}

[Yarin]

That's a great article. Sums up my feelings of Go nicely, especially the part on multiple dispatch (the one true way of polymorphism).

I mostly still think of the Go language as I have for some time: the crippled offspring of the Javascript and Earlang languages.

Wat? Go is nothing like those.
Erlang's syntax is extremely non-C, everything is immutable (so "functional"), and by far the worst, no records (structs for you C* weenies). Javascript is dynamically typed, uses prototypical inheritance, and has mapped object members.

The whole principle of a simpler C seems like false prophecy, too.

The ironic part is, Google "look at how simple I am" Go is GCed. GC is the epitome of language complexity.

Channels are nice too, because they are implicitly thread-safe, and make intra-process communication very easy.

Nothing a small C library couldn't take care of.

[Epy]

Some have already expressed this thought, but I'll say it again, in my own words:

I think a lot of people just like making new languages. Really no reason for them unless they offer something really special in the syntax, or lots of built-in goodies, etc. A for instance would be my love, Fortran, which has built-in array operations, which makes it usable in some situations vs. other languages.

[phantomotap]

[Edit]I borked the earlier edit.[/Edit]

Wat? Go is nothing like those.

O_o

Wat? You'll note that I didn't say "Go is like Erlang." or "Go is like JavaScript.".

I said "[I think of the Go language as] the crippled offspring of the Javascript and Earlang languages.".

(Which is weird because "Earlang" sounds bizarre.)

The Go language looks to me like it was designed trying to fill a role similar to Erlang with the syntax JavaScript without repeating the sins of either language... so gutted too much and found new ways to sin.

[Edit]
To be clear, my opinion comes from the repeated vocabulary used to "Why yet another language?" Go rather than the sins and syntax.
[/Edit]

Soma

[Elkvis]

you can find a `std::?stream' wrappers around pipes for C++98 and C++11 which is very nearly the same beast.

Nothing a small C library couldn't take care of.

But the point here is that it's integrated into the language, and as far as I know, it doesn't use any operating system facilities to transport the data. It's more like a thread-safe queue, which is also easily implemented in C and C++, with their respective standard libraries, but in Go, it's provided by the language specification.

[Nominal Animal]

Fortran [..] built-in array operations [are very useful]

Agreed. I use a rather similar mechanism in my little matrix C toolkit for slicing and views.

At some point, I found out that C does not really have a built-in efficient way to initialize an array. I remember trying to take memfill(ptr, initial, size) up with the glibc folks at some point. It's just an optimized function, basically incorrect memmove(), which duplicates the initial chars in ptr up to size chars. It was basically shot down, unless I got it into GCC first, or something; I forget, this was a decade ago, I think. Using a handcrafted version (similar to the assembly GCC produces for memmove()/memcpy()), it was significantly faster than the typical loop assigning floats/doubles. (The cache-awareness is why it'd be nice to have it as a compiler built-in; it could emit code selected from a few variants at the AST level to best suit the current needs.)

Although I do like to use C, the standard has accumulated a lot of design-by-committee crud, and it feels to me like the C language standard and compiler folks are getting further and further away from actual practical code needs. It's like they work out rules that allow them to generate aggressively optimized code, but with very little thought on how it affects writing practical code. It seems to me, they're getting out of hand, receding into their own little universe, forgetting that the standard exists to serve programmers, not the other way around.

I wonder how many of these new languages are actually started by programmers who have suffered from that kind of development, and started a new language to "fix" this. I know I've been severely tempted quite a few times myself! At some point, whoever is funding the programmers, will bring in language and computer specialists, so the same cycle will repeat.. I wonder if that is the reason so many of these languages get started, but never grow outside their own little garden.

The languages that have a specific purpose, or a specific niche -- consider Lua for example, being lightweight, syntactically simple, and embeddable by design -- seem to fare much, much better in the long run.

[phantomotap]

But the point here is that it's integrated into the language, and as far as I know, it doesn't use any operating system facilities to transport the data. It's more like a thread-safe queue, which is also easily implemented in C and C++, with their respective standard libraries, but in Go, it's provided by the language specification.

O_o

(For clarity, how channels are implemented is a quality of implementation issue.)

I knew what you were saying.

The channel feature being part of the standard is great. As long as you have a conforming implementation, you have access to the channel mechanism.

Absolutely. I'm not disagreeing. The C++ community agreeing on a flavor so that we could have more components like threads pools and channel equivalents would be great.

The underlying mechanism is almost universally available so the syntax is the only thing making the Go flavor different.

My point was that in absence of a standard I can still write similarly expressive code in C++ because the mechanism isn't treated as having or exposing special syntax.

You could look at my comment as saying "Special syntax which only offers more expressiveness to a common mechanism isn't better than the alternatives because operator overloading is a thing that exists.".

Soma

[phantomotap]

It seems to me, they're getting out of hand, receding into their own little universe, forgetting that the standard exists to serve programmers, not the other way around.

O_o

The worse of it is, for most languages, the vendors themselves decide what constitutes conformance.

The line `__cplusplus > 199711L' is the bane of all Yog Sothoth's demented children.

Soma