Fog Creek Software
Discussion Board




The rise of .NET

Microsoft's marketing seems to be working.  We will be supporting an ASP.NET server.  As a Linux server user, I am honestly up in the air about it.  I have to admit that it looks a lot better than the old ASP.  Although, the thought of supporting production Microsoft servers doesn't appeal to me. 

So are there any other Linux/Unix developers that have drank the kool-aide and gone over to .NET? 

Right now I can't tell if the momentum is more in Microsoft's favor or Linux's on the server.  I am guessing it is about 50/50.  I think .NET is pulling more people toward Microsoft.  The fact that Sun hasn't been able to get Java right hasn't helped. 

Where do you all think the server market stands?  Is it going towards Microsoft or Linux?  I'm for Linux myself, but I can understand why so many are going with .NET.

christopher baus (www.baus.net)
Wednesday, June 02, 2004

"Although, the thought of supporting production Microsoft servers doesn't appeal to me."

This is the sticking point for me.  However, it looks like Novell is trying very hard to make Mono handle everything in ASP.NET so you can deploy it on Linux/Unix.

Almost Anonymous
Wednesday, June 02, 2004

How has sun not been able to get java right?

blah
Wednesday, June 02, 2004

> How has sun not been able to get java right?

Here's one example:

Intergration of native extensions or components could have been made a lot smoother.  For instance in python:

python install.py

done.

christopher baus (www.baus.net)
Wednesday, June 02, 2004

Ease of use.  There is no Java equivalent to ASP.NET.

To get the equivalent functionality, you have to learn 10 billion different buzzwords and frameworks before you can get any work done.

I speak from experience.

Richard P
Wednesday, June 02, 2004

What realistically what is the status of Mono?  Half of me wants to get on the bandwagon, and the other half thinks Mircrosoft  is all for it is as a ploy by to convert Linux users to Microsoft servers.  I think it might work. 

The other thing is whole concept of boxing and ref and value types gets me ill enough that I want to run far away.

christopher baus (www.baus.net)
Wednesday, June 02, 2004

What proportion of users have the .NET runtime installed on their machine? Is there any reliable data on this?

Warren Henning
Wednesday, June 02, 2004

I am a long time Java guy who tried .NET and liked it.  But I still do most of my work in Java because that's what my employer pays me very well to do.  I like working with both: I am a managed code bigot.

.NET still really means Windows.  I am little skeptical about Mono being anything you can take seriously, for the enterprise, but it would be nice if I was wrong.  I think .NET for the most part has been "Java" for the Windows people.

Bill Rushmore
Wednesday, June 02, 2004

The desktop isn't the issue.  I'm 100% Microsoft on desktop.  On the server I am a Linux fan.  I keep all my configs in source control, and can update servers remotely without a problem (ie apt-get update).  On windows it has always been a nightmare to remotely admin, and to rebuild servers.  It is always patch, reboot, hope it comes back.  I've even tried ghost and failed.    To me *nix is the logical server choice, but the pressures to use .NET seem to be everywhere.  My guess is the development is easier and the administration is more difficult.  But I'm not sure.  I am willing to try a pilot project to see how it goes I guess. 

christopher baus (www.baus.net)
Wednesday, June 02, 2004

J2EE still has the advantage of having a huge open source following.  A tiny ISV or even a one man shop can download an enterprise viable platform for free, and upgrade pieces later as he makes more money.  With .NET, you need server 2003, MS SQL...in other words, vendor lock in.  I like ASP.NET, I think the web forms are 10x better then anything J2EE has.  I just don't think its worth it though.

vince
Wednesday, June 02, 2004

For an ASP shop it is an absolute no-brainer to move to ASP.NET -- it is a massive productivity, and performance, boost. Outside of that, though, it isn't as easy of a win, and my observations of the field are that J2EE is definitely remaining the dominant player, and there remains a perception that J2EE is for serious "enterprise" development, while .NET is for small shops and toy sites.

Dennis Forbes
Wednesday, June 02, 2004

I drank the Kool Aid.

