Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#271

Post by MetaCosm » Sun, Jun 14, 2015, 8:14 AM UTC

kibwen wrote: post #270

MetaCosm wrote: post #259

Earlier quoted context omitted.

> Tell me what you wanted Rust to do instead... Well -- if we are going into what I would have preferred. I would have preferred a rest period after release. No ongoing changes across 3 trains on a 6 week cycle. Give the community time to accept, adapt, bitch, moan, whine, create workarounds, and then better workarounds. Let enterprises have time to buy in, test, accept or reject and give feedback. Deal with critical…

You appear to have an expectation that the 1.0 release itself is an LTS release. I'm not sure where that expectation came from, but it is not correct. 1.0 is just the foundation for the language's stable evolution, and I don't expect any Rust code to linger on 1.0 in lieu of upgrading to 1.1. The arrival of the 1.0 release also doesn't imply that the language is "done" or ready to use for anyone's particular use case…

> if you would like to add your company to this list...

Sadly, in the near term, the Rust boat has sailed. LTS releases would give a real good reason to reconsider if they ever come about. What support durations are you considering for LTS, and where can I read more?

Re: Why Go is doomed to succeed

#272

Post by octatoan » Sun, Jun 14, 2015, 8:15 AM UTC

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

> Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun.

Very smooth. /s

Re: Why Go is doomed to succeed

#273

Post by octatoan » Sun, Jun 14, 2015, 8:15 AM UTC

neverminder wrote: post #162

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that f…

> shear speed

Do you write tools for a woollens manufacturer?

Re: Why Go is doomed to succeed

#274

Post by microtonal » Sun, Jun 14, 2015, 8:23 AM UTC

Elrac wrote: post #142

okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

Similarly, hashmaps, while built directly into the language in Go, are a library class in C++.

And this is a problem because?

(It's actually a weak point of Go that you cannot define them in a library without sacrificing type safety.)

Re: Why Go is doomed to succeed

#275

Post by pjmlp » Sun, Jun 14, 2015, 8:26 AM UTC

hyperpape wrote: post #113

coldtea wrote: post #42

Earlier quoted context omitted.

JavaEE sure does.

Certainly. I guess I'm not sure if I should call it the standard library or not (and if I should care whether I call it that).

Java SE also does include one since Java 6, but people don't read documentation it seems.

http://docs.oracle.com/javase/6/docs/jre/api/net/httpserver/...

Re: Why Go is doomed to succeed

#276

Post by pjmlp » Sun, Jun 14, 2015, 8:27 AM UTC

hyperpape wrote: post #34

gnuvince wrote: post #27

Earlier quoted context omitted.

Not the parent, but I've read many comments here on HN from users who feel that if a language doesn't include an HTTP server in the standard library, it's not ready for production work. Ridiculous, of course, but that may be what the parent is referring to.

Does Java meet the criterion you're describing here?

You mean like this?

http://docs.oracle.com/javase/6/docs/jre/api/net/httpserver/...

Re: Why Go is doomed to succeed

#277

Post by Elrac » Sun, Jun 14, 2015, 8:29 AM UTC

okasaki wrote: post #247

Elrac wrote: post #219

Earlier quoted context omitted.

Magic concatenation: the "+" operator is understood by the compiler to be the concatenation operator if either operand is a String. "Magic" in the sense that it's an exceptional affordance made by the language (not the library) for this one data type and operator. Auto-conversion: "2" + 5 = "25". This looks horribly hackish, like some type buggering perl might do, or js. But it comes in handy when you want to build a…

Magic concatenation: string hello = "hello"; string world = "world"; string hw = hello + ' ' + world; Auto-conversion: stringstream ss; ss

1 point for "magic concatenation;" I wasn't aware that works!

"nice try" on "auto-conversion".

Re: Why Go is doomed to succeed

#278

Post by Elrac » Sun, Jun 14, 2015, 8:30 AM UTC

microtonal wrote: post #274

Elrac wrote: post #142

Earlier quoted context omitted.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. And this is a problem because? (It's actually a weak point of Go that you cannot define them in a library without sacrificing type safety.)

I didn't say it was a problem. I was objecting to "C++ has all that."

Re: Why Go is doomed to succeed

#279

Post by pjmlp » Sun, Jun 14, 2015, 8:32 AM UTC

pcwalton wrote: post #35

coldtea wrote: post #29

Earlier quoted context omitted.

Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Rust, as a core language, has a lot more concepts to grok compared to Go or even Java. As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and…

> Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the s…

For many of us a complete language means the whole lot, e.g. IDEs, visual debuggers, a library for any use case, books.

This is most likely the why of the incomplete remark of the OP.

Re: Why Go is doomed to succeed

#280

Post by Elrac » Sun, Jun 14, 2015, 8:35 AM UTC

wyager wrote: post #269

Elrac wrote: post #142

Earlier quoted context omitted.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

There are a large number of people who would strongly disagree with the claim that implicit casting is a good thing.

Absolutely, and it's something I consider somewhat of a liability in (e.g.) Scala. You can drive yourself crazy if you're not careful.

However, I feel that doing the "implicit casting" thing only for the single, limited case of string concatenation strikes a happy medium between providing useful convenience and giving you enough rope to hang yourself with.