Nice.
Now please make C# a first-class citizen in Android and start to migrate from Java to C#.
Now please make C# a first-class citizen in Android and start to migrate from Java to C#.
* It has an enormous user base
* It's not owned by Oracle
Not saying they will but those are real possible reasons for Google to do this.
What the parent wanted was official support from Google for Xamarin's Android API wrapper or a complete rewrite of core parts of the OS in .NET instead of Java. It seems fairly unlikely because of all the effort Google has invested in their Java VM and JIT/AOT compilers, but maybe that'll change.
So you replace one lawsuit-happy DB company with... another lawsuit-happy DB company.
It would be nicer if there was a managed langauge platform that was not tied to an entity with a history of patent litigation, but let's not lose our sense of scale here. The degree to which Oracle has betrayed our community and tried to undermine the bearable status quo of the software industry to milk the Android ecosystem is as unforgivable as anything Microsoft has done in the darkest depths of the Balmer era.
I'm not convinced Microsoft is as lawsuit-happy as Oracle.
I love Go, but it's not really a suitable language to do UI, or anything that deals with data models.
C#, however, is a perfect replacement for Java, most of the times. I would say "it's simply superior in every imaginable metric other than cross-platform implementations of the compiler/VM" but that's just my opinion.
Oh really? Why?
Java has anonymous classes and static interface members as the only real advantages over C#.
The async/await API's and their rigid nature was torture and the language was overly loose as if users asked for everything and got it... The reason I left C++ for Java 20 years ago is the things it removed and discarded (e.g. operator overloading) C# to me is a step back in the direction of "everything but the kitchen sink".
Way better than callback hell. The only awkwardness surrounds streams of tasks.
Operator overloading is a necessity. Matrices, big integers and so on, all require the familiar operators for clear code. Type inference is here to stay, and every new language has it. The fact that every language is also trying to adopt a streaming API like LINQ should also tell you something.
I'm afraid you're on the losing side of history on all of these points. C# does include a lot, and I would certainly prefer a single uniform abstraction to handle many things, ie. generators and async/await can be unified under coroutines or something similar, but the proliferation of "kitchen sink" features is not nearly as bad as you imply.
now generics is a problem of its own when working with data and algorithms, but they managed to get along with it in the backend so far, so...
Mind you, there might be an opportunity there for developing a different kind of UI paradigm where interface elements don't map to objects and actions are the main driver of screen updates. Anyone has any ideas of such a paradigm?
See, I feel the opposite. I think UI programming is the worst application of OO-design because the data and actions of a UI are inherently decoupled.
You have have n data structures and m events that can be fired on a page and not every event is associated with every data structure. However, importantly, any event can be associated with any number of data structures, some of which may not even be conceived at the time of run/execution. OOP-doesn't work well in situations where you have functions that can operate on lots of disparate data-types.
When you apply OO principals to UI work, you end forcing a coupling that artificially limits what you can do with the data, requiring an increasing the levels of abstraction in order to provide baseline functionality. For example, when you have a button, it's an object, then if you want to apply a listener to it, you need to create a method on Button that accepts a listener. But to ensure that the method can actually interact with the passed object, you need to create an interface then ensure that every potential listener implements it. There is an entire world of classes that could be bound to the listener as-is, but those existing classes don't implement the correct interface since they didn't know of its existence. So the OOP-land solution is to write wrappers for every class you'd like to attach as a listener to the button.
In a functional world, you can attach any function that takes the appropriate number of arguments and be on your merry way. If the function doesn't fit that mold for whatever reason, you can cleanly wrap it in an anonymous function right where you're attaching it as a listener.
For instance, let's say you have a very simple Resize Image dialog, with two fields for desired height and width and a toggle button for keeping the current aspect ratio. Your data model is just (height : int, width : int), but you also have a UI state (keepAspect : bool). Changing the state could affect the actual data model, but it's not part of the final data you get out of the dialog.
In the traditional OOP paradigm, you'll just have to mix data and state, and once the UI gets more complex, you'll often end up with convoluted and bug-prone UpdateWidgets() methods being called after every user action or external data model update, and this function will both read and update the data model, the UI state and the UI view parameters. With the FP paradigm, you can just cleanly implement one function which receives the data model and state and creates the UI View, another function that enforces constraints on the data model and state and a few event handlers for specific user actions. This is essentially what you get nowadays with the more well-conceived workflows in ReactJS.
But while I really like this style of programming, I don't see how you can apply it to go. If there is one thing Go is worse at than OOP, that's FP. Go has no concept of pattern matching or currying, almost no inference, a cumbersome closure syntax and a pathetically weak type system without generics. Yeah, I know, JavaScript also falls short on most of the items in that list, but being dynamically-typed you can still easily write higher-order functions like map, filter, reduce and compose. Try to do that in Go without using reflection.
The Go authors and community seem to favor explicit for loops to functional constructs or comprehensions, and a little bit of copy-paste to function composition. That's OK, since Go's #1 goal is to be 'simple' in the sense that the code you see describes the imperative execution flow as accurately as possible, with very little magic happening behind the scenes. As far as UI design goes though, Go is probably even worse than C in some respects, since it doesn't even have these fancy macros that helped us brave UI programming back in the day. ;)
C# on the other hand, offers not only better-Java-than-Java OOP, but also an array of surprisingly competent functional features which keeps increasing with every language version. It had proper generics and closures since version 2.0 and covariance/contravariance and lambda syntax since version 4.0, expression bodies since version 6.0, pattern matching and tuples since version 7.0 and it will hopefully have proper record types and discriminated unions by version 8.0.
In Cocoa, you don't have these silly class-specific interfaces ("ButtonClickListener" or whatever). Instead it uses target/action: you give the button an object, and the method name to call on the object. So it does allow you to bind any member of that "world of classes" as-is.
Next, you allow the target to be dynamically determined. For example, say you have a button representing the Copy to Clipboard. You can set its target object to a sentinel representing the keyboard focus. And the button can even use reflection, and disable itself if the focus doesn't support Copy.
In a functional world, functions are opaque: the only thing you can ultimately do with a function is call it. But in an OO world, functions are closer to objects: they have names, they can be inspected, they can be dynamically dispatched. This is part of what makes OO languages excel at UIs.
but, you may probably as well organize them as nested property sets each of which containing the other ( like a listview contains a view part and a list part). Not sure the result will be as elegant, but i'm curious to look at the result.
None of them have all those million engineer hours baked in, not even close.
My guess is that the CLR have more man hours spent on than both those two implementations combined.
http://arstechnica.com/tech-policy/2016/01/android-n-switche...
From the outside it seems like a lot of work. Firstly HotStop is not optimized for fast startup, small footprint or short GC pauses. There is talk about merging the Java ME VMs but such things usually take years. Secondly Google built many proprietary extensions, eg DEX. I'm not sure that ART can even execute Java bytecodes.
Additionally, most high-performance JVMs are optimized for long-running server applications, wile the CLR is optimized more for desktop applications (considerably better startup time, is fast without requiring lots of warmup, but doesn't do some of the very advanced optimizations JVMs tend to do). I suspect it would be easier to make the CLR performant on mobile than to make a JVM fast with constrained memory.
So basically, the CLR is probably already competitive on mobile devices. Does anyone know if Windows Phone uses a stock CLR or if they reimplemented it? Seems pretty snappy.
The .NET CLR isn't really "fast without requiring lots of warmup". It's a much simpler design that out of the box simply compiles each method the first time it's used. It doesn't "warm up" because it doesn't do profile guided or speculative optimisations at all. The weakness of the CLR is one reason C# pushes more optimisation complexity onto the developer e.g. having to mark virtual methods explicitly instead of methods being virtual by default. With respect to memory usage I guess it's not much different.
There are JVMs designed for old candybar feature phones (J2ME etc). The issue is not "can you make a mobile JVM" as the answer is clearly yes for any type of phone, even very old ones. The issue is "how much fancy technology can you fit in that space".
Memory use is quite different due to reified generics and value types.
.NET is AOT compiled to native code using the same backend (C2) as Visual C++.
After Google own teams decided to go Typescript, the Dart team seems to keep searching for reasons to keep the project alive.
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl...
There's no reason why it can't be reversed, with Xamarin (or something along these lines) becoming the new native high-level API, and Java being a compat layer on top of that.
I doubt it will be officially acknowledged by Google, but hey they never acknowledge third party good things, and the official Android developers docs still tech us to do networking with HttpUrlConnection and threading with asynctask, we moved on to okhttp and retrofit and rxjava anyway
Not by a big margin. Java 8 has lambda functions, which used to be the most painful aspect of the language for me.
For example, in Java, you have this: http://docs.oracle.com/javase/8/docs/api/?java/util/function...
Note all the permutations. This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. So you end up defining separate types for things like int->int, int->int->int, long->long etc. And then if you need e.g. bool->int, well, that's just too bad.
Whereas in C#, you just have Func<...> and Action<...>, and they work with all permutations of all primitive and user-defined types.
Actually, that's going away with Java 9 (or 10). Luckily.
Moving android away from Java is going to be a big undertaking and I doubt Google will undertake such a huge project only to move away from Oracle and closer to MS.
If they ever try to replace Java, it'll be Dart or another language they acquire in future. Dart has good chances.
They already have an early stage framework to make Android (and iOS) apps with Dart[0]. It's also the main GUI toolkit for their Fuchsia OS [1].
* - based on the premise that MS might be open to this after failing at mobile over and over again
What Google is to get out of it is a more interesting question.
What would be ideal would be that Apple, Google and Microsoft sit together and agree on a common language and GUI API that would work on Android, iOS, Windows, MacOS and Linux natively.
Or for something more like C#, Delphi? https://www.embarcadero.com/products/delphi
Both these platforms, which include a cross-platform UI library including native controls, are Windows, iOS, Android, macOS, and Linux in the next release.
Even C# is starting to show its age. Perhaps it's the occasion to reboot it. Start from scratch based on modern concepts with a truly cross-platform language.
With support from Microsoft + Google + Apple, and cross platform across Windows, MacOS, Linux, iOS and Android, adoption would go to 100% (or 11!) on month 1.
What's more likely these days is Google entering the desktop space (x86) by merging it with mobile (e.g. Andromeda). Pretty sure that OS could grab 30% of new laptops in a heartbeat (think: almost free for manufacturers: no Win license).
Meanwhile, I'm pretty sure Apple will do its thing (did they fix Gmail on Mail yet?) Though I think Swift, if it were in "the state of C#/.NET" as worded above, would eventually become a great candidate for a high level common language. Somehow I don't think Apple is trying, their open-sourcing seems to end at "reassurance" (stacks can't die if you can maintain the packages, b/c oss, yay).
But even C# is starting to show its age and would deserved a reboot. If we agree on a truly cross platform language, we might as well make it modern and simple, with great tooling. That does mean breaking backward compatibility with older languages but the benefits of having a common language way offset the cost of retraining developers.
http://www.investors.com/news/technology/microsoft-alphabet-...
Because mentat asked please.
In other words, it might have less to do with the merit of the language than with the politics of the organization.
Maybe Google could decide that putting resources on Dalvik and related tool development does not make sense.
Maybe they would like to see one language to cover both the client and cloud development.
In this spirit of enabling developers and their organizations, Google is pleased to be joining the Technical Steering Group of the .NET Foundation. .NET is a key component in the modern enterprise, and the Google Cloud Platform (GCP) team has worked hard to ensure that .NET has first-class support on Google’s infrastructure, including excellent infrastructure for Windows.
Not that we aren't already headed there with a ton of app frameworks embracing javascript.
What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless.
This is exactly what COM was, and what its current evolution, WinRT, is. Any language that can do C structs and function pointers can ultimately do COM/WinRT, but it establishes things like lifetime semantics (refcounting), runtime metadata API, standardized futures etc on top of that. Then languages take that and map it to things that make sense there.
But it needs to be a shared public spec, preferably standardized.
Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).
The problem with conventional C ABI is that it's just too low-level to produce good wrappers. I mean, all you have are global functions, structs, and data and function pointers. There isn't even a standard string type! (you can say char*, but there's the need to deal with lifetime issues - who deallocates what).
So in practice you need the C ABI, plus all those conventions, like how an "object" looks (i.e. how you do things like method dispatch or type queries), how a callback looks, how strings work etc. And all those conventions are expressed in terms of that basic C ABI - but they also have to be standardized, and they become ABI of their own, like COM and WinRT.
And you also need a convention/standard for metadata, for those wrappers to consume, and for any sort of runtime magic like property bindings - like typelibs for COM and metadata assemblies for WinRT.
I like C# but making a language a first-class citizen of a platform is an huge task. And we can already use kotlin without re-engineering the whole stack.
And last I checked you couldn't use Java 8 fully on Android (please correct me if I'm wrong).
There are still uses though. Lambdas are the future, but there are lots of OO-first libraries that are still quite popular. It'd be nice to create e.g. `new Newtonsoft.JsonConverter() { ReadJson() {...} WriteJson() {...}}` etc on the fly sometimes without needing separate classes.
It's possible in F# though, so nothing dotnet specific is preventing it.
public static final MyInterface SINGLETON = new MyInterface() {
...
}So, yeah, go away because that's not contributing to the conversation.
Well, maybe there’s another implication.
Google switching to C# would lead to them neglecting and deprecating the Java ecosystem on Android. That’s gonna be real ugly for app devs, ending up having to rewrite everything.
So, maybe, there is a real contribution in the comment, which you just haven’t seen yet?
Paul Graham once said [1]:
I think it's ok to use the up and down
arrows to express agreement. Obviously
the uparrows aren't only for applauding
politeness, so it seems reasonable that
the downarrows aren't only for booing
rudeness.
It only becomes abuse when people resort
to karma bombing: downvoting a lot of
comments by one user without reading
them in order to subtract maximum karma.
Fortunately we now have several levels
of software to protect against that.
Many have taken this to mean that down voting a comment when they disagree with the opinion therein, no matter how well it argues that opinion and no matter how much it contributes to the conversation, is fine.
The down vote causes the comment to be dimmed and seen as a rejection to the comment. It is very frustrating when the top right side is your name and your "Hacker News Points" so I don't get why the down vote if you disagree. A down vote kills the conversation.
A credible threat of Google moving Android away from Java is the best hope we have of this situation ever improving.
- Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention.
- The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.
Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.
For most devs, Visual Studio isn’t a realistic option.
Windows is the de facto standard in most places that aren't chasing the leading edge.
I’m not sure anyone would agree with that.
Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers.
Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.
But good job with the warrantless and wrong contempt.
Project Rider by Jetbrains is a cross platform C# IDE.
VS Code has some tooling.
etc...
Project Rider is still extremely green and is not FOSS, nor free as in free beer.
VS Code is extremely limited and the little support it has is for .NET Core only.
I'm right now working on an MVC 5 project on Linux and I have to jump around MonoDevelop and Rider to have a workable dev environment; with the occasional jump to a Windows VM and Visual Studio to make sure everything works over there (it often doesn't).
.NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS. If you want to do real work with it you have to eat, breathe and live Windows and VS.
If I didn't absolutely have to work with .NET in this particular situation I would've laughed all my way back to a real cross-platform stack.
.NET isn't, and wasn't officially meant to be. That's your problem.
I've been working on a .net core web app on my mac exclusively now for the last 8 weeks and have had no problems with it. I do check to make sure it works in full VS/Windows occasionally and every single time its worked without fail, and without a single change. Just pull the code and go. I haven't needed to touch windows but its nice to know it still works over there anyway.
Using VS Code as my main editor. Tried Rider a little yesterday and I'll probably switch to that once its more stable as it has a few more tools for refactoring etc.
So .NET core is clearly what's intended to be used cross platform, and it works great.
Idk about Swift, never used it yet.
I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).
The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example:
void DoSomething(MySpecialType value);
void DoSomething(string value);
////
var result = GetData();
DoSomething(result);
* GetData() is probably badly named in this situation
* If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded
On top of that, this code can also have the same problem without type inference:
DoSomething(GetData())I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.
Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.
If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way.
Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.
Sure, different types shouldn't use the same method name for different functionality, but it happens. And when such a scenario happens, I imagine it will be quite nasty to debug.
I've used var since it came out years ago and never had this autocompletion problem you talk about.
You sometimes had to explicitly declare a type in foreach loops, but that had more to do with shitty legacy APIs that used abstract classes as return types. Wasn't really var's fault though.
You have a Toilet object with a method flush.
var toilet = house.getToilet();
toilet.flush();
I agree this problem would also occur when using chained calls (house.getToiled().flush()), but explicit types could cover at least some of the cases.
This has happened to me exactly 0 times since type inference was introduced in 2007/2008.
99% of the time it's completely obvious what the variable is because you can just look at the right side of the equal sign.
Also, you can just hover over it.
As for the extension methods, they pretty much fixed that in VS 2015, it will now tell you which using statement you need to include.
Extension methods are a good solution to a specific problem.
Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>();
Is prefferable to:
var foo = new Dictionary<string, Tuple<int, List<string>>>();
What do you get from the former that makes the eye-pain worth it?
Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.
Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<>();
Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.
TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.
One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you.
Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.
Extensions methods can be approached via default methods.
Java 9, latest by 10, will get var. It is already on the approved roadmap.
Operator overloading is probably the worst feature ever invented, same with Class Extensions, reducing readability of code.
And with a switch to C# Google would neglect the Java ecosystem on Android, requiring us app devs to rewrite everything again.
I’m not sure there’s an upside to switching to C#.
C# also has yield, async, structs, reflection on generics, and a number of other features.
Class extensions can be fantastic and really enable design elements in elegant ways, any advanced feature could be argued that it reduces readability if used poorly.
or greatly enhancing it. Depending on how you use it.
That's why Java is a language for idiots. I'm not saying everyone who uses it or likes it is an idiot, it's a reasonable language to like. I'm saying it's designed to be usable by idiots. Can't have operator overloading, it might be abused. Can't have unsigned types, no one ever should use those. etc...
A seemingly common sentiment, but one rarely backed by any meaningful data.
Swift, Scala, and C# are statically-typed languages, like Java, whereas Apache Groovy is dynamically-typed originally -- though static typing was added in Groovy 2, virtually no-one uses it. Dynamically typed languages like Groovy are good for glue code, build scripts, and testing, not for developing actual systems.
Likewise Java's OOP enums (basically singletons) are something I miss too.
That's a few small features I notice missing when I switch to C#.
Plus, in general I find there's a difference in style. C# libraries tend to be more pragmatic, following on Microsoft's heavy use of reflection and stringly-typed stuff. Not much OOP navel-gazing.
Java, on the other hand, celebrates OOP to a ludicrous extreme.
Also on the community, C# has been working very hard to develop the kind of bazaar that Java has, but they're coming from far behind on that front - far more C# developers restrict them to the first-party tools compared to the Java ones.
There was also nant and a number of build tools, plus good old make.
C# guys are working on adding full-fledged pattern matching to the language:
https://github.com/dotnet/roslyn/blob/features/patterns/docs...
and there's a concurrent proposal for ADTs:
https://github.com/dotnet/roslyn/issues/6739
Given the velocity of adding new features in C# these days, these will come sooner rather than later (indeed, some basic pattern matching is already in C# 7).
Also, Google joining the .NET foundation was a cloud move. Nothing more.
there is a lot of Innovation going on, with the new open source .NET. the CoreRT[1] project compiles C#->C++->Machine code for any platform, including ARM. and Samsung has been a big contributor to make that happen. and today during the Connect() event, they announced that every Xamarin forms app will run on Tizen[2].
[1] https://github.com/dotnet/corert [2] https://www.tizen.org/blogs/dh0922/2016/tizen-.net-developer...
CoreRT uses RyuJIT.
C# is close enough that ART could likely be extended to encompass it. But it would be somewhat more work than supporting an actual JVM language.
BUT the real question is, with modern IDEs, does it matter? How much do you need a prettier and/or more concise language? And if you do, why not Kotlin?
Apart from that, C# and Java are not very different from each other. You can get many of that "features" from other Java languages, no need to move away from the JVM, so you can still benefit from the largest community.
You could even compile C/C++ to CIL and obviate the need for some architecture specific binaries.
The GP wants to avoid shipping N different binaries for N platforms in cases where the C/C++ code being called isn't already on the platforms.
I haven't used Managed C++ and I'm fuzzy on the details, but my understanding is that a fairly large subset of C/C++ can be efficiently compiled to .NET CIL. (Of course, the class loader for untrusted security contexts will refuse to load classes that use the type-unsafe/memory-unsafe portions of .NET CIL, just like the Java classloader for untrusted applets won't load classes making arbitrary JNI calls.)
And, indeed, VC++ lets you do just that. There are some bits of the standard library, mostly new stuff like threads and atomic, that had some issues, as I recall. But it's more about the amount of effort that's needed to target what's essentially a completely different platform.
The thing to know about CIL is that it has:
- structs;
- unions;
- raw data pointers, with pointer arithmetic;
- raw function pointers;
- dynamic stack allocation (like alloca in C);
- tail calls;
- exceptions with exception filters (arbitrary expression evaluation when deciding whether to transfer to a given catch-block or not) and finally blocks.
I'm actually curious if there's any language that cannot be compiled down to this efficiently.
If you bothered to read why DLR was created, you will see why CIL wasn't enough.
Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matters for the lower level is that it's flexible enough to permit something like DLR to be implemented on top of it. CIL is undeniably flexible enough for that.
Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.
Yes, it's COM. People assume that makes it non-cross-platform, but there's nothing Windows-specific about COM, it's just a slightly higher-level ABI than C. So Mono supports it on Linux in the same manner. Not sure what the story is in .NET Core.
EDIT: Instead of downvoting, please point out how LINQ is actually superior?
How do you extend the the java Stream API? for LINQ you just drop in a few extra extension methods for IEnumerable<T>, IOrederedEmumerable<T>, IQueryable<T>, etc.
How do you reverse a stream in java? (I know you need to evaluate the whole stream for that) You can write a utility method, but that will break the fluent readable logic. In C# you can do the very same thing, with the same method usable as an extension method keeping the readable fluent expression.
Starting a stream is a PITA itself, as it differs for Iterables, Arrays, Collections... Been there, done that. Not that with some utilities these could not be overcome, but it was an inferior experience to LINQ.
By calling .reverse() on it, and making it iterate the other way around?
> extension methods
Extension methods are something that’s really really problematic, and easy to create confusion with.
That said, I’d just import the functions I want to call on the stream into my local namespace with import static.
Edit: Just checked: https://docs.oracle.com/javase/8/docs/api/java/util/stream/S... no reverse().
Fyi for 1 year I have been working on a Stream API heavy app. Now working on a C# project with quite some LINQ. I know both sides to some extent...
After my experience with Mono on past .NET versions, I'm skeptical of any of these "compiles to x" schemes.