But I was just a LAMP (PHP/MySQL) hack, not a real programmer, so take my opinions with a grain of NaCl.  For me, it was more of a move to something bigger, with more options, and an education in OO (besides PHP's classes) than a straight switch.

What I love: the .NET class library and Visual Studio.NET.

What is hype: The ASP.NET model hides a lot of the facts of life from a web developer.  This is great from a development perspective, but can produce a few unexpected results.

As for server administration, it sounds like the strategy you've implemented for *nix will be hard to match with Windows servers, but all is not lost.  You can automate and script a lot more in Windows than the average admin takes advantage of.

As for mono, I'm getting ready to try it out as soon as I have a break in current workload.  I have high hopes for it as the feedback from the beta releases has been good.  I met with a Novell Sales engineer last fall who basically said that they *have* to make mono work.  They're pitching it as part of their web application server that is supposed to run your existing .NET code with no modifications.  Its availabiltiy is to coincide with the release of NW7.

offMyMeds
Wednesday, June 02, 2004

"With .NET, you need server 2003, MS SQL"

ISV's can save some cash by using the Web Edition of Windows Server 2003 for ASP.NET applications which is much cheaper, and MSDE instead of MS SQL Server, which is free, and by the time you need to upgrade to the full version of SQL server you should (hopefully) be able to afford it. Just some options...

Ben R
Wednesday, June 02, 2004

"there remains a perception that J2EE is for serious "enterprise" development, while .NET is for small shops and toy sites."

Which vertical market? I'm curious, because I haven't heard that in a while, even from Java shops. These days, the Java advocates seem to be relying mostly on the "proprietary/lock-in/single platform" argument rather than the "not ready for prime-time" argument.

That's my experience, anyway.
Philo

Philo
Thursday, June 03, 2004

BTW, I appologize for my poor editing in the past week or so. I've been swamped with a project for the past couple weeks, and I just post here when I have a minute or two.  The grammar in my posts shows how much my brain is fried. 

christopher baus (www.baus.net)
Thursday, June 03, 2004

So Philo, does .NET run on big iron?

i like i
Thursday, June 03, 2004

I'm a J2EE programmer. My take is:

1. Currently there is no shortage of J2EE work -- in fact, I can no longer even refer jobs to my friends, because everyone I know is working. I see plenty of C# work as well; perhaps it is mainly gaining at the expense of VB and C++?

2. Many of the Java people I've worked with, including myself, like C# well enough. After all, it's just like Java, and has the benefit of being launched later and so both adds some nice features and avoids some of Java's early-on baggage.

Lots of the tools that I use on a regular basis -- Ant, log4j, JUnit, etc -- have already been ported to C#.

3. The enterprise shops I've worked for like J2EE partly because of what Philo said, "avoiding vendor lock-in", but more importantly because of huge amounts of legacy applications. J2EE was made to integrate these things; .NET was made for the write-just-one-check folks.

As for Windows and Linux, I am seeing plenty of both, and hardly anything else.

Portabella
Thursday, June 03, 2004

I will soon need to administer a Windows Server 2003 machine, including IIS and MSDE. Looking around, I see far too many books about this subject. Can anyone recommend one or two books that do a good job explaining the entire administration lifecycle (installation, patch management, a bit on IIS, a bit on DNS, etc.)?

Oren
Thursday, June 03, 2004


Here's the thing that gets me about .Net....

If it's not in the core of it, then there's no way that you're going to be able to find reasonably prices extensions to do most of what you want.

In the Java world, if I want to do anything...  I hop over to Google and I can find a project or five doing exactly that, usually with simple documentation.

The community around Java is built entirely upon collaboration and therefore, it happens and things gain wider acceptance.  Since .Net isn't (doesn't seem to be) built this model, there still seems to be a constant push to re-invent *everything*.

KC
Thursday, June 03, 2004

Some would disagree on the collaboration thing, cfr. Ted Neward's recent postings on the Java community http://www.neward.net/ted/weblog/index.jsp?date=20040531#1085987861984

http://www.neward.net/ted/weblog/index.jsp?date=20040531#1086041098562

http://www.neward.net/ted/weblog/index.jsp?date=20040601#1086142692515

but you are right in the sense that Java does have a few years on .NET .

Just me (Sir to you)
Thursday, June 03, 2004

Aren't PHP and ColdFusion the competitors to ASP, not Java? Or has ASP.NET taken it into a whole new territory

Mr Jack
Thursday, June 03, 2004

Just me (Sir to you),


The articles you mention seem to focus on unity and competition.  I specifically noted that I would be able to find "a project or five".  I like the fact that there are semi-warring factions with different implementations of things within the "Java community".  It allows for trade-offs and some flexibility.

KC
Thursday, June 03, 2004

"Semi-warring fractions" doesn't exactly sound like "Java is built entirely upon collaboration " and why is finding "a project or five" "allowing for trade-offs and some flexibility" in the Java world but "a constant push to re-invent *everything*" if it's .NET ?

Don't get me wrong. Java has had a remarkable community for a proprietary product. .NET's community is growing in leaps and bounds. Maybe 5 years from now, they will also have turned into nasty groups of semi warring fractions.

Just me (Sir to you)
Thursday, June 03, 2004

> Intergration of native extensions or components could have been made a lot smoother.

Maybe so. It's clear that JavaSoft really discourages these, and so the support for them is lackluster.

> Ease of use.  There is no Java equivalent to ASP.NET.

True.  However, the J2EE community is keenly aware of this. If you read The Server Side (a popular J2EE discussion board), for example, you'll hear much discussion about this very issue.

You can also do a totally free J2EE stack (you only pay for the hardware), and this is free in both senses of the word.  Yes, this is only a small part of the total cost of a project, but it definitely helps with small projects and bootstrapping big ones.

Portabella
Thursday, June 03, 2004

