Live data from Hacker News

Why Go is doomed to succeed

texlution.com

251–260 of 330 posts

Re: Why Go is doomed to succeed

#251
post #243

Earlier quoted context omitted.

Right, Google just needs to will something to succeed, and poof , the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success. Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient cond…

Yes, but Go solves a real problem for many people and isn't attempting to turn a profit. I wonder when it would be at the point where it could sustain relevance without further funding.

[deleted]

Re: Why Go is doomed to succeed

#252

Earlier quoted context omitted.

I agree. Also, maybe Rust-the-community isn't ready to honor promises ( http://blog.rust-lang.org/2014/10/30/Stability.html ) it makes, which is critical for enterprise adoption. Twenty-two days after release, Rust started talking about making breaking changes ( https://internals.rust-lang.org/t/pre-rfc-adjust-default-obj... ). This conversation killed a Rust project I had pushed for... it played into all the existin…

The promise was "we won't break your code". The conversation was to determine the answer to the question "is there any code out there that this will break", because we take that compatibility promise seriously and want to honor it. If you're unhappy that we're having that discussion, well, I'm sorry, but we need to have these kinds of discussions if the compatibility promise is going to mean anything. The alternative…

> If there's no code out there that actually breaks, then I don't see the problem.

Exactly, which was my point. Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in organizations... and a bit of a kick in the junk to those of us who supported it. You saw it as without impact, when it has already had a huge impact on at least one organization.

> Golang has made many changes that could technically, and actually did, break code as well (just to name a recent example, the GOMAXPROCS default bump; there have been several others).

Rust isn't Go, that might seem "unfair" but that is the way it is. Go does not have the same reputation to fight against as Rust, the same famed history of breaking peoples code who are trying to use it, Rust WILL be held to a higher standard when it comes to breakage than ANY other language I suspect.

Re: Why Go is doomed to succeed

#253

Earlier quoted context omitted.

I agree. Also, maybe Rust-the-community isn't ready to honor promises ( http://blog.rust-lang.org/2014/10/30/Stability.html ) it makes, which is critical for enterprise adoption. Twenty-two days after release, Rust started talking about making breaking changes ( https://internals.rust-lang.org/t/pre-rfc-adjust-default-obj... ). This conversation killed a Rust project I had pushed for... it played into all the existin…

The promise was "we won't break your code". The conversation was to determine the answer to the question "is there any code out there that this will break", because we take that compatibility promise seriously and want to honor it. If you're unhappy that we're having that discussion, well, I'm sorry, but we need to have these kinds of discussions if the compatibility promise is going to mean anything. The alternative…

[deleted]

Re: Why Go is doomed to succeed

#254

Earlier quoted context omitted.

The promise was "we won't break your code". The conversation was to determine the answer to the question "is there any code out there that this will break", because we take that compatibility promise seriously and want to honor it. If you're unhappy that we're having that discussion, well, I'm sorry, but we need to have these kinds of discussions if the compatibility promise is going to mean anything. The alternative…

> If there's no code out there that actually breaks, then I don't see the problem. Exactly, which was my point. Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in orga…

> Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in organizations... and a bit of a kick in the junk to those of us who supported it.

Tell me what you wanted Rust to do instead. Again, the options seem to me to be either "make potentially-breaking changes silently without gathering feedback" or "make no changes to Rust that could break any code ever". If the latter, realize that this implies we could never add functions to modules (because of glob imports and shadowing), we could never add modules, we could never add trait implementations (because of method resolution), we could never add to the prelude, we could never upgrade LLVM (because of undefined behavior), and probably a whole host of other things I'm forgetting.

> Go does not have the same reputation to fight against as Rust, the same famed history of breaking peoples code who are trying to use it, Rust WILL be held to a higher standard when it comes to breakage than ANY other language I suspect.

