“Java inventor James Gosling says he isn’t losing much sleep over Microsoft these days, despite the software giant’s effort to stem Java’s popularity with its own Java-like language. The next battle in Web services software development pits Microsoft against Java creator Sun Microsystems, along with Java adherents IBM, Oracle and others. Crucial to Microsoft’s effort is C#, a Java-like language that will soon be part of the company’s new Visual Studio.Net package of software-development tools, which was released to developers Wednesday.” Read the rest of the interview with James Gosling at C|Net News.
Java’s SuperStar on Why Microsoft’s C# Isn’t
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
C# is.
If he wasn’t losing sleep he wouldn’t be making a statement. Yada yada yada.
C# isn’t anything special… just another language to clutter the already messy landscape of languages available… bah… C… possibly REBOL if I wanna write something really quick and have it work on 50+ platforms… PHP/Perl for webdev… ahh :]
Eugenia – can we get an update from the REBOL team regarding IOS Express and how it will compete with Java and .NET?
Rugby, the distributed request broker for the REBOL platform has been ‘mysteriously’ dropped by its creator Maarten. Quote from the Mailing List:
From: Maarten Koopmans
All,
Rugby is officially dead, the web sites have been removed. You may use it
(including republishing) as the BSD license indicates if you stil have it.
With IOS coming Rebol will have a built-in distributed system. If IOS fails
there is no case for such thing anyway. I feel it is in Rebols best interest
if there ‘is only one’.
Thank you all for using it and making it a fun.
Goodbye,
Maarten
There was an interesting reply from Holger at REBOL in response to everyones questions as to why Maarten did it:
We at RT are as surprised about this as everyone else.
At the technical level IOS does have some overlap in functionality
with Rugby, but it is targetted towards different markets and
applications than Rugby. I do not see any kind of threat for one
of those products by the other and, from that perspective, see no
reason to discontinue work on Rugby. Maarten may have had other
reasons though.
<snip>
Well, Rugby is released under BSD licence though, so anyone can take it over, … and will do so 😉
-pekr-
It’s like comparing apples to oranges. Script languages are useful for writing utilities and small web sites. But since they have dynamic typing and most of them are not compiled, they suck when you want to write big, efficient, safe applications. That’s where Java and C++ (and maybe C#) rules.
Phazer, pardon me, but why not to compare? What is the issue with app being written using any tool? Only the user experience matters. What about following:
– java is multiplatform, but a little bit bloated and slow for UI
– C++ is not easily multiplatform, although apps created using it are fast
– Rebol/Python/etc. are scripting languages, are multiplatform and user experience is exactly the same as if the app would be written using any of Jave/C++/C#
I don’t buy your reasoning for scripting-lang-based-app != efficient + safe …
As for big apps – not everyone wants to code office suite, or just define what do you mean by “big” … 😉
-pekr-
As far as i recall correct me if im wrong isnt J# the java offensive product C# is nextgen of VC++ just wondering.
Java is buried too deep for Microsoft to unroot it now. There are too many Java developers/programmers and with Microsoft’s bad reputation of money first and quality product later, it’s not going to happen anytime soon and you can bet on that!!!
In some programs only the user experience counts, but in others there might be other things that counts. Some important measurements of a program is efficiency and stability (few bugs). Script languages are dynamically typed which means:
– They are slower than statically typed languages (the compiler cant optimize as much). It’s a fact that script languages are a magnitude slower than for example C++.
– The compilers dont find as many compilation time errors as compilers for statically typed languages (like C, C++, Java etc.). Typically you must perform runtime checks instead, but if you create a big program (10000+ lines of code) this can be VERY time consuming and tedious.
I dont say that script programs can’t be efficient or stable, but it’s easier to write an efficient and stable program in a statically typed language.
Every language has it’s use, but some have more uses 🙂 I see dynamically and statically typed languages as fundamentaly different and I dont think it’s fair to compare them to each other.
Well it seems that Maartens wife slapped him about a bit and he’s decided to carry on with Rugby development but under a GPL rather than BSD license
This is good news for us rebolers who like distributed programming
> n some programs only the user experience counts, but in others there might be
> other things that counts. Some important measurements
> of a program is efficiency and stability (few bugs). Script languages are
> dynamically typed which means:
> – They are slower than statically typed languages (the compiler cant optimize
> as much). It’s a fact that script languages are a magnitude slower than for
> example C++.
Java is also an order of magnitude slower than C++ because it does a lot of runtime checks.
For a cool language, check out http://www.RapidEuphoria.com/
> Java is also an order of magnitude slower than C++ because it does a lot of runtime checks.
No. For typical applications Java is about as fast as C++. C++ is a little faster for algorithms.
Microsoft claims that C# is the next generation of C/C++, however, anyone who has been following C# at all can tell you (unless they are lying) that C# is Java without Sun’s JVM. J# is a path for Java developer’s to update their existing code to .NET. J# is worthless and nobody in their right mind will touch it.
“C# is.”
Is…A waste a time? Sure.
Is…A rip-off of Java? Yes.
Is…Not going to get the slightest bit of my attention? Absolutely.
Phazer
No. For typical applications Java is about as fast as C++. C++ is a little faster for algorithms.
On what planet? Have you ever done any profiling of Java code? Do you have any idea how many asm instructions have to be exectued to run a Java app? C# is on the order of 10x faster than Java, and it is still 5x slower than C++, which is 5x slower than C (numbers are approx).
I would be interested in seeing Java running 10x slower than the exact same C code. I’ve seen factors like 2x with modern day JVM’s, but not 5-10x. I’ve benchmarked math operations in Java versus C/C++. Once the code is run through the JIT, it is pretty much just as fast as C/C++ is. Since a large number of math operations are very iterative, it will get run through a JIT very soon. GUI performance has too many variables to blame the JVM versus poor coding.
> On what planet?
Earth.
> Have you ever done any profiling of Java code?
Yes. I’ve done some mathematical benchmarks and Java code is typically a few percent slower than similar C++ code.
However, micro benchmarks like this are not really important for an object oriented application, instead you measure things like object creation and deletion, method dispatching etc. This is where most of the compiler research are made.
> Do you have any idea how many asm instructions have to be exectued to run a Java app?
Havent counted them, but I know that modern JVM’s perform very advanced optimizations similar to those of a static C++ compilers.
> C# is on the order of 10x faster than Java,
Haha, show me the benchmarks.
> and it is still 5x slower than C++,
So Java is 50x slower than C++? Take a look at:
http://www.aceshardware.com/Spades/read.php?article_id=153
Now show me the benchmarks that says Java is 50x slower than C++.
> which is 5x slower than C (numbers are approx).
I would say your numbers are VERY approximative (even made up). 🙂
I agree. Java’s speed issues are mostly made out of plain old ignorance and bad programming skills.
Java’s lack of GUI speed is usually because “developer’s” have no idea how to use threads. If you write your Java app correctly, the GUI is as responsive as any other (even more so than the goofy GUI’s that plague Windows XP).
Having done many benchmarks in the past on every version of Java since 1.0, I can honestly state that Java was never the speed dog that some people like to purport. Currently, it runs at near native speeds, and outperforms compiled C++ code in several areas.
“As far as i recall correct me if im wrong isnt J# the java offensive product C# is nextgen of VC++ just wondering”
C# is a new language designed primarily to take advantage of the .Net architecture and give developers some of the strengths of C++ with rapid application development. It shares a few things in common with Java primarily because it shares the same base (C/C++) and brings in some of the same things from modern language research.
VC++ still exists, and they’ve added some things so that it can work for .Net as well.
J# is essentially the new version of Visual J++, targeted at the .Net architecture for developers that still want to use the Java language.
I have to disagree. Currently the C# syntax has been changed so that it doesn’t resemble Java as absolutely identically as it used to. However, C# is not nearly as related to C/C++ as it is to Java.
For example, this code would compile under C# before they made the syntax changes:
class HelloWorld
{
public static void main(String[] args)
{
System.out.println(“Hello World!”);
}
}
That is Java code.
Now, Microsoft has changed the syntax a little, so the same program looks like this now in C#:
class HelloWorld
{
public static void Main()
{
System.Console.WriteLine(“Hello World”) ;
}
}
Still, a lot closer to Java syntax than C/C++.
Syntax is not the only thing to keep in mind. CLI is microsoft’s version of Java’s bytecode, both languages have a VM, both languages have similar garbage collection mechanisms, etc.
The only differences between the two languages that I can find, that should be important to developers, is that Java has been around for years and is a mature technology. C# is not. Java allows developer’s to participate in its evolution via the community process. C# does not.
Having worked at Microsoft during the beginnings of C#, I can tell you all that it is a hijacking of the Java language. Microsoft tried to pull this off with J++ version 6.0 and lost a suit over it. This is just Java hijacking version 2.0.
In my opinion, amongst other things, C# is yet another technology lifted by Microsoft.
J# is, as I said before, supposed to be a path for current Java developers to enter the .NET arena. You can still make Java programs with it to run on the JVM, but they will be based on Microsoft’s antiquated JVM. Any Java developer that knows what they are doing probably won’t touch this product.
“The only differences between the two languages that I can find, that should be important to developers, is that Java has been around for years and is a mature technology. C# is not. Java allows developer’s to participate in its evolution via the community process. C# does not. ”
Explicit conversions in cases where data loss is possible, checked/unchecked evaluation to throw exceptions on overflow, versioning of classes, delegates and callbacks, property declarations inside the class, signed and unsigned data types (like C/C++), compilation to binary, preprocessor directives, operator overloading (excepting assignment operators). These seem like things that should be important to at least some developers.
Finally, at least some of the things that make it similar to Java are in part simply the difference between older languages and new (ie C++, though being an ANSI standard only since 1997, dates back to 1983). Class declaration in Java is much easier for people to deal with than the syntax in C++, the boolean data type wasn’t even part of C++ for most of it’s existance (hence VC++ 5/6 handle BOOL and bool differently, because MS added one before the other was part of the standard, and did so in a slightly different way), handling errors as exception objects, interfaces as an abstraction of collections of methods (which could be said to be somewhat based on COM), and the memory management, which is more a part of the .Net framework than the language, though the language is designed to allow the framework to handle it.
I think that, in the end, the most important thing will be to see how well MS can make .Net perform, and hopefully it’ll finally be a method through which the Win32API can be cleaned up, or maybe even replaced in the long run.
Here’s the real deal!
Yes, at one point in time, some Java benchmarks were written which showed that it could beat/match some C++ code. Times have changed. C++ compilers got better. More C++ programmers understand how and why to do things properly. Wow! With a *good* C++ compiler, and assuming the code is well written, it will always be faster than Java for any significant application. The other issue which usually comes into play is that when testing Java, most benchmarks do lots of application specific VM tuning, many of which is to avoid having GC during the benchmark. Often, the HUGE java start up time is ignored under the assumption that an application will run long enough for this overhead to be considered noise. Total BS. Oh ya, that’s fair. I don’t remember anyone taking dynamic lib load time and other misc. process start up time from C/C++ applications during benchmarks nor do I remember them profiling to remove the overhead associated with frees in the C/C++ applications. This is just plain silly.
So here it folks, like it or not, *generally* speaking and assuming sane code for each platform as well as assuming REAL work is being done, C and C++ are almost on par. differing only by a couple of percent depending on the task at hand. Java ranges from several percent slower to an ORDER OF MAGNITUDE slower than C/C++, depending heavily on the type of application in question.
Likewise, scripting languages such as Perl, Python and Ruby range from several percent to an ORDER OR MAGNITUDE slower than Java.
Now then, now that we’ve covered that, let’s address the REAL WORLD. Generally speaking, and backed up by several studies (please don’t ask for links…I read this a while a go) which show there are several other factors that directly effect real world results with differing languages. Surprise, Java is easier to learn than C++ and easier to debug than C/C++. Likewise, having an expert coder on a Java project is much more likely than it is to have an expert C++ coder. Why? Well it seems that C++ is an ORDER OF MAGNITUDE more complex to learn and understand the underlying design implications than is Java. So, what does this mean? It means that in the real world, you are more than likely going to have more effient code on a Java project that you will on a C++ project? Why? Because of two reasons. Firstly, it’s more probable you’ll have one or more expert Java coders than you will have a single expert C++ coder. Second, even if you have average coders on both sets of projects, since Java is easier to code for, it’s more likely the C++ coder will write poorly performing code when compared to what the Java coder will produce. Lastly, since C/C++ generally taking longer to debug that often provides more time for algorithm specific optimizations as well as general VM tuning with Java.
It pretty much boils down to, use the best tool for the job. Areas where each language excels:
Java:
General GUI, fat clients, distributed clients, peering applications, light weight servers or services, light weight web applications.
C/C++:
Large projects, heavy weight services or servers, distributed applications, peering applications, applications requiring a high degree of parallelism.
Python/Perl/Ruby:
General GUI, light client, peering applications, light weight servers or services, light weight web applications.
Notice that Java and the scripting languages have a lot of overlap? This is not to say that any of these languages can’t be used for other purposes, rather, it’s pointing out the areas where each tends to excel. Also, by no means is this an all inclusive list.
> Here’s the real deal!
According to the almighty Greg! 🙂
> Yes, at one point in time, some Java benchmarks were written which showed that it could beat/match some C++ code. Times have changed. C++ compilers got better.
I doubt C++ compilers have improved vastly over the last 2 years. Actually many companies still use MS VC++ 6.0 which is more than 2 years old. GCC has improved. JVM’s have improved lots in the last 2 years and continues to improve.
> More C++ programmers understand how and why to do things properly.
That might be true, but I would still say that 90% of those who use C++ don’t use it in a correct way.
> With a *good* C++ compiler, and assuming the code is well written, it will always be faster than Java for any significant application.
I dont agree with this. When generics will be added to Java (should happen in JDK 1.5) I dont think there is any reason for Java code to be slower than similar C++ code. Actually Java code has the potential to be faster for a number of reasons:
– It can optimize the code for the platform the user is currently running on. A C++ program is typically compiled once for a specific platform.
– It can more aggressively inline methods since it has runtime information about which methods that are called often.
– Garbage collection is faster than explicitly calling “delete”.
> The other issue which usually comes into play is that when testing Java, most benchmarks do lots of application specific VM tuning, many of which is to avoid having GC during the benchmark. Often, the HUGE java start up time is ignored under the assumption that an application will run long enough for this overhead to be considered noise. Total BS. Oh ya, that’s fair.
Start up time is a problem with Java. It is being addressed by Sun and hopefully soon we will have things like shared JVM for all Java processes. However, while start up time is important for client applications it’s not important for server side applications.
> Surprise, Java is easier to learn than C++ and easier to debug than C/C++. Likewise, having an expert coder on a Java project is much more likely than it is to have an expert C++ coder. Why? Well it seems that C++ is an ORDER OF MAGNITUDE more complex to learn and understand the underlying design implications than is Java.
Correct. I’ve used C++ for about 10 years and I still learn new things about the language almost every day I use it. I’ve used Java for about 3 years and I’m about 5 times as productive with it if I have good IDE.
> Java:
> General GUI, fat clients, distributed clients, peering applications, light weight servers or services, light weight web applications.
You got this one wrong. J2EE is used in almost all big web applications. Java dominates this market. I would say Java can be used as a replacement for C++ in almost all applications except mathematical and extremely performance critical applications.
I want to learn java. any advice? what are some good books? what IDE do you like? is it free? if not are there good free IDE’s for java?
thanx a bunch!
> That might be true, but I would still say that 90% of those who use C++ don’t use it in a correct way.
Which is totally irrelevant as to whether Java is faster than C++.
> I dont agree with this.
Your choice.
> When generics will be added to Java (should happen in JDK 1.5)
So if we’re talking here + now, then you accept C++ is faster?
> I dont think there is any reason for Java code to be slower than similar C++ code.
1] Bytecode
2] Runtime checking
3] Security Manager
4] Thread abstraction
5] Memory Access Restrictions
6] Dynamic loading
7] Method dispatch
8] Damn wrapper classes.
> Actually Java code has the potential to be faster for a number of reasons:
> – It can optimize the code for the platform the user is currently
> running on. A C++ program is typically compiled once for a specific
> platform.
I can optimise my C++ program for whatever plaform I want to run it on.
And I don’t have to do that at runtime.
C++ wins.
> – It can more aggressively inline methods since it has runtime
> information about which methods that are called often.
I guess the idea of a profiler is beyond some people.
> – Garbage collection is faster than explicitly calling “delete”.
In what way could that possibly be true?
How is leaving your objects floating around for a background task to reclaim them, call finalize methods on them, and then return the memory to the pool, going to be somehow faster than doing exactly that same thing without needing the background task?
If you want to learn Java have a look at the online tutorial:
http://java.sun.com/docs/books/tutorial/
There are a bunch of free Java IDE’s. Some of them:
Eclipse, http://www.eclipse.org, I recommend this one
JBuilder, http://www.borland.com/jbuilder/
NetBeans, http://www.netbeans.org
Hope this helps you. If you have any questions about Java, comp.lang.java.programmer is a good place to ask:
http://groups.google.com/groups?hl=en&group=comp.lang.java.programm…
>> That might be true, but I would still say that 90% of those who use C++ don’t use it in a correct way.
>
> Which is totally irrelevant as to whether Java is faster than C++.
Yes, I was just responding to the previous writer.
>> When generics will be added to Java (should happen in JDK 1.5)
>
> So if we’re talking here + now, then you accept C++ is faster?
Yes, in some cases it’s faster. I’ve never said anything else.
> > I dont think there is any reason for Java code to be slower than similar C++ code.
>
> 1] Bytecode
No. The bytecode is compiled to machine code.
> 2] Runtime checking
Can slow things down. The new JVM’s can optimize away array bounds checking.
> 3] Security Manager
How does this make Java slower?
> 4] Thread abstraction
???
> 5] Memory Access Restrictions
This doesnt necessarily slow things down, and it’s a BIG advantage not to have pointers running wild in memory.
> 6] Dynamic loading
Slows loading time, not execution time.
> 7] Method dispatch
Java method calls is similar to calling a virtual function in C++. In many cases the JVM can optimize the call to a direct call (or inline the call).
> 8] Damn wrapper classes.
Only slows things down if you use them (C++ dont have them). Java has primitive types just like C++.
>> Actually Java code has the potential to be faster for a number of reasons:
>>
>> – It can optimize the code for the platform the user is currently
>> running on. A C++ program is typically compiled once for a specific
>> platform.
>
> I can optimise my C++ program for whatever plaform I want to run it on.
> And I don’t have to do that at runtime.
> C++ wins.
Yes, but you cannot optimize your program for EVERY platform it’s users run. A Java program will take advantage of improvements in future CPU’s without you doing a damn thing.
>> – It can more aggressively inline methods since it has runtime
>> information about which methods that are called often.
>
> I guess the idea of a profiler is beyond some people.
Profilers are useful, but I think it’s more useful to have the JVM automatically find the functions that needs to be inlined.
>> – Garbage collection is faster than explicitly calling “delete”.
>
> In what way could that possibly be true?
> How is leaving your objects floating around for a background task to reclaim
> them, call finalize methods on them, and then return the memory to the pool,
> going to be somehow faster than doing exactly that same thing without needing
> the background task?
There are many research reports that states that garbage collected languages (like Java) have more effective heap management than languages that are not garbage collected (like C++).
“Explicit conversions in cases where data loss is possible, checked/unchecked evaluation to throw exceptions on overflow, versioning of classes, delegates and callbacks, property declarations inside the class, signed and unsigned data types (like C/ C++), compilation to binary, preprocessor directives, operator overloading (excepting assignment operators). These seem like things that should be important to at least some developers.”
Can’t you program without having these things? Java has other mechanisms to allow you to do the same things a different way. Also, things like checked/unchecked evaluation to throw exceptions on overflow is irrelevant in Java. In fact, Java protects programmers from a lot of the errors that C/C++ don’t and that equals less defects and a quicker time to market. So to answer your question, no, I don’t think these items are important.
I’m not saying that I don’t like C and C++. Both of them and Java make me a lot of money. I am saying that I see no value in learning C#. Sure, I could probably make money programming C#. I could also make money programming in VB, but I don’t want to because I hate the Basic language.
However, none of this changes the fact that C# was created solely because Microsoft’s attempts to hijack Java by doing things like adding the WFC to J++ 6.0 and adding proprietary stuff to the Windows JVM failed. If they had been successful in making Java better on Windows than other platforms, C# wouldn’t exist. I should know, I was there.
Finally, I think the main thing that should be important to programmers is their ability to sell to the largest market available. Programming is fun enough, but let’s be honest, the best part about it is the money. Why any programmer would want to embrace a technology that was specific to Windows and Windows only is entirely beyond me. Yes, I make Windows programs, but if I can also sell those same programs to Mac and Unix users, or make wireless versions of them for a variety of handhelds, then with hardly any extra effort at all, I’ve just increased my market pool. More that signed/unsigned variable types, that is what’s important to me.
>> 1] Bytecode
> No. The bytecode is compiled to machine code.
With a JIT yes, *but* it is done at runtime.
Depending on your application that can be a significant overhead.
As is starting up the JVM.
>> 3] Security Manager
> How does this make Java slower?
Every attempt to perform operations that are “secured” is slower.
eg, File access has to go though the OS’s security code, and then through the JVM code. More work == slower.
It’s a reasonable price to pay, but you take a performance hit.
>> 4] Thread abstraction
>???
On platforms with native threads, it is going to be faster to use the platform specific thread primitives than the java abstraction.
The Java threading model is a fairly simplified model.
eg Linux has a much more complicated model for threading.
Using the native API for threads gives more control + more speed, at the possible loss of simplicity.
>> 5] Memory Access Restrictions
> This doesnt necessarily slow things down,
Usually.
It’s much faster to play wildly with memory than to have checked access.
> and it’s a BIG advantage not to have pointers running wild in memory.
But it’s a performance hit. There’s no such thing as a free lunch.
You get what you pay for.
>> 7] Method dispatch
> Java method calls is similar to calling a virtual function in C++.
Similar, but not the same.
It’s a bit slower, and all methods are virtual.
> In many cases the JVM can optimize the call to a direct call
> (or inline the call).
Both of which the programmer can do in C++, and can probably do a better
job of, if they profile their program correctly.
100% developer time saves about 5% execution time.
A bad trade off, but that’s not the point here.
>> 8] Damn wrapper classes.
> Only slows things down if you use them
Yeah, but you have to use them way too often.
Maybe (but I doubt it) generics will solve this.
> There are many research reports that states that garbage
> collected languages (like Java) have more effective heap
> management than languages that are not garbage collected
> (like C++).
I fail to understand how/why that could be the case, but
I haven’t read the research.