something about 4 CPU systems being the max at the time
Ignorant BS. You just proved your self 100% clueless.
something about 4 CPU systems being the max at the time
Ignorant BS. You just proved your self 100% clueless.
You're going to argue that Play in 2009 was not obscure? Your audacity is mind-boggling.
It was the most light-weight, most non-obscure of all the Java frameworks. I understand this can be difficult to understand. Ask someone who knows Java the next time you meet them. Now, can you find another source that agrees with your moronic 10:1 advantage? Fanbois are tiring.
So linq is generally useless according to your own statements for the class of systems we're discussing
Did I ever argue it was? However, in all systems there are significant portions that are not performance critical. Even if the overall system is. In those areas, Linq is better than the alternatives.
not least of which was obscurity
Obscurity? You have to be kidding me.
The only statement I'm making is that your statement implying that Play ported anything from
So you clearly know a lot more than the creators of the Play framework. You can go here and see what the Play framework creators think that they them selves did, but hey, you probably know best. Play comes with Twirl, a powerful Scala-based template engine, whose design was inspired by ASP.NET Razor. Does it hurt to be that dumb?
you were processing a multi-million row complex data set on the fly for every query?
Talking about reading comprehension...Imagine processing a certain type of performance data every 15 minutes. This is the monstrous data set. As part of that processing, you are required to enrich certain records with data retrieved at the beginning of the fifteen minute interval from an external source. One where you have no ability to control the result set size. Was that difficult to comprehend? That data must be processed, in memory, prior to you being able to do any form of data enrichment. Was that difficult to comprehend? Again, have you ever worked with external data providers?
Setting up a simple searchable data polling proxy service, however, should take you all of a couple of weeks, tops
You have clearly never worked with the government. It can't do anything in "a couple of weeks". A couple of years, perhaps. The big telcos are similar, or at least were ten years ago.
Hey, let's see you back up your 10:1 speed difference. Moron.
That's why I restrict linq discussions purely to DBs
No, that's not why you restricted it to just DBs. You restricted it to DBs because you are ignorant. You don't use Linq2SQL in your app. It's that fucking simple. Not if performance is important. If performance is not important you also do not use Linq2SQL, you use the Entity Framework, which can be queried by using Linq, but it isn't a part of the framework. Linq is not, has never been, and will never be a DB framework. You are equating your own ignorant opinion to basic facts. The problem with opinions is that they are lie assholes. Everybody has one and they mostly stink. Fact: Linq has nothing to do with DB access. Your opinion in that matter is irrelevant. It is contradicted by fact. Also, more on your vast inexperience below when you say retarded stuff like: "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory"
But some languages and features promote bad architecture
Java and C# are basically identical. The framework that have grown up around them are also basically identical (and porting between the two is plentiful, so you can get monstrosities like nHibernate and more useful stuff like log4net. Yes, languages and frameworks promote bad architecture, and Java and C# are so close to being identical that they promote identical architectural solutions. Since C# has developed in the wake of Java, it has avoided some of the monstrosities of Java, such as EJBs and the whole J2EE nonsense. Conversely, where interesting stuff was done in
yet you failed to comprehend what that example was telling you
No, it told me plenty. All of it about you. You have no experience with larger systems. You have no experience integrating with external systems over which you have no control. Here is an example of your mind-boggling in-experience. Your comment "You're already toast in my scenarios if you are passing more data than you need into your applications and are parsing shit in memory". I even told you why this was necessary but you simply have no experience with integrating with external systems. You therefore have never been in a situation where you have no choice. The service I was specifically talking about above was an external government (non-US) service which we could query for information vital to our system. The service had no search facilities, it had no possibility of limiting the data set you pulled down. In other words, we had no choice but pulling the data down, and it had to be real-time and do the filtering in memory. It took us seven years to get them to put an API in place and it would have taken us another five to get them to make the data searchable. You have clearly never attempted to gather data from data sources that were not your own and that you therefore had no control over whatsoever.
As for Apple 1) they built it on AWS, 2) when Azure was stable enough they distributed their risk. 3) Azure is at least 33% Linux based
Apple built the iCloud on AWS and Azure simultaneously, and the two serve somewhat different purposes. But hey, let's look at the rest of your statemment, shall we?
3) Azure is at least 33% Linux based
Yes, obviously. Microsoft released Linux on Azure in 2013, after it having been available in Beta since late 2012. So, when did Apple launch the iCloud on Azure? 2011.
You are a pretentious fool
If I was pretentious I would have to make positive statements about something. The only example of self I have used was in response to some pretentious nonsense you blabbered about one million rows in a DB as if that was a lot. I have personal projects that are bigger than that. The only thing I have pointed out is your nonsense. Your obvious ignorance. You seem to think that Java promotes a better architecture for stuff than C#. Since they are basically the same it is obvious nonsense. You claim that Linq is DB related, which is provably wrong. You claim that there is an inherent 10/1 speed difference between Java and C#, a statement that is proven wrong by every single performance test ever done on the two. Every single one. Then you go and blabber on about how the fact that a bunch of moron developers develop software that is less performant than some software built by competent people proves your point. Also, you claim that a feature millions of developers have been praying that Oracle would add to Java has no value. Finally you prove your inexperience by showing you have never in your entire life been required to fetch data from external data sources you have no control over.
The only pretentious nonsense spewed in this discussion have come from your side. You have proven one thing, and one thing only, that you are an ignorant fanboi.
Here is the reality: Java and C# are almost identical in features and framework development. Neither is significantly better than the other, and with Lambdas finally appearing in Java, many of the C# language advantages are gone (but don't get me started on a rant about what a cluster fuck auto-boxing in Java is). Anyone who claims there is a huge difference between the two is either a moronic fanboi or just ignorant. However, writing C# code requires fewer lines for comparable functionality. The language and the framework is moving at a faster pace than that of Java, and good developments happens a lot faster in
it pretty much fails to deliver as soon as you get to anything interesting
Could you elaborate please? Again, keep databases out of it, Linq is not a database framework. The fact that you continue to compare Linq to Hibernate shows you think Linq is database related, which just shows your ignorance. Linq has nothing to do with databases.
Lambdas? I haven't seen where they are significantly better than other simpler solutions
You are kidding right? Lambdas are the simple solution, they make code more succinct and to the point than the alternatives. Your statement shows that you think you know best and everybody else is wrong. This just shows a staggering level of ignorance. There is a reason "everybody" wants Lambdas. They make your code better. They are not magical, but succinct code is better than overly verbose code, which the code is when not using lambdas.
You can accept that statement as is or not.
Considering the fact that all you have provided so far is ignorant nonsense (about both lambdas and Linq) I take what you say for what it is. The ramblings of someone who's relevance has come (being nice here) and gone. Probably decades ago.
The Java app was far more modular
So you are not comparing Java to C#/.Net. They two are close to identical in base features, so it is impossible to make a Java app that is more modular than you can make a
Sometimes bad architecture lays a crumbling foundation that just can't be corrected.
Yeah, but bad architecture is not a framework or language feature. Bad architecture is a feature of the software developers implementing the solution. Using bad developers as an example to illustrate bad frameworks or bad languages is moronic, to put it mildly. If you had any experience as a developer, you would know that.
Java's outperforming C# is based on real world scenarios
No, it is not, and you just said it is not. In real world scenarios nobody in the world has observed what you claim. You are the only one. So, is everybody in the world an idiot and you a genius? Probably not, you are just ignorant. You said that the reason the systems you were struggling with were bad was because of incompetent developers, not a bad framework or a bad language decision. The performance is based on the fact that the developers you are talking about were morons, not that the tools they had selected were bad. Bad architecture creates un-maintainable software, bad architecture will usually result in under-performing software, but that has nothing to do with the tools. Seriously. You can't be this dumb!
A current startup project is still in testing stages, and tables are already touching 1M rows...
If each of those calls hit 5 tables...
So you are talking about relatively small systems with few tables and quite moderate amounts of data. OK. That may explain things. You simply haven't worked on teams where performance is an issue, you have had some straight-out-of-school kids do some stuff in
Imagine an MPLS switched network with about 20 000 nodes, switches some servers etc. They are all SNMP managed, and they have 64 or 128 points each that regularly report status back to the NMS. On average approximatley once per hours at night, more during the day.In addition there is about 100 performance counters for each of the devices from which performance data is collected every 15 minutes, aggregated to hourly, daily, weekly, monthly and yearly aggregated values. The data collection alone means about 10 million inserts into the database every hour. Stored procedures aggregate these values, and they are presented as close to live as possible in various dashboards. That's not a very large system, it is bigger than the bookstore example you provide, but it's not one of our bigger installations. It runs entirely on the
Let's look at another one, one that you are maybe familiar with. It's called the iCloud. You know, the infrastructure on which Apple is relying to serve all of its Apple Mac and iDevice customers. Apple didn't have the infrastructure in place to build their own, so they out-sourced it. To Microsoft Azure (and also to AWS). Azure is built onw which platform again?
You're a moron.
If you're talking about LYNC
I assume, since this was in a DB context, you meant Linq, Lync is a messenger thingimajig I believe. Linq is a language feature not a tool, if you don't know what tools are ask a programmer. Oh, and I doubt the number of developers in the
Linq on the other hand just another way to write Lambda expressions, in fact, Linq queries are compiled to Lambda expressions by the C# compiler. If Linq is bad then Lambdas are bad. If Lambdas are bad then I am curious as to why the Java community has been begging for them for years. Linq can be used to write lambdas for any collection type. I currently fetch Json from a very, very slow government server somewhere and I use lambdas to parse the data as it comes back. Since the server in question doesn't do any filtering on the data at all, and I'm only interested in about 5% of what it returns, having a single line of code extracting what I need is cool. I can write [obviously it's a tad more complex] var myStuff = allStuff.Where( s => "value".Equals(s.property)); which is quite useful. The code runs once every 24 hours, so I don't really care if it runs in 2ms or 3ms. If performance was critical, I might have written it differently. Why being able to query Json like that would be a bad thing is a mystery to me. Can you elaborate please? Why are lambdas horrible? I could have written it in Linq too (from d in data where d.property == "value" select d) but that would have been more verbose and to me (but that is just preference) less clear. The code is identical though, once it's run through the first compiler step. As a side note - about a year ago that server returned a highly convoluted XML stream instead of Json. The code to filter my data from the XML result didn't change at all. I can query Json, XML, a list of C# objects or a database with the same line of code. As I said, I'm not saying it is hugely performant, but for most Enterprise applications that is actually not an issue.
Now, you can easily argue that Lambdas (and by association Linq) are not performant enough for high-performance applications, and depending on how the lambda implementation for various entities, you would most of the time be correct. So, stay away from them. Linq and Lambdas are great for many types of applications where performance is perhaps important but load is lower.
The Java system easily outperformed the
Seriously? This comment alone shows that you are lying through your teeth. There isn't a single benchmark in the world that would give a ten to one speed advantage for Java over
was updated multiple times for each
So you claim it is easier to update Java apps than C# apps? That's just nonsense. Fanboi warning. Remember, your programming language is a tool, not a savior of your soul. Get a grip. The similarities between C# and Java are significantly more important than the differences, but C# tooling is far better. Re-factoring, for example, in Visual Studio with Re-Sharper blows the Eclipse variation out of the water, it easily beats IntelliJ too. The fact that Visual Studio can use the C# compiler to do re-factoring is an excellent feature I have yet to see elsewhere (but I might not be 100% up to date on that one).
you just can't touch Java's performance or productivity with C#
That is a statement backed up with zero data. It's also pure nonsense. If you are a knowledgeable programmer you are simply lying, if you are not consciously lying you are not a knowledgeable programmer. Prove me wrong by fleshing out the statement above with some actual reasons and data. Don't and you prove me right.
Companies that use
Can you elaborate on why?
Would be better to use an open source toolkit rather than to make oneself hostage of MS,
Ah, that explains it. You are just clueless. Let''s see, what Open Source tools are
The reason the folks switched from
This is pure nonsense. I did Java for the Enterprise from 1997 through 2006. I worked for one of the first companies in the world that had significant product for the Telecom world written in Java. Back then we could not inform our customers it was Java since Java was perceived as too slow for our market segment. A colleague of mine wrote an SNMP stack at the time that was at least two orders of magnitude faster than any other stack out there. I struggled with CORBA when the Iona C++ ORB would not talk to the Iona Java ORB.
Since 2008 I've been doing about 20% Java, 60% C#/.Net and the rest a combination of Ruby, C and some Scala. C# blows Java out of the water in every single way. Tooling is heads and shoulders above what Java developers have wet dreams about. Scalability is certainly not inferior to Java in any way. The C# language has been significantly better than Java since 2008, and the distance between the two is increasing. Ongoing maintenance cost for
Java is playing catch-up, but it is playing catch-up-by-committee. It's not catching up.
Actually handling physical discs is rubbish
Only if you don't care about image quality, and if you don't care about image qualit, wtf do you worry about 4K or even HD for? Streaming HD quality is marginally better than SD. If you have a 40-45* TV and sit ten feet away, you can not really see the difference between streaming HD and SD. Streaming 4K content today is of lower at times significantly so, quality than 1080p. Watching 4K content on Neflix is terrible. The footage is sharpened to the unwatchable. But hey, if you don't care about image quality, that's OK. Just get the biggest, cheapest TV you can get. Don't ever get a 4K TV.
and I'd be pretty hard-pressed to see a difference between 1080P and 4K even at that size
How far from your "TV" are you sitting? 20 feet?
like they're going out of style
and they will, really fast.
node.js is just awful. Why would anyone think that is is more scalable than the LAMP stack
This is one of those comments that are too funny. A person talking up a horrible, terrible, monstrosity of a piece of junk (PHP) as a solution to another horrible, terrible, monstrosity (in their opinion) node.js.
Machines have less problems. I'd like to be a machine. -- Andy Warhol