I'm not sorry for doing so much development in the open instead of behind closed doors, even if everyone got to see how much the language changed from 0.1 to 1.0 and it acquired a reputation of "changes all the time". The point is, it doesn't change all the time now. From 0.6 to 0.7, for example, all code everywhere broke. Same with 0.7 to 0.8, 0.8 to 0.9, and 0.9 to 0.10 (though the amount of breakage got less over time, as you would expect). Conversely, the amount of breakage between 1.0 and 1.2 (assuming the trait lifetime change goes through) is so minuscule we don't even know of a single crate anywhere in existence that it would break. This is, in my view, so different as to be incomparable.

Re: Why Go is doomed to succeed

#255
post #172
post #86

I'm curious about two things. (1) where does Rust fit in this? (2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?

> Why don't people use Erlang/Elixir Because Erlang is different . It's not just the syntax, even though that throws many people uncomfortable with much that's not a direct descendant of C syntax; it's the whole programming model which requires a real shift in perspective that simply isn't easy. It's worth it once you start to "get it", but that can take a bit. I do think Elixir gives the Erlang VM a better shot at t…

> Because Erlang is different.

I'd say that fails to capture the full scope of the statement.

From where I stand, Erlang is not just a language - it's an extremely robust, highly opinionated event loop with its very own DSL.

Re: Why Go is doomed to succeed

#256
post #220

Earlier quoted context omitted.

But what happens when some of the apps require different versions of the JVM?

As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.

Except on those fun occasions when it isn't really. :\

Re: Why Go is doomed to succeed

#257

Earlier quoted context omitted.

This is helpful. Thanks! I have one more question, how does Go ensure easy concurrency?

Assuming that's an honest question: it has actual lightweight threads, so you don't need to muck around with either async garbage or worrying that you're using too many threads because you aren't mucking around with async garbage.

Yeah,I was reading about the http module and goroutines. It looks nice. Though I still have to try it.

Re: Why Go is doomed to succeed

#258

It's an interesting language test, of how easy it is to understand an open source project. Looking at github, the lines of code are usually easy to understand in C and java. What's difficult is how the parts of the project fit together (which is never documented). Does Go help with that?

I think it can help with that in the sense that Go packages don't have complex boundaries and the type system is simple and self-contained. You don't have to trace an inheritance hierarchy to understand any given type, so a project of multiple packages is generally easy to understand just by reading each piece independently.

Inheritance can be a problem, but I was thinking more of the architecture, what calls what, who is in control, where are the various tasks done, what are the interactions... I'm not sure how a simpler type system would help with that e.g finding out which module does the task of interest, but I don't know Go.

[ Design patterns were supposed to help with this, with recognizable groups of classes. Sounds like a good idea, but I haven't found that, but maybe I don't know them well enough, or projects don't them well enough. ]

Re: Why Go is doomed to succeed

#259

Earlier quoted context omitted.

> If there's no code out there that actually breaks, then I don't see the problem. Exactly, which was my point. Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in orga…

> Rust-the-community (and you as a member of it) see no problem with it... which for me, IS the problem. The timing, the fact that it played into all the existing narratives about why you never trust Rust, it made it a brutal bit of political weaponry in the hands of those who are pushing against Rust in organizations... and a bit of a kick in the junk to those of us who supported it. Tell me what you wanted Rust to…

> 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 issues and focus on stability as a deliverable... and don't break anything during the rest period (even if that means being on a single version of LLVM and no new traits or modules or functions or whatever). But, that ship has sailed.

> I'm not sorry for doing so much development in the open instead of behind closed doors

Who asked you to be? I was simply pointing out the reality that Rust has a reputation to contend with -- you can't change that be being righteous about it, it just is.

Re: Why Go is doomed to succeed

#260

Earlier quoted context omitted.

What a strange idea. The whole point of a programming language is to enable abstraction. I suppose assembler doesn't let you "abstract yourself in the foot" (whatever that means) either.

There is such a thing as too much abstraction. That's partly why Java has now that huge reputation of being a very enterprisey language.

That is actually due to a lack of rich abstraction mechanisms in Java.
Post reply on HN