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.
Why Go is doomed to succeed
251–260 of 330 posts
Re: Why Go is doomed to succeed
#252Earlier 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…
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
#253Earlier 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…
Re: Why Go is doomed to succeed
#254Earlier 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…
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
#255I'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…
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
#256Re: Why Go is doomed to succeed
#257Earlier 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.
Re: Why Go is doomed to succeed
#258It'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.
[ 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
#259Earlier 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…
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
#260Earlier 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.