.NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO

  • Thread starter Thread starter consumer62000
  • Start date Start date
And for the record, the country was pretty closely split between reds
and blues. So either way you look at it, roughly half the country
disagreed with you. Half certainly disagreed with me. Does that make
them right?
 
Please do not even compare .NET to any other product. It is the best product
so far, compared to Java. Java garbage collection and response times are even
worse. .NET is much better in every aspect. People are just accepting Java
because they have jealousy for Microsoft; I don't even see a valid reason.

Innovation of .NET has addressed several problems that Java has brought in.

Regards.
 
Hi guys and girls,

I really enjoy this conversation. I think it would have been better to post
your code and let someone help. I sincerely believe it's a programming error,
if not prove me wrong, please. Btw i am not a coder, just a newbie.

Great guys keep, up the good work.
 
Satya said:
Please do not even compare .NET to any other product. It is the best product
so far, compared to Java. Java garbage collection and response times are even
worse. .NET is much better in every aspect. People are just accepting Java
because they have jealousy for Microsoft; I don't even see a valid reason.
Click to expand...

Everything I've seen indicates that performance for most things that a
server would be interested in are roughly the same for Java and .NET.
GUI performance has historically been poor in Java, but that has
improved over time (and different toolkits are available).

I would argue that Java also has more choice in development
environments - and that currently, Eclipse is *way* ahead of Visual
Studio .NET. Of course, VS 2005 will improve things on the .NET side,
but frankly from what I've seen it still hasn't reached the level of
Eclipse 3.1. When I'm developing in Java, I develop much faster, even
though the language occasionally constrains me (in terms of lack of
events and properties). Then again, in C# I miss the Java-style
enums...
Innovation of .NET has addressed several problems that Java has brought in.
Click to expand...

I suspect that both .NET and Java are better for the mutual
competition. Each has advantages and disadvantages.
 
Where did you go?

I didn't see any sample code to perform some testing! It's hard to answer a
question like this without a sample.
 
Hi,

I am a software engineer in .net since 3 years

I am huge supporter of each and every tech. developed from microsoft


But ...

Mr Tim Wilson , you must accept that your this .net fantacy is not mean for
real time software . no matter how less time the GC takes

Beacuse for realtime applicatons the most bigges reqirement is that its main
thread must not be paused at any cause , but this is the frequent case in
any application developed using .net framework

U should accept that Microsoft is not really concetrating to produce a
really good programming platform.

they are just doing like

"Handing over a toy to a crying child"

Thats why , even after the advent of .net (5 yeast elapsed) they could not
beat the Java in market.

Event i am strongly attached with Microsoft and its technologies


Do reply me what do you think about this at


(e-mail address removed) ,
(e-mail address removed)

Prem Kumar
Associate software Engineer
Larsen & Toubro Infotech Limited
Navi Mumbai
Vashi
India
 
While the original post indicates a lack of maturity it does suggest that
there are developers who expect to be able to use .NET in ways that were not
anticipated, e.g., real time systems. Java, a language comparable to C#, has
extensions for developing real time applications. Rather than dismiss this
developers frustrations it might be better to determine if there is a way to
enhance future versions of C#.

Please see: http://java.sun.com/products/embeddedjava/real-time.html
 
Ahem,

I have not had any issues with .NET when writing applications in C#. .Net
2.0 beta performance has been an issue from time to time for me, but hey,
it's in Beta and I expect the final release to be good.

The person who started this thread really needs to re-evaluate what they are
saying and look at the code they are trying to produce before ranting on
about Microsoft sucking.

Paul
 
Tim did say that architects and developers should consider what
languages/platforms are best for their needs. He did state that .NET isn't
really for real-time applications.

Performance can be better by following certain guidelines. If you leave all
your memory to be collected by the GC you will suffer performance penalties
at some point. If you free your memory - perhaps by following the disposable
pattern for managed memory as well as native handles - you can
deterministically free memory so that the GC doesn't lock the threads while
collecting later.

Rico Mariani's blog at http://blogs.msdn.com/ricom/default.aspx is a good
place to read about performance, not just for managed code but native as
well. So is Raymond Chen's blog at
http://blogs.msdn.com/oldnewthing/default.aspx.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft
 
Heath Stewart said:
Performance can be better by following certain guidelines. If you leave all
your memory to be collected by the GC you will suffer performance penalties
at some point. If you free your memory - perhaps by following the disposable
pattern for managed memory as well as native handles - you can
deterministically free memory so that the GC doesn't lock the threads while
collecting later.
Click to expand...

Um, how exactly do you propose to use the Disposable pattern to free
memory? Calling Dispose doesn't free memory, it just allows an object
to clean itself up.

As far as I know there's no way of explicitly freeing memory in .NET -
at least not in C#.
 
When this topic-thread started, I thougt it is not going to be too
lenghty; programmers are mature enough.
But...
it still appearing on top counters... in
microsoft.public.dotnet.framework news group.
 
Um, how exactly do you propose to use the Disposable pattern to free
memory? Calling Dispose doesn't free memory, it just allows an object
to clean itself up.

As far as I know there's no way of explicitly freeing memory in .NET -
at least not in C#.
Click to expand...
there are 2 ways....