I'm not so sure that J2EE avoids the vendor lock-in issue 100%.  Consider a cluster of IBM WebSphere servers running some decently complex sites/applications...now try converting that to a cluster of BEA WebLogic servers.  Sure, it can be done, but there *is* a cost to it, and it's not always trivial.  Even if your apps port without a hitch (ha!), you still need to retrain your staff...

I'm not saying that that's Sun's fault, or Java's fault, just that it's a reality.  Honestly, I don't care that much about being tied to a given platform.  I mean, once a system is up and running, what's the likelihood that you're going to switch vendors within, say, 5 years?

Joe
Thursday, June 03, 2004

"With .NET, you need server 2003, MS SQL"

False, and false.  ASP.Net can be hosted by IIS version 5.0 and higher, and I've written apps that talk to Access, MSSQL, and Oracle.

Greg Hurlman
Thursday, June 03, 2004

"Consider a cluster of IBM WebSphere servers running some decently complex sites/applications...now try converting that to a cluster of BEA WebLogic servers.  Sure, it can be done, but there *is* a cost to it, and it's not always trivial."

Most of the porting difficulty with J2EE is caused by developers who:

- use vendor-specific extensions without wrapping those calls behind more generic interfaces

- don't directly use vendor-specific extensions, but still base their code upon assumptions of underlying behavior that happen to be observed in the vendor-specific product but aren't guaranteed by the J2EE spec

- overuse EJBs, causing them to have to rewrite a truckload of deployment descriptors

NoName
Thursday, June 03, 2004

On the Java community...

I bought into Jakarta straight away.  I used, and --gasp-- still used jserv in production.  I had a lot of respect for the Apache foundation based on my experiences with apache.  The release were very organized and the product stable.  Jakarta, at least in the early days, was a complete mess.  I even went to some of the meetings, where I realized that most involved had no idea what it meant to support production users.  The APIs changed. There were no stable builds, etc.  It was totally build and hope something didn't break. 

A lot has changed over the years, and things have gotten much better (tomcat is hugely better than 4 years ago), but I still find the java community around Jakarta still lacks the organization of my favorite Open Source projects including Apache httpd, Linux, and now Subversion. 

At the time there really wasn't anything better for writing web apps than Java, and I learned to live with the problems, but now I'm not so sure. 

I don't think .NET is a bad technology (hell it is basically a knock off of Java which I like), I just don't like the tie into the Microsoft platform, which I think is a third rate production server environment.

christopher baus (www.baus.net)
Thursday, June 03, 2004

> I'm not so sure that J2EE avoids the vendor lock-in issue 100%.

Yea but I can develop on windows and deploy on Linux using the same servlet container with out problems.  I do this all the time. 

christopher baus (www.baus.net)
Thursday, June 03, 2004

With J2EE, changing operating systems is usually trivial.  Where I work we also develop on Windows and deploy on Unix.

But that is only easy when using an app server from the same vendor, e.g. moving from Weblogic on Windows to Weblogic on Unix.  Moving from JBoss to Weblogic to Websphere presents problems if the developers aren't disciplined enough to keep portability issues in mind and consciously avoid vendor-specific tie-ins.

T. Norman
Thursday, June 03, 2004

What do you want to spend your time doing?  Double checking everything against the J2EE spec (and 2 or 3 different app servers) and abstracting away every vendor feature and bug-induced work-around, *just in case* you have to switch at some indeterminate point in time down the road, or getting your project done? :)

I agree that switching the OS while keeping the same brand app server is easy enough, but there you're relying on your vendor to provide the platform independence for you.  Nothing guarantees that IBM won't stop supporting some *nix variant you happen to be using...

Joe
Thursday, June 03, 2004

> I am a long time Java guy who tried .NET and liked it.  But
> I still do most of my work in Java because that's what my
> employer pays me very well to do.  I like working with
> both: I am a managed code bigot.

Same story here. I've been doing J2EE for the last 3 years and 1 month ago I started with .NET (due to client requirements).

From my perspective I can tell that .NET is rising, more clients are requesting .NET based projects. In this part of the world (Europe), J2EE has got a bad reputation lately for being overhyped, overcomplex and expensive and .NET is gaining ground in this scenario.

DotNet newbie
Friday, June 04, 2004

"Double checking everything against the J2EE spec (and 2 or 3 different app servers) and abstracting away every vendor feature and bug-induced work-around, *just in case* you have to switch at some indeterminate point in time down the road, or getting your project done? :)"

Choosing to develop to the J2EE spec really isn't harder, it just takes a little discipline.  You have to develop to *somebody's* spec, whether it is J2EE or the vendor's flavor.  So just develop to the J2EE spec, and don't let yourself be enticed by vendor-specific bait.  Deal with the vendor's bugs when they happen.

I never said one should aim for seamless portability across different vendors.  Just make the porting simple when it has to be done by minimizing the vendor-specific tie-ins and wrapping them when they have to be used.

T. Norman
Friday, June 04, 2004

*  Recent Topics

*  Fog Creek Home