I know MSBuild gets a lot of hate but this is still great news. The end goal of having a .Net project be compile-able on Windows, Linux and Mac is going to be awesome. I'm curious, when everything is finally done, what the adoption rates will be like. Will hard-core Linux users who used Java migrate when it makes sense? Will they avoid it because "M$"?
Indeed. And they cannot play the "but Java is OSS" card anymore as Oracle has made it pretty clear that Java's APIs are proprietary and that you will be sued if you do anything not authorised by them (which effectively removes the 'open' in "open source software").
Say what you will about the Android Java situation, but it doesn't exactly scream "this is open and free software."
I read somewhere that Microsoft's structured the patents/licenses in the .NET ecosystem in such a way as to make that kind of lawsuit unlikely. Can anyone comment if that is true?
I think the most important part is that the new cross-platform .NET core framework, CLR, and compiler (Roslyn) are under permissive open source licenses (MIT for fx and clr, Apache 2 for Roslyn). You can see licenses and patent pledges here: https://github.com/dotnet/
Disclaimers:
1. Microsoft employee until they notice I'm hanging out on hacker news instead of replying to e-mails and "fix the glitch".
It's not a question of $ or of liking MS, it is a question of trust. Microsoft can and will suddenly discontinue entire solutions like Silverlight. I know of a company that is in real trouble because they first rewrote their entire application in Silverlight and now have to do it again in HTML5...
Java on the desktop is almost dead due to the horrible JRE by Oracle. On the server and on Android it is alive and well, and the community is big enough to keep it going even if Oracle loses interest. It will also make its return to the desktop one day when someone figures out how to make it suck less, as the language and the available libraries are awesome.
> It's not a question of $ or of liking MS, it is a question of trust. Microsoft can and will suddenly discontinue entire solutions like Silverlight.
In all fairness all technology companies are like that. Hell even open source groups are like that. If the community disappears why would you continue to invest millions into it when better solutions are coming around the corner? Silverlight, for a while, was absolute king in video streaming (you could squeeze much more quality out of it than flash) but like with everything on the web unless it's strictly standards-based you're going to run the risk of it being discontinued when better standards come around.
I don't think that's really a fair knock against Microsoft.
> It will also make its return to the desktop one day when someone figures out how to make it suck less, as the language and the available libraries are awesome.
Good luck with that; it's going to take a desktop OS who can make a Java GUI framework feel native and not horrible and at this point I don't know why any of them would invest in this.
It might not be fair; it's just that in my mind one moment Microsoft was hyping Silverlight and the next moment they were discontinuing it. That's not a nice way to treat your customers.
What Microsoft should have done is to make it compile to HTML5. Something like SmartGWT is a great way to write interface in Java. It may even be the way the Java ends up on the desktop again.
I always find it a bit puzzling when people blame Microsoft for the death of Silverlight. As an in-browser technology, Silverlight's success depended entirely on the willingness and ability of third-party browsers to support it. It just needed one browser to gain a significant market share and then refuse to play ball to pull the rug right from underneath Silverlight's feet. This is what happened in 2010 when Apple blocked it from the iPhone and the iPad. Sure, that move was aimed at Flash, but Silverlight took collateral damage from which it never recovered. That wasn't something that Microsoft could control.
@Silverlight:
are you much better off if you've wrote a Java Applet at the same time ? (I think this was the right thing to do in Java back then)
We were trying to use Java Webstart, but we gave up, because of the fact that some modern browsers just block the Java plugin.
I have to use a Java applet for some customer VPN's I am connecting to and the only browser this works for me is Internet Explorer to connect to those VPNs.
You can still write Winforms applications and this is some really old technique. Maybe you are still able to use MFC, but I haven't tested that in a LONG time.
That's true, but at least Java applets died a natural death instead of being axed.
I checked the history of Silverlight and the first version was released in 2007. jQuery was released in 2006 so Silverlight was a classic case of "too little, too late".
Real Java applications run well nowadays, so much so that you don't notice it's Java (except that you always have to give them more memory...)
It will be very nice to be able to do CI/compilation on extremely cheap and fast (to spin up) linux slaves as opposed to requiring an expensive (license, hardware) and slow (miserably slow ec2 boots) Windows servers.
Good Lord, yes. It takes forever for my TeamCity build agent AMIs to spin up and actually connect to the TeamCity server. It would be awesome to replace that bulky Windows build agent with a Linux one.
I gave up on activating windows agents programatically, I keep one powerful windows build server running, it spins down at night after regression testing, then back on during the day when employees come into the office. The pocketbook definitely feels it, though.
The Mono framework[1] has been pretty popular in some circles for years now, so I imagine a decent amount of adoption can be expected once .Net Core proves stable.
> The end goal of having a .Net project be compile-able on Windows, Linux and Mac is going to be awesome.
Except msbuild can't easily support builds across different version of .NET on the same platform. I hate digging into its needlessly archaic build files.
.NET was already somewhat popular on Linux for GTK apps. I don't know if you're going to see adoption for web servers unless it can be competitive with Java in performance, which I don't think Mono has traditionally been.
Seconded. Performance is the main thing holding me back.
I'm very excited about C# and other .NET languages for server applications, and would like to make it my primary server side environment, but am waiting for three things:
1) A production ready compiler and runtime on Linux (coming)
2) Tooling to support the new .NET project structures and dependency management (coming, it seems)
3) A production ready server solution with reasonable performance. On Mono, .NET Linux server apps consistently score near the bottom of benchmarks, essentially ruling it out. (Who knows? It seems too early to know whether this will happen.)
There has been work on performance and more to come (source: ASP.NET Community Standup podcasts). The stated goal is to be in the ballpark of the top performers. You can follow the progress here:
Very happy to see a focus on performance on the roadmap.
I've actually seen that benchmark page, but all the results it lists are for the Web Server running on Windows (perfsvr), where Linux is only used for load generation.
Any idea if the results are similar with the server running on the Linux machine (perfsvr2)?
> Will hard-core Linux users who used Java migrate when it makes sense?
Probably only for mobile/desktop app but less likely for back-end/webservice/infrastructure stuff.
Take MSBuild. This is pretty much Ant. Sure, there's NuGet but Ant+Ivy or MSBuild+NuGet combo isn't anywhere close to Maven (despite the XML hate).
Libraries, communities, tools, frameworks of .NET ecosystem is still behind Java.
Unfortunately language features and syntatic sugar alone probably not enough to sway these users. Besides, Java and C# are very similar, technically there's less reward in learning a very similar language.
Oh, God, thank you! I've been hunting and hunting for something to replace CruiseControl. I had no idea this existed. Is there an easy way to turn this into a CI?
Maven manage your module/projects from building, dependency management, generating project website (if you want to), deals with packaging, and deployment (if you want to), and many more (via plugins).
Maven is essentially NuGet+MSBuild or Ant+Ivy or Bundler+Gem+Rake without having to manage build tasks manually.
Those tasks are:
1. Compile code
2. Compile test code
3. Run unit-test
4. Run integration-test (separately from unit-test)
5. Setup paths for running unit-test (say you want to use different config/resource files for your unit-test)
6. Package your artifacts _without_ the unit-test artifacts
Maven has these built-in and in a non-disruptive manner. Don't have unit-tests? Maven won't run anything for you.
You have unit-tests source code and assets that you don't want to be included in your final build? Maven will handle that out-of-the-box-no-config needed.
While people might prefer to use "one tool that does its jobs beautifully/correctly", the reality is that you need at least 2 things to build the project: tool to manage your dependency and tool to build+package your project.
It's the only build system I've ever seen that's truly declarative. You can't put random turing-complete computation in the middle of a maven project definition; you can only invoke well-defined plugins (if you want a custom build step, you package it up as a plugin - written in ordinary java, unit testable and all the rest of it).
The result is there are no "snowflake builds". One project tends to build exactly the same as any other; virtually every project uses the same source directories etc.. It makes it really easy to be productive straight away when switching projects. And the limited build steps mean the IDE integration can be very complete.
Yeah and last time I used it at work (2012-2013) it didn't even support incremental builds. Even the company's best Java developers just accepted this as normal.
I think maven did not push incremental builds because there was not a big need.
Most people code Java in an IDE. Both Idea and Eclipse do incremental builds inside the IDE. So as you are coding, you are incremental building.
Every place I have used maven, maven was used for the build server and the final release. Spinning on a webpage changing some code? You are using your IDE for that.
(Now scala is a little bit different, so we have SBT with incremental support as a pretty ground level thing)
Adding to all the good points that others mentioned, this sort of consistency only grows in importance in large companies where developers support many different projects. It allows you to focus on the business problems rather than spend time getting used to dozens of variations in the build themselves.
We had this problem with Ant many years ago. Everyone did their builds differently and half of them were subtly broken.
Do you have any practical experience of using MSBuild? If you have ever worked on MSBuild and other build tools (e.g. ant, maven, even make for that matter), you would have noticed how difficult it is to write or extend simple build tasks in msbuild. Have you ever tried to use MSBuild to build anything on a machine that doesnt have visual studio installed? If you use any other ide, the separation of IDE and the compiler is very clear. Try figuring out the build parameters that Visual studio uses to compile your code.
It's a whole different ecosystem - it's not like Scala where I can sling in one class on an existing Java codebase. .net isn't just its own VM, it's its own IDE, its own build tool, its own packaging model....
For little standalone pieces - the kind that people write in D or OCaml because they want to - I can see .net being used on linux. But I don't see anyone migrating an enterprise Java codebase - it's just too much effort for too little gain.
1 year ago, yes. C# is awesome as a language but I don't see a reason to switch to .net when the JVM has Kotlin, which is nicer than C#, but still super lightweight and thoroughly pragmatic.
Nicer in what sense? I do like both, I'd take either of them over Java on any day, but whereas Kotlin is maybe better suited for functional style programming (immutability out of the box, data classes etc. - however .NET people always have F# for this stuff), it's hardly on the same level as C#.
For instance Kotlin doesn't have reified generics (if I recall correctly they actually attempted it, but it's too hard to get it done on JVM), Kotlin doesn't have yield-return semantics, Kotlin's equivalent of LINQ doesn't use deferred evaluation. Kotlin doesn't have async/await like C#, which is a real gamechanger when it comes to asynchronous programming. It's very nice and promising, but it's not in the same league.
As far as JVM universe goes, Scala could give C# a better run for its money.
Of course it's not fair comparing Kotlin to C# - for numerous reasons - but if we do it anyway, it's got to be honest
>Kotlin's equivalent of LINQ doesn't use deferred evaluation.
Wow, I'm pretty surprised at that. Any kind of list comprehension/functional sub-language over collections seems like it ought to be deferred/lazy from the ground up. I'm doubly surprised at that from JetBrains.
Unfortunately it is so, so I wouldn't recommend it for large collections, or wherever performance considerations come into equation.
Let's peek at Kotlin's sources (_Filtering.kt):
public inline fun <T> Iterable<T>.filter(predicate: (T) -> Boolean): List<T> {
// note how it's allocating a new ArrayList<T> -
// Kotlin doesn't have a "new" keyword, but it's initializing it here
return filterTo(ArrayList<T>(), predicate)
}
And it redirects to filterTo:
public inline fun <T, C : MutableCollection<in T>> Iterable<T>.filterTo(destination: C, predicate: (T) -> Boolean): C {
for (element in this) if (predicate(element)) destination.add(element)
return destination
}
With this approach, if you're chaining several of these operations, you will end up allocating quite a few arraylists, one by one.
Note that without something like yield-return in place, writing your own collection-transforming extension functions with lazy evaluation won't be so clean and easy either
Since it has 100% interop with Java, you could work around this problem by using something like Guava - Iterables and FluentIterable are based on iterators as they should.
They use static helper methods, all you need to do is to snap out some extension functions in Kotlin to serve as bindings to Guava. The only problem, especially on Android, is that Guava's notoriously big.
Kotlin is good, I'm not hating on it, but mature? Not yet. Nicer than C#? Best of luck, but not with this type of shortcomings
* new (lazy) extension functions would be getting in the way of standard ones, you would need a paralel naming convention (perhaps one borrowed from LINQ, where map = select, filter = where, fold = aggregate and so on) and developers would still confuse one with another.
* unless we agree on one canonical implementation, yours would be different than mine, easy to see how it could become a mess.
If there is a better approach which removes these obstacles, someone let me know
I'd argue that just because a language runs on a platform with a potentially large number of third-party support (JVM) doesn't mean it's going to be nice to use.
For example, I ended up having to write Java code when dealing with large XML data sets in a Clojure system, because the current offerings simply didn't let me do what I needed in fluent Clojure code. I suspect Kotlin has those same kinds of issues, just amplified because it's a lot less widespread than Clojure.
The fact that it integrates with Java isn't what I'm getting at. Developing in Clojure eventually forced me to write some Java, which I didn't want to do. I just don't see Kotlin as somehow solving that problem.
My reason would be: I can choose from a ton of C# positions, meanwhile Kotlin would have what? In my and neigbour countries I can find exactly zero Kotlin job offers.
That is true. I assumed I would eventually go into business for myself and see no reason to use C# - besides Kotlin is very young, there is still plenty of time to get in on the ground floor so to speak.
All good stuff.