Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

591–600 of 679 posts

Re: Go is Google's language, not ours

#591
post #527
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…

> and native monitors

Are there any plans to fix those?

Re: Go is Google's language, not ours

#592
You want Go to be designed by the Internet equivalent of a cooperative? Isn't that how you get stuff like C++?

For some things Democracy is excellent (governance of nations, because it might be the least bad option). For other things a dictator is good (Amazon seems to be providing a lot of societal value under Chairman Bezos) . For yet other things perhaps a motivated group of technocrats might be better (Go).

I don't suggest I know the answer definitively. I could be wrong. But Go's results are good. Perhaps it would be fair for me to concede that I should examine this question again in 10 more years. What is good for 5-10 years might show problems in 20-50 years time.

After all, even communist North Korea was a relatively functional place for a time.

Re: Go is Google's language, not ours

#593
post #538
post #516

Earlier quoted context omitted.

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.

It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: https://news.ycombinator.com/item?id=19979613

Re: Go is Google's language, not ours

#594
post #309
post #278

Earlier quoted context omitted.

> It would effectively create a new language and in turn to a new ecosystem. And that new language would be Go++ (i.e. Go with generics) and what would be wrong with that? Consider how C++ started. It was nothing more than a preprocessor extension to the C language called C with classes . There is nothing stopping that Go++ turning into the Go equivalent of C++. So back to the previous OPs question, what's stopping s…

Because after his experience being forced to drop into BCPL from Simula, Bjarne sweared not to do it ever again. So when tasked to write his distributed network application in C at Bell Labs, his first step was to build something that would bring his Simula back, instead of bare bones C.

[deleted]

Re: Go is Google's language, not ours

#596
post #591
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…

> and native monitors Are there any plans to fix those?

Some ideas; nothing concrete. Need to figure out cost/benefit.

Re: Go is Google's language, not ours

#597
post #214

Earlier quoted context omitted.

I completely agree. When I first started writing Go (coming from Python/C#) I complained an awful lot about what felt like pointless hamstringing of functionality. Go is a simple language, and you don't get many toys. It also feels very verbose at times, and forces you to think a lot about doing things which seem automatic in other languages. However, as time went on, I noticed a few trends. Firstly, forcing me to th…

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…

>Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot.

Isn't that also a classic example of "boiling the frog" or Stockholm Syndrome?

Re: Go is Google's language, not ours

#599

Earlier quoted context omitted.

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

>Javascript isn't actually that bad of a language

Well, the basic parts are not that great. Plus, it has almost nothing of Scheme (nothing more than e.g. Python has of Lisp), that's just an old wives tale. It just has closures and that's it. Scheme is a Lisp, whereas Javascript isn't [1]. Not sure what Brendan had in mind when he was inspired by Scheme, but the end product is nothing like it.

Coercion rules are crazily bad. No integer type is stupid. Prototypal inheritance nobody much cared for (where nobody = very few). An empty array is not falsy. And several other stupid decisions besides.

The only reason it wasn't that bad, is that it wasn't big enough to be bad. It was just a handful of features plus a tiny (and bad) standard library (some math, some string stuff, etc). Everything else people had to build on top (and usually the did it badly).

[1] https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...

Re: Go is Google's language, not ours

#600

Earlier quoted context omitted.

If you mean intrusive data structures, Rust just doesn't support them. Everyone still manages to write software in Rust just fine. (There's some early support for immovable data with `Pin`, but that's only exposed via async/await at the moment.) Move constructors are one of the worst parts of C++ and being able to write movable, intrusive data structures is absolutely not worth the cost. If you do need one, Rust show…

> Move constructors are one of the worst parts of C++ Move constructors fix a narrow problem, which is, when you have something like a vector append, how do you copy over all the previous elements as a "shallow" copy rather than a deep one? In C with realloc(), it's just assumed that memcpy works for that. With C++03 and earlier copying the elements could very well end up duplicating everything on the heap for no rea…

Yes, every assignment of a non-Copy type is a move. (Copy types are basically primitive ones like ints, so not vectors etc.) The compiler prevents you from using the old variable at that point.

Since Rust always enforces that a move is a memcpy, a vector reallocation is just a realloc() like in C.

Post reply on HN