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

531–540 of 679 posts

Re: Go is Google's language, not ours

#531

Post by erik_seaberg »

sjellis wrote: post #42
RcouF1uZ4gsC wrote: post #2

To determine how open a language really is look at how many widely used implementations of the compiler there are for the language. If there is only a single implementation of the compiler/interpreter than it is not really open but controlled by that core compiler team.

The TinyGo project are implementing a Go compiler on top of LLVM, to use Go on very small devices: https://tinygo.org/ The Go language is defined by a spec with compatibility guarantees, but beyond embedded systems and WASM, there don't seem to be a lot of use cases for alternate implementations.

I haven't looked into compiling Go to JVM bytecode, but a solid way to do that would resolve an ongoing tug-of-war at work, and avoid a lot of résumé-driven development of stuff maven central already had.

Re: Go is Google's language, not ours

#532

Post by DaiPlusPlus »

weberc2 wrote: post #512
dnautics wrote: post #484

Earlier quoted context omitted.

> it's not too verbose that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.

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.

Re: Go is Google's language, not ours

#533

Post by tracker1 »

jolfdb wrote: post #330
castlecrasher2 wrote: post #291

Earlier quoted context omitted.

Companies pay Oracle because 1) PostgreSQL doesn't take you to lunch and 2) Oracle "just works." I mean, we all know #2 is effectively a lie but having the option to go to Oracle directly for issues (even if the response is just "pay a contractor") immensely reduces risk for executive leaders.

You can hire a Postgresql contractor for admin, bugfixes and features, and you can pay Postgresql corporate for bugfixes and features

Last time I was in a position to try, not so much. I emailed about 15 such contractors at least close to the SW US (I'm in Phoenix), and didn't get a single response. This was 5-6 years ago.

Re: Go is Google's language, not ours

#534

Post by iends »

ashton314 wrote: post #440
iends wrote: post #316

Earlier quoted context omitted.

It seems to me that you’re going to have a lot more trouble maintaining Elixir code than Go code over the long run.

What makes you say that? I personally don't see Go and Elixir's primary domains as being equal, or one a superset of the other. So there's some argument to be made about the region where they overlap, but for something inherently based around fault-tolerance and distribution, seems to me that code written to run on the BEAM will be smaller and clearer and therefore more maintainable.

If I'm interested in building low latency and highly available web services it seems to me that both Go and Elixir are reasonable choices. How are they not the same primary domain?

But in any case, Elixir allows a lot more clever code. In my experience working on legacy software, clever code in a dynamic language is error prone and hard to refactor and maintain. Static typing can help, though, I've found this especially true in functional languages where you have a super smart developer do something clever that's hard to understand 5 years later.

Re: Go is Google's language, not ours

#535

Post by divan »

computerex wrote: post #448
divan wrote: post #151

It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations. Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team)) There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2] The way how…

The article barely even talks about generics, though (and takes a favorable position towards the Go team). What are you on about? Did you read the same article I did? https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo... The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.

> barely even talks about generics

Yet uses it as an opening line to build the whole argument on.

Re: Go is Google's language, not ours

#536

Post by emn13 »

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…

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 overreaction against the C/C++ of the day, and whereas the GC turned out brilliant, the idea that it's not even necessary to express the notion of references/pointers/values etc. was too much; and the idea of a single type system root (object) is similarly dubious, and then particularly the idea that that root type isn't the empty type. Object has semantics, and that was a mistake, because it contributes to the bloat. I'm totally happy with ignoring those features 99.9% of the time, but having them completely unavailable makes those 0.1% cases extremely expensive. (I mean, I think those things are slightly changing, but it's slow going).

Re: Go is Google's language, not ours

#537

Post by satyenr »

erik_seaberg wrote: post #487
insertnickname wrote: post #443

Earlier quoted context omitted.

>Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you. It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.

This. If you want to revolutionize the profession, come up with something that helps with reading as much as modern IDEs help with writing. My answer is that boilerplate should be generated somewhere else and largely ignored.

IMO, boilerplate source code shouldn’t be generated at all — the tool chain should directly emit the required object code. And code generation shouldn’t require a different language — or special comment syntax.

Re: Go is Google's language, not ours

#538

Post by divan »

apta wrote: post #516
Retra wrote: post #483

Earlier quoted context omitted.

It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.

The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.

I disagree, as I remember a lot of talks and articles from Go team members where they discuss in detail established work in other languages – on GC, on language evolution, on generics and so on – and deliberately learn from them to avoid same mistakes.

Re: Go is Google's language, not ours

#539

Post by hu3 »

docker_up wrote: post #486

I like Go a lot, but the fact that Google doesn't use it extensively in their own environment makes me wonder why that is. It almost feels like a Trojan horse.

Rewritting software is expensive.

I'd be surprised if any new language becomes prevalent in less than multiple decades within Google's unfathomable scale.

Re: Go is Google's language, not ours

#540

Post by divan »

FroshKiller wrote: post #371
divan wrote: post #154

Earlier quoted context omitted.

Go team is actually incredibly open and approachable if you meet them at conferences. Google (as a company) has little influence on the language design design. Its needs has shaped design (obviously), but it's not like there are requirements outside of the Go team. Go is heavily used in Google, so it's a natural dogfooding process, but that's it.

"If you meet them at conferences" is a huge if of inaccessibility.

Haha, sorry, they're open outside of conferences too :)
Post reply on HN