Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

521–530 of 679 posts

Re: Go is Google's language, not ours

#521

Post by [deleted] »

josefx wrote: post #434
pflats wrote: post #334

Earlier quoted context omitted.

Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is…

> Google was saying "from day one" it was a literal showstopper, For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "lite…

[deleted]

Re: Go is Google's language, not ours

#522

Post by jimmaswell »

eropple wrote: post #495
thechao wrote: post #310

Earlier quoted context omitted.

Generics in Java are giant hack from the early 2000’s to maintain backwards compatibility with 1990’s-vintage JVMs. C#’s generics we’re done right.

I'm of two minds of that, these days. I came from C# so of course reified generics were of course better, of course--but these days I would rather have them in Java more and in C# less. I often find myself wanting to write the moral equivalent of `IFoo ` in C# and end up having to have two separate interfaces, etc. just to have a way to handle a list of a thing that I end up working on in an abstract manner. (Though…

You mean like this, right?

    class A {};
    class A : A {};
I don't mind that. It can even be an aid to organization - all the generic stuff goes in the generic class, all the stuff that doesn't rely on that can go in the base class. But it would be nice to use something like . Too bad generics don't inherit implicit casts, like A to A.

Re: Go is Google's language, not ours

#523

Post by pushpop »

ncmncm wrote: post #89
pushpop wrote: post #49

Earlier quoted context omitted.

I’m guessing you don’t use C or C++ either then because they were proprietary Bell Labs languages. You should probably rule out assembly too because they will have proprietary instructions for proprietary CPUs. Which means if you really want to be freed from the shackles of using proprietary tools when programming you’re now building your own hardware too, processors and all. Good job ASCII isn’t proprietary otherwis…

Guess away, but both C and C++ broke out of Bell control very, very quickly by language standards. Now they are driven by ISO Standards bodies, with many, many participants -- ATT not among them anymore, to my knowledge. Even in 1995 ATT had nothing approaching veto power. My remarks lumping Java in with C# and Swift are transparent wishful thinking.

That was 10 years after it’s initial release and the spec hadn’t much changed from the specification defined by those Bell Labs employees. It wasn’t until 2011 that C++ saw some significant changes through the community. And in the first 10 years I seem to recall it was plagued by proprietary compilers having their own subtle behaviours.

I’m not saying it was all terrible nor that Go is managed better. But whenever there is a conversation about Go on HN people get so caught up in their own snobbery about how terrible they perceive Go to be that they lose all touch with reality.

The fact remains a language backed by a company is far less likely to die into insignificance than a language that isn’t. This is because it takes a lot for a language to gain momentum. You have a bit of a chicken and egg problem where developers won’t use a language without a good ecosystem, frameworks and community. But people aren’t going to write that if there aren’t already developers using it. This is where corporate sponsorship really helps.

Thankfully there are a plethora of good languages out there you can choose from. If you don’t like the direction of one language then you can use another. Or, alternatively, since Java, C# and Go all have open source compilers, you could fork and build your own community.

Re: Go is Google's language, not ours

#524

Post by jeanlucbernard »

sgift wrote: post #213
dullgiulio wrote: post #197

Earlier quoted context omitted.

It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writ…

> Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) la…

Java is a blue collar language in the eyes of people interested in language design and to be fair, some of them recognize its merits. The majority of programmers care more about their domain in which they are working and less about the language used in that domain.

Re: Go is Google's language, not ours

#525

Post by tracker1 »

akerro wrote: post #497
jayd16 wrote: post #455

Earlier quoted context omitted.

C#'s language is much better designed IMO. Can anyone compare LINQ and Java's streams and not pick LINQ? Feels much sloppier in Java and Java came second.

Yes, I personally prefer streams, LINQ seems to me like mixing SQL in C# and that feels wrong.

I do like all of LINQ's extension methods, but not the syntax myself.

Re: Go is Google's language, not ours

#526

Post by tracker1 »

cryptos wrote: post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

Aside from JS/Node and maybe C++, I can't think of any languages or platforms that are nearly as community driven. Java is probably the closest.

Re: Go is Google's language, not ours

#527

Post by pron »

pjmlp wrote: post #520
pron wrote: post #503

Earlier quoted context omitted.

C# has made some serious mistakes: reified generics (which has basically destroyed simple language interop on the CLR and makes it an unattractive target for language implementors), and recently, async/await. Both of these help in some ways, but have costs that are higher than the benefit and much better alternatives. Java is not trying to "keep up." It is intentionally slow-moving and conservative (this design goal…

