3 ms·
For the sake of argument, let's assume Go were equal to Java and C# (nb, I think that is not true, but let's look at the issue from that perspective). Can Go r
by fnl 9y ago
For the sake of argument, let's assume Go were equal to Java and C# (nb, I think that is not true, but let's look at the issue from that perspective).
Can Go replace C#? That's MS land and comes with the .Net platform. I think nobody will think Go is even remotely gathering its following from C# and the amount of tooling you get there is probably the largest set you can get.
What about Java? That has 20 years of entrenched Enterprise usage. So to make a dent on that, it not only has to have equal languages facilities, it also needs an equivalent ecosystem (maybe?) and, crucially, has to be better: Java replaced C++ as it's a much better fit at what it's used for due to GC and "no" resource management. But I certainly don't see anything that Go does that makes it much better over Java as Java was in it's day over C++.
So no, I don't see Go replacing .Net or the JVM anytime soon.
- fauigerzigerk 9y agoThat is a long list of straw man arguments. You keep refuting claims I never made while ignoring my point. I never claimed that Go is seeing any significant uptake in Java's or C#'s historical strongholds. I'm not talking about current usage at all. I also didn't say that Go is going to replace .NET or the JVM. I didn't even say that Go is better at anything. None of what you keep going on about has even the slightest thing to do with the point I was making. My point is very simple: Go, Java, Scala, C# and their most widely used implementations have similar enough technical capabilities to be useful for many of the same tasks. Therefore it is useful to compare them.
- fnl 9y agoAs I said right off the bat, if that's your argument, where are things like: generics, error handling facilities, macros, reflections, annotations, etc. in Go that are provided by Java, Scala, C++, C#, and Clojure?
- fauigerzigerk 9y agoWhat you need for a useful comparison is two things that are substitutable for each other in a particular context but not identical. Go vs Java meets these criteria. That's all I'm saying.
- fnl 9y agoWhich is why I said, we (mostly) agree: Go is great for web backend development, as I've never disputed in any reply, quite the contrary. My point was and is, that's all there is to "compare" - even if that area might be the biggest domain in IT right now.
- fauigerzigerk 9y agoHere's what you said: >Go is an alternative for C (for services), PHP, and server-side JS. I don't understand why people keep comparing it to languages like C++, C#, D, Java, Rust, or Scala. Your claim was that there is no overlapping area of application and hence comparing the languages makes no sense. That is where we disagree if that is still your opinion. Besides, I see abolutely no reason why Go couldn't be used for writing something like Cassandra, Kafka, Spark, Hadoop or a core banking system. None of these are specifically Web backends. Equally, I see very little reason why Docker or Kubernetes could not be written in Java or C#.
- fnl 9y agoI think our semantical differences are mostly due that there I was referring to language level facilities, then, while even in that post I clearly underlined Go's utility for web development. As to transactional processing, there's a reason why that's not using GC languages and why the banking and oil industry are one of the few mainframe clients left. Just because you can do X with Y, it doesn't mean it's economically or technically feasible.
- fauigerzigerk 9y agoDon't underestimate how much our industry is driven by fashion, culture, corporate backing, historical coincidence and inertia. Very few decisions are based on technical merit. Go read some of those "why we switched from X to Y". It's 99% rubbish ex-post rationalization of nothingness. In my opinion there is only one significant technical dividing line between language implementations: Mandatory automatic garbage collection. No other purely technical characteristic makes a whole lot of difference for the sort of problems that can be solved with comparable results using different language implementations. That's why it doesn't make much sense to me to put Go in a different basket than Java or C#. Doesn't mean there is no reason to prefer one over the other of course.