- with using() there are probably some low-level optimisation going on but
it appears the object (and some other?!!) are freed straight away

- with GC.Collect() ;-)
 
True, it's not that you implement IDisposable and everything is taken care
of, but it's what you do in your Dispose method such as freeing native
handles or disposing of other objects that may free any memory they're using.
It just depends on how you're allocating memory, what you're instantiating
(and how that allocates memory), etc.

What's also require is that callers dispose your disposable objects. It all
just depends on what needs to be disposed. Supressing finalization also helps
performance, which implementations are support to do in the
IDiposable.Dispose implementation.

Will that make code suitable for a critical, real-time app? Perhaps not, but
it does help performance.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft
 
All using does is wrap the code block in a try-finally, with a call to
IDisposable.Dispose in the finally block. That is why a compiler error occurs
if you do not pass a disposable object to the using() statement.

Using ildasm.exe from the .NET Framework SDK or another disassembler or
decompiler like .NET Reflector is a good way to explore how your source code
compiles into MSIL.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft
 
Heath Stewart said:
True, it's not that you implement IDisposable and everything is taken care
of, but it's what you do in your Dispose method such as freeing native
handles or disposing of other objects that may free any memory they're using.
It just depends on how you're allocating memory, what you're instantiating
(and how that allocates memory), etc.
Click to expand...

But any "pure .NET" types won't be able to free their own memory. At
best, they'll be able to null out a few members, which in a few very
rare cases will help, but not often.
What's also require is that callers dispose your disposable objects. It all
just depends on what needs to be disposed. Supressing finalization also helps
performance, which implementations are support to do in the
IDiposable.Dispose implementation.
Click to expand...

You only need to suppress finalization if you have a finalizer, of
course - very, very few types should have finalizers IMO.
Will that make code suitable for a critical, real-time app? Perhaps not, but
it does help performance.
Click to expand...

Making your types implement IDisposable where they don't need to won't
help though, and that seems to be what you're suggesting. You *cannot*
deterministically free managed memory in .NET.
 
Defend it, no, but I'm not sure anyone billed .Net as a realtime
system. If I had those requirements, I'd not use the VM, I'd break out
to native code. Have it handle the communication between the outside
world and your .net app.

To me the real issue around GC is that in heavy load situations is that
it bogs down to the point of bringing the system to a crawl. .Net 2005
may easy this some, I haven't had a chance to test it there.

But from what I've seen the current 2003 version's generational GC
system just doesn't cut it in high memory load situations. The ADO
libraries seem to call GC way to frequently as well which adds to the
problem. I'm sure the eager collection of ADO was in response to its
own memory issues.

Hopefully 2005 may have some of these addressed.
 
Lloyd said:
- with GC.Collect() ;-)
Click to expand...

I know you put a wink there, but GC.Collect should be used with care.
Realize that collecting all generations in an app that has memory paged
out can cause real performance issues.

In my experience adding generations to garbage collection only
marginally improves the performance in an app that is experiencing
memory pressure. Ofcourse a lot depends on the usage pattern of the objects.

It would be really nice if the VM developers would realize they're not
omnipotent and allow the application developer some control.

I'd really like to be able to create an object or objects outside of the
GC system that I want control explicity. They may be large objects or a
web of large number of objects that have a shared, well defined life
time. Rather than having to jump to C++ it would be nice if I could just
declare them excluded.
 
[email protected] said:
Let me tell you a scenario and you will see what I mean.
There is a large application that has communication with a real time
system . The app has to respond to the requests in no more than 1 s.
The app is a C# .NET app and everything is fine and everyone at
Microsoft is happy that they forced their "new" platform down someone's
throat.

Now imagine a scenario where the GC has to collect the memory. Well,
when GC runs all the threads are suspended and there is no response to
the incoming requests and application fails a critical requirement.

Well,any MS people here who can defend their sucky product,
I know they will say "don't use .NET for this or that...use C or C++
etc"
My q to them is why did you create .NET then?
Click to expand...
 
Don't get me wrong here - but i tend to think that I have a balanced view
with regards to companies/technologies. I use PCs, Macs and Unix machines. I
have to say that I think that each of these platforms has its strenghts and
weaknesses. It is the same with programming platforms. People feel that Java
rocks, and I think it does when it comes to web development, but it
absolutely sucks when it comes to building rich client windows applications.
On the other hand .NET is becoming better and better at web app development
and definately rocks in developing windows apps. Lets face it Microsoft never
claimed that .NET and C# can be used for writing real time critical apps,
using C#. Who would do that? Microsoft hasn't forced anyone to use .NET, and
certainly hasn't forced it down our throats!. You could say they have done
that if they had stopped support for C++ but they haven't. They offer both
managed and unmanaged code development for C++. The thing that really upsets
me is people moaning about how crap Microsoft is and how good Java and Unix
are. If they are so good - USE THEM, and leave the rest of us in the
Windows/.NET world alone.

Keep up the good work @ Redmond guys,

Thank you

Joseph Megkousoglou
Software Engineer
 
I totally agree, but for one point: MS is phasing out COM based Visual Basic
(6.0)... I know that's a totally different story, but... ;-)
 
Back
Top