Go is Google's language, not ours • Hacker News Board

Re: Go is Google's language, not ours

#541

Post by folkrav » Wed, May 22, 2019, 7:29 PM UTC

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.

Projects like Linux are "community" projects in the sense that there is not a single company backing it, sure. However, for Linux, only 7.7% of contributions were made by unpaid developers as of this 2016 report[0].

I have a hard time calling this a "community" project when the community is paid by corporations. Don't get me wrong, I'm not really complaining, as a project the size of a commercially viable operating system kernel is hardly a project that could be viable without corporate backing IMHO.

[0] https://thenewstack.io/contributes-linux-kernel/

Re: Go is Google's language, not ours

#542

Post by pjmlp » Wed, May 22, 2019, 7:30 PM UTC

pron wrote: post #527

pjmlp wrote: post #520

Earlier quoted context omitted.

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 af…

In 1995 I was enjoying Oberon, Component Pascal, Eiffel and Delphi.

Value types were pretty much obvious as necessary.

More so when one dives deep into how languages like CLU and Mesa/Cedar were designed.

Having a AOT support doesn't preclude having a JIT as well, like Common Lisp or Eiffel already had in 1995.

Re: Go is Google's language, not ours

#543

Post by dirkg » Wed, May 22, 2019, 7:33 PM UTC

DaiPlusPlus wrote: post #532

weberc2 wrote: post #512

Earlier quoted context omitted.

Pretty sure those are almost all of the most popular statically typed languages (absent C#, which has about the same verbosity as Java). I'm sure I'm wrong if you're willing to lower the threshold for "popular" enough.

I’ll opine that C# is much less verbose than Java in practice - language features like properties, reified generics, functional-like programming with Linq, tuples and its jilt-in support for async APIs mean you can be surprisingly succinct.

Agreed 1000%. Java is backward compared to C# - bolted on half baked features that are the opposite of elegant, a standard library that is built on the principle of 'why use 10 lines when a 1000 will do' and the tools/IDEs are a generation behind C#. As is the runtime speed.

Re: Go is Google's language, not ours

#544

Post by mcguire » Wed, May 22, 2019, 7:34 PM UTC

lallysingh wrote: post #339

playing_colours wrote: post #259

Earlier quoted context omitted.

Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot. It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python. But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we ex…

The nice thing about walking minefields is learning how to watch your step.

"If you're walking on eggshells, don't hop."

-- unknown

Re: Go is Google's language, not ours

#545

Post by dirkg » Wed, May 22, 2019, 7:34 PM UTC

richardwhiuk wrote: post #466

baby wrote: post #418

Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…

Go already supports generics - the hashmap is generic, and the array is generic. It's just you can't implement your own hashmap in Go, and make it compile time type safe.

C also supports generics - just use void * !!

no, Go doesnt' support generics.

Re: Go is Google's language, not ours

#546

Post by pjmlp » Wed, May 22, 2019, 7:35 PM UTC

emn13 wrote: post #536

pron wrote: post #527

Earlier quoted context omitted.

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 af…

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an ove…

C# got it right from day one, regarding value types.

AOT compilation not so much, given the NGEN constraints.

However they got it both wrong, considering CLU, Modula-3, Delphi and Eiffel are considered influencial languages on their design.

Re: Go is Google's language, not ours

#547

Post by mcguire » Wed, May 22, 2019, 7:37 PM UTC

nfriedly wrote: post #504

SmirkingRevenge wrote: post #288

Earlier quoted context omitted.

My enjoyment using any given language always tends to grow as I get more productive with it, even if I have a more general dislike for the language itself. Making computers do things is fun (usually)! The programming language is (almost) immaterial - depending on the task at hand of course. Despite myself, I've even found myself enjoying JS in the few times I had no choice to avoid it. shudder

That part about JS is pretty much the story of my career - I started out completely hating JS, was forced to use it enough to get more familiar with it, and eventually eventually started enjoying it to the point that it's now the primary language I write. (I still hate it occasionally, but there's a lot more joy these days.) The initial turning point was probably around the first release of jQuery...

[Javascript isn't actually that bad of a language. It really is about 90% of Scheme plus prototype inheritance, which takes some getting used to but ... eh, it's as good as any other option. The problem was that it was one of the battlefields between Microsoft and Netscape and has some really hideous scars in the landscape.]

I did not write this. My fingers did not type it. Nothing to see here. Move along. I'm a hedge.

Re: Go is Google's language, not ours

#548

Post by JamesBarney » Wed, May 22, 2019, 7:38 PM UTC

darkpuma wrote: post #509

logicprog wrote: post #449

Earlier quoted context omitted.

I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor. Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all t…

> "My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor." As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android ha…

Also see javascript and static typing.

Re: Go is Google's language, not ours

#549

Post by mcguire » Wed, May 22, 2019, 7:39 PM UTC

darkpuma wrote: post #509

logicprog wrote: post #449

Earlier quoted context omitted.

I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor. Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all t…

> "My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor." As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android ha…

Re: Go is Google's language, not ours

#550

Post by dirkg » Wed, May 22, 2019, 7:43 PM UTC

pron wrote: post #503

bunderbunder wrote: post #335

Earlier quoted context omitted.

> Java has only things that were proved to work in other languages. But they still somehow keep finding ways to make them not work so well when implemented in Java. C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.

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…

async/await is fantastic and pretty much the direct inspiration for the exact same feature om ES6, where its a godsend.

C# i s one of the best dev experiences in any language/IDE