A company I was working at was using a java library to do one specific thing related to file uploads, despite all their code being .NET. The library became a bit of a black box and no one bothered to keep up with updating it as it was essentially a binary blob that sit outside the normal update mechanisms (visual studio references)
Turns out the library had patched a RCE vulnerability a while back, spent a fun afternoon making a PoC exploit for it (tricky because we had some other file validation in place) to win the unofficial office competition to find a security hole in our product.
I would agree with your point in general, but the moral of the story is that adding complexity is not good considering most people are too lazy/incompetent to understand the full implication of something like "I'll just use a third party binary / library here" to their ongoing maintenance.
Not sure what makes you think Oracle's JVM is slower than the CLR, in any case...
Lucene, Guava, Apache Commons, Redis driver, Postgres driver, Cassandra driver, Kafka driver, gRPC, Http2 support(on all platforms, not just windows 10)
Notice I said "equivalent". C# ports exist for some of these but they're unofficial, unmaintained, or both. The most heinous thing I've seen MS do recently is only support Http2 on newer versions of Windows. Http2 is a high level protocol and there's absolutely no reason for this. In Java you can use Http2 on any platform using Jetty, Netty, or soon built into Java 9.
I am not properly familiar with Guava, but aren't most things available in .NET's collections classes?
A lot of what's in Commons is available in the .NET BCL.
https://redis.io/clients#c looks fine to me (I'd probably pick the StackExchange client)
NPgSQL seems to be the recommended library for Postgres.
https://www.nuget.org/packages/CassandraCSharpDriver/ was updated in February.
https://github.com/Microsoft/CSharpClient-for-Kafka starts to show some of the issues you're talking about - Microsoft aren't supporting this one anymore, but they point to https://github.com/confluentinc/confluent-kafka-dotnet which wraps librdkafka - seems sensible
I'll definitely give you a point for the HTTP2/IIS issue - although there might be more technical reasons than you think for that. From what I recall, a lot of NET and Windows HTTP stuff is implemented in http.sys or WinHTTP which is a low level component. They're not going to ship a large update to anything before Win10, so that's probably why it's missing. In this case I'd just run nginx in front of IIS if you needed to, but I'd hope that most people running IIS in production can afford to update to Windows Server 2012 or 2016.
Things I've used recently include Guavas automatic argument tester, in memory caches/queues, high speed hashing algorithms, and Bloom filter. None of that stuff has real equivalents in C#.
That redis client looks solid, so I may got a bit carried trying to prove a point. The Postgres driver looks good too, but is not officially maintain by the PG team so it could evaporate some day. The Java equivalent IS an official Postgres driver. I see this with C# frequently, it's treated as second class by a lot of OSS projects.
You didn't make a counterpoint to Lucene, I assume because there was really no equal out there for C#.
These days tying your language to Windows, visual studio, and IIS is unforgivable. MS is trying to undo this with .NET core but for the time being I find it rediculous to need to pay for all these licenses. If my employer wasn't paying for my enterprise edition of VS and copies of IIS, Windows Server, and SQL Server I wouldn't be touching C# at all.
At home I use OpenJDK with eclipse and Dropwizard running on Linux with Postgres. The quality of the tech is the same and everything is free and open source.
I’m not sure if I’m understanding you correctly, that you’re saying Java is slower than .NET, and the JVM more vulnerable than the CLR?
After that, I started joking that installing malware one way or the other was Oracle's primary goal.
My understanding is Java tooling has gotten better, but being able to setup a hello world application in Java, or any established application without a ton of weird dependencies to discover always seemed painful, and "Enterprise" .Net applications didn't feel much better.
Today, my world tends to mostly center around Node.js and git... I've dipped my feet into some new .Net bits, and a little bit of go, and that's about it. I find the learning curve steep, but the actual implementation WTFs are nearly non existent. With Java/.Net it's always been a relatively steep learning curve (worse with Java) and a lot of WTFs along the way.
Setting up new applications in Java or .NET is by far easier than Node.JS.
It's Node.JS where you need 400 dependencies just to use the latest version of the language.
That said, there's many easy to use and simple frameworks for Java, and you can try also other JVM languages such as Kotlin, Clojure, Scala or Eta.
The JVM hosts the most powerful and fastest managed languages at the moment (via eta and clojure also allowing haskell and lisp on the JVM).
.NET is nice, but there's quite a few reasons why Java is used everywhere.
I'm far from a node fan, but that is simply not true. When it comes to going from zero to a "Hello World" webapp (super simple rest api that grabs data from db and returns as JSON) nothing really beats node in my opinion.
Install npm, npm install express (or restify), npm install database-driver (and there are drivers for everything), type a dozen lines of code into a single file and you're done. Sure npm is probably doing some crazy things with dependencies in the background, but you don't have to worry about it to just get started. Doing the same with Java or C# is much more involved.
Of course going from there to a large complete application is far from equally trivial and I definitely prefer working in something else in most cases, but node has the whole getting started experience down pat and that's probably the reason it's become so popular.
You add two dependencies to your gradle, write a dozen lines of code, and you’re done.
Even if you go full enterprise it’s not much more. Let’s go full Java Enterprise:
// Enterprisify everything!
compile group: 'org.springframework.boot', name: 'spring-boot-starter-data-jpa', version: '1.5.0.RELEASE'
compile group: 'org.springframework.data', name: 'spring-data-jpa', version: '1.11.0.RELEASE'
compile group: 'org.springframework.data', name: 'spring-data-commons', version: '1.13.0.RELEASE'
// persistence framework
compile group: 'org.hibernate.javax.persistence', name: 'hibernate-jpa-2.1-api', version: '1.0.0.Final'
// database driver
compile group: 'org.postgresql', name: 'postgresql', version: '9.4.1212'
// to auto-generate getters, setters etc.
compileOnly "org.projectlombok:lombok:1.16.16"
Now we’ve imported spring, our database driver and an ORM. Let’s write the code.First, let’s config:
// application config
spring.application.name=ourapp
server.port=8090
// database config
spring.datasource.url=<our database url>
spring.datasource.username=<username>
spring.datasource.password=<password>
spring.datasource.driver-class-name=org.postgresql.Driver
Then add the database layer, defining our model: @Entity @Table // To auto-generate mapping for the ORM
@Getter @Setter // To auto-generate getters and setters
public class Book {
@Id
private long id;
@Column
private String name;
@Column
private String description;
}
And our access layer: public interface BookRepository extends CrudRepository<Book, Long> {
Optional<Book> findById(long id);
}
And our application: @RestController
@SpringBootApplication
@EnableJpaRepositories
public class OurApplication {
@Autowired private BookRepository books;
@RequestMapping(path = "/{id}")
public Optional<Book> getBookById(@PathVariable long id) {
return books.findById(id);
}
public static void main(String[] args) {
SpringApplication.run(OurApplication.class, args);
}
}
So. This is if you go full insanely Java Enterprise, want full Spring, and everything. If you choose sanely, it’s obviously far less code.Notice how I don’t have to use any transpilers, etc, and still get typing and the latest language features.
But that doesn’t change the facts. Good luck getting modern JavaScript or TypeScript, without using any templates, in equal or less LOC, and easier to understand for a newbie, than my Java Spring Enterprise example below.
JavaScript is easy if you want to do tiny things, but as soon as it gets to larger projects, it has the same issues as PHP and other similar languages. Every language has some things it can do better, and some it does worse. Until JavaScript development slows down, and the compilation pipelines standardize, and there’s simpler ways to handle that, setting up a node.JS project will always be more work than a language where that has already happened.
Node pipelines are pretty nice, not quite as nice as go's channels, but nice none the less. There are different options depending on libraries. I don't find it to be significantly more cumbersome than C#/.Net (which I have more experience than with Java). Also, your "example" has a LOT of assumed knowledge, more than a relatively simple express app, that's for certain.
It really depends on the approach.
I had never worked with Spring or Java Enterprise, and could write the example after 1 hour of reading docs.
After years of working with vanilla JS, and weeks of reading docs, I still can’t get a typescript compilation and CSS/SCSS compilation and minification pipeline right. Seriously, I still can’t get it working.
I've managed to get webpack + babel + sass working pretty readily, in about the same time you mention above.
The coreclr is only maybe 10-15% faster than Desktop, but not a magnitude or more compared to old ASP.net.
I don't think that the clr is slower than the jvm, but quite a few basic frameworks are compared to their Java counterparts
And yes that's the problem. The CLR itself probably isn't slower than JVM but most of the .NET stack is. It just wasn't written with performance in mind.
I don't really think that's true.
Right, tell me the ecosystem of .NET vs Java and deployment statistics...