|
|
|
It adds a lot of cruft. Complicates server deployment.
Or at least: that is how it feels.
... such stuff as dreams are made on
|
|
|
|
|
More complicated. But can be automated...
You may be interested in my article about .NET Core (the second one)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I was thinking in terms of updating .NET itself, when there are dependencies between all the applications and the core. Maybe you cover that too, but I saw no link
Köszi 
... such stuff as dreams are made on
|
|
|
|
|
It does not cover .NET Core updates, as I do not consider it as a developer problem.
It is about hosting the very same compilation on different platforms... ASP.NET Core: compile once, host everywhere[^]
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It is about hosting the very same compilation on different platforms
Errr....as with java the actual idiom would be 'code once' and then 'test everywhere'.
|
|
|
|
|
I have been doing server development for at least 20 years. Implementing Rest layers (and before that Soap, http and TCP) on down to the database. And designed all it as well.
Exactly what sort of servers are you writing where the architecture and requirements themselves are not the principal source of the complexity?
There was only one time where language choice was objectively justified and that was based on business/marketing/finance requirements rather than any technological need.
|
|
|
|
|
3. Does not write .NET apps but uses [insert your favorite language] for cross platform applications
For me, it is C++ with cross platform frameworks like Qt and C, C++, and Perl for console applications.
|
|
|
|
|
It is actually 2. - you consider your current cross platform solution better (or good enough)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I think it would be a good choice if I would write .NET apps (and have not used many methods that are not supported by .NET core).
|
|
|
|
|
No requirement, a purely windows shop so "everywhere" is .Net 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I like .NET and I'm excited about .NET Core although I haven't used it for a production app as yet.
Having said that, up until recently there was a lot of stuff missing. Given than Java is more mature and has better performance, there's always the question in the back of my mind "why don't I just do this in Java?".. and that's the first hurdle Microsoft is going to have with developers when it comes to cross platform web development.
Personally I'll stick with it, but I'll probably need to learn Java as well just to hedge my bets on where future opportunities are going to be.
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: Given than Java is more mature and has better performance
I dispute both of those assertions. And I have close to 20 years of experience with java going back to 1.1.4 (not 1.4). And 8 years of C#. Plus C/C++ before that.
And been doing server side development exclusively for 20+ years.
Neither language is significantly better than the other. Last time I used C# the IDE was significantly better than those available for Java, but at least for me that wasn't a significant factor.
In terms of "performance" all that matters is that which impacts the business - which is where the money comes from. And from that aspect requirements and design are the things that have the most impact, orders of magnitude more, than technological choices.
Additionally any language that does in fact have a "performance" advantage must be filtered through the chaos that any large scale enterprise creates via its own processes, multiple refactors and legacy support, multiple employees (and skill) and costs associated with that. Thus even if it was measurable initially over time it would not rise above the noise level when measuring (not guessing) about actual business performance.
|
|
|
|
|
I probably should have written it clearer - Java is more mature than .NET Core. I don't think that can be disputed?
Performance wise, every ASP.NET application I've seen takes a long time (> 20s) to return a response when cold. On Java applications, the response is instant. Up until lately, .NET has had the drawback of only running on Windows Servers which (probably thanks to the heavy desktop components, general Windows baggage and IIS) runs slower on the same hardware before we've even started talking about making requests. .NET Core running on Kestrel on Linux should (theoretically) be an improvement on all that but the jury's still out as it's a new, immature and generally untested technology.
I'm a dyed-in-the-wool C#/.NET developer but as far as developing cross-platform web applications Java has been the go-to technology. Until .NET Core can prove itself (and that's going to take years), Java will remain at the top.
jschell wrote: In terms of "performance" all that matters is that which impacts the business
True enough, but a lot of businesses are moving to the cloud (Azure or AWS) where every CPU tick, every scrap of RAM or storage costs money.. performance is going to be a big factor for more and more companies over the next few years (and it already is for many).
Now is it bad enough that you let somebody else kick your butts without you trying to do it to each other? Now if we're all talking about the same man, and I think we are... it appears he's got a rather growing collection of our bikes.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: I probably should have written it clearer - Java is more mature than .NET Core. I don't think that can be disputed?
Yes and no in terms of the rest of your response.
First one must differentiate between the languages of Java and C# and the eco system in which those languages might be used, such as IIS and tomcat.
In terms of that I think that Java has an edge. However I wouldn't use what I think of as an edge to make my sole stack determination.
Brent Jenkins wrote: Performance wise, every ASP.NET application I've seen takes a long time (> 20s) to return a response when cold
I did credit gateway card processing on C#. It was necessary to performance test the server and what I found that the server had zero impact compared the actual measured time that the card processors themselves had on the system.
So at least in that business any delay was no more than noise to something over which I had no control anyways. Same would have been true with Java.
Brent Jenkins wrote: every scrap of RAM or storage costs money.. performance is going to be a big factor for more and more companies over the next few years (and it already is for many).
So far everything I have seen or read suggests that it often, now, comes down to one specific metric which can often be surprising. Even more so now that cloud services are attempting to divide up the entire processing stack so they can charge for each individual piece.
I recall reading a story about one business that went from tens of dollars a month to thousands because AWS (I believe) fixed a bug on the AWS side which meant they could now accurately track some metric that they had added billing for.
|
|
|
|
|
Well, there's 2 issues at play here.
First, Java already does that, so most people that had a vested interest in cross-platform applications are most likely already following that route.
Secondly, MS hasn't helped the situation by failing to wrap the .NET world under a coherent umbrella. They just tack a new word onto it, pass it to a team, and let them do whatever they feel like. The division between .NET Standard and .NET Framework is a great example of this: there is no reason whatsoever that all modern .NET isn't .NET Standard, except different teams have their fingers in the pie.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
True .NET is late to the party, but all latest (and alive) .NET versions implements .NET Standard 2.0 (the latest too)... so there is an improvement there...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It seems only about 15% of us consider .NET Core as platform for development
Who is "us"?
Tiobe index only places C# at 5% and Java is only 12%. However given the spike in the numbers this year I expect that there is a data collection problem (which happened years ago also.)
TIOBE Index | TIOBE - The Software Quality Company[^]
Kornfeld Eliyahu Peter wrote: 2. Or does not consider .NET Core as a good choice for that
I expect some of that it true.
However, in my experience, people rationalize (not objectively) technology choices based either on what has succeeded for themselves individually in the past or failed for themselves.
So, for example, that is why many people jumped on the NoSQL bandwagon because they do not know how to use a relational database correctly.
|
|
|
|
|
Us === CPians
The post related to the current weekly poll...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: The post related to the current weekly poll...
I see.
|
|
|
|
|
jschell wrote: So, for example, that is why many people jumped on the NoSQL bandwagon because they do not know how to use a relational database correctly.
So, while I largely agree with your point about how individual performance with tech may vary, I think you're falling victim to the same hypothesis in regards to NoSQL. The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
I doubt that in general.
First many smaller (data) apps can get by just fine with a less than optimal relational database. And the same applies to a NoSQL database.
However when one runs into an unusual problem with the relational database, then one is likely to attempt to solve it in the database, and without the skill, that is problematic. NoSQL, for most, means the solution must be external to the database so it seems 'better' to those without the SQL skill.
Note as well that at least anecdotally I have the experience to back this up as I know individuals who do not like relationals because of the skill level required (they specifically say that) so they choose NoSQL.
Other than that I can also hypothesize that object models map directly to NoSQL whereas one must consider more carefully how to do such a mapping with relationals. With skill the relational mapping is easy but without out it, a failure to map can lead to problems that would not necessarily show up with NoSQL.
And because those without the skill might have encountered the various problems, due to lack of skill, and problems that cannot exist with NoSQL they think it is better. Doesn't mean that the incorrect implementation that lead to the problem in the first place was not needed to solve some other problem, but they neglect to properly take into account the need to solve the original problem.
|
|
|
|
|
I'm sorry, that's simply not factual. Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly. Data structure design is just as important, and not even handled all that differently. It just doesn't have a safety net that SQL does; it will not immediately fail when a relationship mapping is not performed correctly.
As the most basic example would include an object property that references a specific entity. Unless you map that relationship properly you will end up with a copy of that entity stored in the data model, in the state that it was in when serialized, rather than a reference to an entity in another collection, which is what you want as that will be the master source for state on that entity.
Yes, it will appear to work, but you have a giant bug that might not be detectable until the system encounters a concurrency error between the real state of the object and the state tracked by the copy attached to the entity that you're working with. If you don't understand the data relations, you will never find the bug in this system.
That's what I meant in the section of text you quoted. Appearance of functionality is not success; actual functionality is success.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