As former Java dev, returned into .NET world, I don't consider it a mistake, the CLR was designed with multiple languages in mind, and there are plenty of options available, even if Scala devs failed at that. On the other hand, what I consider a major mistake from Java side was ignoring value types and AOT compilation since it's inception. Had Sun blessed such features since the beginning, and many use cases for C an…

Value types add complexity and they weren't necessary in 1995. They only became necessary due to hardware changes circa 2005. Similarly, AOT compilation has only become attractive for the kinds of applications people use Java for only recently, when startup time became important for serverless. The lack of neither has caused Java lasting damage; what has is the domination of the browser on the client, but that has affected all languages.

As to baking variance into the runtime, I think this is just a bad idea, which is so far used only in C++ and .NET, two languages/runtimes with notoriously bad interop (it's not just Scala; Python and Clojure have a similarly bad time on the CLR, as would any language not specifically built for .NET's variance model). It is simply impossible to share a lot of library code and data across languages with different variance models once a particular one is baked into the platform. This is too high a price for a minor convenience.

Specialization for value types (which are invariant), is another matter, and, indeed, it is planned for Java. Perhaps some opt-in reification for variant types has its place, but not across the board. I am not aware of other platforms that followed in .NET's misplaced footsteps in that regard. Those that are known for good interop -- Java, JS and LLVM, don't have reified generics.

What's worse is that it's a mistake that cannot be unmade or resolved at the frontend language level. Even Java's big mistakes (like finalizers, how serialization is implemented, nullability and native monitors) are much more easily fixed.

Re: Go is Google's language, not ours

#528

Post by Kovah »

munmaek wrote: post #77
Kovah wrote: post #34

I am about to learn a new programming language and I decided against Go just because of this fact. I do not trust Google and reading this article just makes clear how critical the state of the language is in terms of control by the community. Python looks most promising and I already worked with it, but I am not sure yet. Can anyone recommend a viable alternative for Go? Any web-focused language that is performant, m…

You should use a language based on how well it performs for your problem and domain, and the community around it. Not based on one article or because google is maintaining it.

It seems you misunderstood my post, like some others in this thread. I did not decide against Go because of the linked article, but rather because I have the same view on the language that is outlined in the article. I have a big problem with Google. And the fact that Google practically own Go is a red flag for me.

Re: Go is Google's language, not ours

#529

Post by emn13 »

adamc wrote: post #501
emn13 wrote: post #383

Earlier quoted context omitted.

Hmm, I do a lot of C# programming, including very language-y low-level stuff, and I'm not sure I completely agree. I appreciate that by moving faster they get more stuff into more hands faster, but they definitely have a lot of hackish solutions with poor ergnomics outside of the narrow scope they were originally intended for. If you will: the language features have a clear purpose but a general implementation; and o…

Uprated because you gave lots of specific examples. Too many conversations get vague fast.

Thank - I hope I don't come across as too bitter - I really do think there's an upside to all those limitations. I'm just past the exuberance of thinking that because it's so actively developed, that all these flaws are eventually fixable. It's a fast lifecycle, and probably at some point it'll be too impractical to continue as is, and then we'll just jump ship to some slimmed down alternate with a good transition story - and that's fine. So far: so good.

Re: Go is Google's language, not ours

#530

Post by tracker1 »

ncmncm wrote: post #41
cryptos wrote: post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

Actually Mongo doesn't even look at pull requests. So, yes. Postgres (do we really still need the "QL" reminder?) has demonstrated staying power, and repays invested time in spades. Linux, obvs. Rust, it's still too early to be sure about. Learning it will be at least educational, maybe formative, and at worst it won't be taken away.

Been learning Rust for the past few weeks.. absolutely love most of it. It's the first low-level language that actually feels right to me. Of course, I'm one of those weirdos who actually loves JavaScript. I also appreciate Go and C#. Rust just feels like most of the right trade offs, and once Futures and Async/Await stabilize, it'll be IMHO feature complete.

As an aside: The community needs an abstraction for WebAssembly's File System that has something like fcntl/flock functionality. As it stand's the Node interface for emscripten targets isn't good enough. Would love to see a bit more collaboration on this regard for sync and async interfaces for FS I/O that supports file/record locking in a more abstract runtime. Though this has been a pretty big shortcoming with Node since early on imho.

Post reply on HN