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

561–570 of 679 posts

Re: Go is Google's language, not ours

#561

Post by JamesBarney »

Raidion wrote: post #384
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.

Idk, have you seen the interfaces with default implementations in latest C#? Also duck typing? Both are mistakes IMO. First missteps I feel like I've seen C# make.

Why don't you like default implementations?

Re: Go is Google's language, not ours

#562

Post by ashton314 »

iends wrote: post #534
ashton314 wrote: post #440

Earlier quoted context omitted.

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

What about distributed programming? The BEAM makes that sort of thing super easy.

Maybe Go does have good primitives or libraries for that, and I'm just ignorant of that. :)

Re: Go is Google's language, not ours

#563

Post by pron »

pjmlp wrote: post #542
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…

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.

There's a difference between useful, and even very useful, and absolutely necessary. Clearly value types weren't absolutely necessary, as Java did well without them (and JS still does).

Gosling said that his goal was to have nothing you can somehow live without (I don't know how well early Java lived up that ideal, but that was the ideal). Hardware changes made user-defined value types absolutely necessary for workloads Java wants to target.

Re: Go is Google's language, not ours

#564

Post by reflexer »

naikrovek wrote: post #235
reflexer wrote: post #209

Earlier quoted context omitted.

wrt a "proper" way: adding item to a slice, uhmm?

A slice isn't an array. A slice is a view into an array. You don't look through a window in your house into the backyard, and plant a tree in the backyard by fiddling with the window. It's the same with arrays and slices in Go. If you want to insert an item into a slice, insert it into the array (by copying to a new array and adding your new element to it while copying), then creating a new slice which includes your…

I meant that go's append idiom to reallocate array behind the scenes seems to me somewhat complicated and error-prone.

Re: Go is Google's language, not ours

#565

Post by computerex »

divan wrote: post #535
computerex wrote: post #448

Earlier quoted context omitted.

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.

He doesn't build the whole argument on it. Generics just happens to be one of the most polarizing, most talked about subjects in the Go community. It's no surprise the author alludes to it. In his own words:

> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.

Re: Go is Google's language, not ours

#566

Post by neop1x »

It is actually a good thing. The more forks there are and more complicated ideas and toys, the more mess and chaos. It can eventually kill the whole ecosystem.

I love open-source and libre software but there needs to be some central authority who oversees the changes and is forward-thinking. I actually love Go in the way it is and it wouldn't be it if you kept asking community what features to integrate. I am looking forward to generics as it solves some cases (containers holding items of a templated type sharing some common methods). But even if Go stayed the way it is, I would be fine. The point of open and libre in this project for me is that Google can't shut it down and that's enough for me in the case of prog language.

Please, if you want to make super-crazy-new community-driven uber-language which will change the world, make yet another and truly yours language or join Rust or whatever more community-driven language you like. Thank you! :)

Re: Go is Google's language, not ours

#568

Post by jimmaswell »

eropple wrote: post #557
jimmaswell wrote: post #522

Earlier quoted context omitted.

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 .

I do mean that, and I do mind it a lot when I'm so used to just being able to erase the generic. There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.

This is the only non-bad consequence of type erasure I'm aware of. On the other hand, a lot of code I've written in C# would be impossible or severely hacky without type retention, like "new T()", "T is Thing", finding all classes that are derived from T, etc.

Re: Go is Google's language, not ours

#570

Post by neop1x »

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.

You mean for example various versions of java which are incompatible?! Or java programs said to be mtiplatform loading .so libraries of fixed Ubuntu versions? Well, that's exactly what I hate.
Post reply on HN