Announcement

Collapse
No announcement yet.

Mono Developers Renew Their Love For Microsoft

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Pajn View Post
    I really like C# as a language. But the way Microsoft treat is I'm never gonna use it when I have the choice.
    Microsoft need to create a full standard and make an open implemention the reference.

    Also with Java 8 i feel less urge to use C#
    Microsoft does give you a much better choice than C#: F#

    Scala is better than Java (and C#) in almost every way. Even Java 8. I do hope the Scala team updates to JDK 8 and provides platform lambda compatibility. Android is the big problem that pushes everyone for JDK 6 compatibility.

    C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.

    Comment


    • #32
      Originally posted by ciplogic View Post
      This is not true anymore.
      I can say that there are definitely parts where Mono and .Net (and to some extend Java) are faster than C++:
      When http://benchmarksgame.alioth.debian.org/ was alive, C/C++ generally ran the fastest, Java behind that, C#/MS .NET behind that, and Mono was much slower than MS.NET.

      Originally posted by ciplogic View Post
      There is one case when Mono runs virtually the same as C++: on iOS as it uses the same compiler/optimizations as a C++ compiler would do it.
      citations? I'm skeptical of this.

      Beyond the speed, those kinds of porting layers often add a lot of unwanted complexity to the application development stack. They add extra layers that have be debugged through in the case of problems.

      Comment


      • #33
        Originally posted by directhex View Post
        This is a Javaism. Hotspot allocates enormous amounts of memory.

        Mono isn't particularly RAM-heavy.
        I've seen Java allocate lots of memory on really small benchmark apps, but on larger apps, in my experience, it depends on how much data your app loads in memory. Java doesn't add much overhead. I wrote code that loaded 4.5 GB of binary data into memory and performed data analysis. The Java app took ~4.5GB of RAM. I believe the JVM had a few megs of overhead, but that's just a rounding error with data that large.

        Comment


        • #34
          Originally posted by DanLamb View Post
          Java doesn't add much overhead.
          That entirely depends on how you process the data. Load gigabytes into an array and you'll probably be fine. Load gigablytes into an array of Byte objects, and you could find it takes 10x or more RAM than you thought you were going to need, because that becomes an array of pointers to allocated objects.

          Comment


          • #35
            Originally posted by movieman View Post
            That entirely depends on how you process the data. Load gigabytes into an array and you'll probably be fine. Load gigablytes into an array of Byte objects, and you could find it takes 10x or more RAM than you thought you were going to need, because that becomes an array of pointers to allocated objects.
            Sure, Java lets you write inefficient code. No language is idiot proof. If you use a totally inappropriate data structure you can get terrible results.

            Comment


            • #36
              Originally posted by DanLamb View Post
              When http://benchmarksgame.alioth.debian.org/ was alive, C/C++ generally ran the fastest, Java behind that, C#/MS .NET behind that, and Mono was much slower than MS.NET.
              First of all, the benchmarks are different, and probably you understood that what I stated it was: "in some cases".

              I am working to an (non conforming) implementation that rewrites CIL into C++. I can say that 1:1 translation from CIL operations to C++ (using smart pointers), makes C++ code to be 16x times slower than .Net (ver 4.5). If an optimizer is applied over C++ inefficiencies you can get like 20-30% faster with C++.

              [1] http://coderefractor.blogspot.com/20...c-be-fast.html
              [2] http://coderefractor.blogspot.com/20...very-fast.html

              This is my analysis on the subject, so I can give to you some reasons this is the case, but I want to make sure that you understand that I am impartial in the review. In fact, if you read the first review, I advertised Java at least for performance (I don't like the language, but the runtime is decent... it will be even more after Java 9 when probably they will succeed to split the runtime using Jigsaw).

              Originally posted by DanLamb View Post
              citations? I'm skeptical of this.

              Beyond the speed, those kinds of porting layers often add a lot of unwanted complexity to the application development stack. They add extra layers that have be debugged through in the case of problems.
              Here are some citations:
              [1] http://docs.xamarin.com/guides/ios/a...s/compilation/
              [2] http://www.mono-project.com/Mono:Run...mentation:LLVM

              It looks to me that you consider that Mono is an emulator of .Net or something of this sort. Mono has it's own compiler that reads IL, "evaluates it" and generates at the end native code. If the optimizer runs well it should generate fairly good code. Using the default Mono optimizer (named Mini) you will not get highly performant code. But you have either to add an extra flag (-O=all) or change the optimizer (using LLVM, the backend optimizer used into C++ compilers in LLVM world) so you can get fairly good code.

              The memory part as it was told, is just a Java issue, not necessarily a .Net one, just to make clear to you: adding a 1 byte variable that is a stack/value data to a List in C#, should add 1 byte as memory consumption (a List is as both in Java and C# has some capacity that is extended when a threshold is hit, sometimes the addition is zero, sometimes is bigger), but when in Java is 16 bytes: all data in Java is 8 byte rounded and you have the reference associated data + 1 byte itself (+7 bytes for padding). Given this, the extra layers you seem to talk are mostly in Java world.

              A very simple comparison in memory consumption is running for real applications: opening the same project (CodeRefractor) inside:
              - Xamarin Studio 4.2.1 - a SharpDevelop ported to Gtk#: 108 936 K
              - SharpDevelop 4.4 : 87 924 K
              - Visual Studio Express 2013: 175 584K
              In fact SharpDevelop is using WPF/WinForms only, XS is a mix of C controls (GTK#) and C# and Visual Studio is mostly C++ with some C# interoperability.

              Maybe you can explain what you mean with "those kinds of porting layers often add a lot of unwanted complexity". You mean things like WPF? Xml, or things like that? In fact I think is just the opposite: having a framework makes you to not make the same mistake twice. The unwanted complexity is inside every library doing heavy stuff: data binding, xml processing, internationalization. Making it by your own will always make it harder to fix and debug, or maybe I'm missing your point.

              Comment


              • #37
                Later:
                Originally posted by DanLamb View Post
                (...)C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.
                Of course what you're saying and implying is wrong at many levels. It made sense when it was made: it was intended to be the best way to develop Windows applications, but by extension if it was made the best way to develop applications for clients/enterprise, it may work well for different operating systems. Even more, most of the CPUs were weaker than 1 GHz when .Net was made, and today we have in every (smart)phone more MHz (GHz) than the desktops of that time.

                Is C# platform agnostic? It was from the day one: Rotor .Net implementation was working on BigEndinan/PowerPC/OS X, and Micro .Net was running on embedded (albeit on an interpreter). Taking Mono as running on many more platforms: Linux, iOS, Android, NaCl, makes that C# to be even more platform agnostic. In comparison the CIL is more platform agnostic than is JVM: JVM does not run in iOS, on Android the bytecodes are different (albeit are bootstrapped from the original JVM bytecodes).

                The single "major" detail that .Net offers and Mono doesn't are regarding COM related (which is to be expected, yet there is no problem, as CORBA in Java or any similar Java implementations are not JVM agnostic), although you can run .Net remoting with .Net host and Mono client (or vice-versa), and C++/CLI parts which are extensions that are not related with C# in itself.

                F# is a great language, and I don't want to make it any less valuable this part, also Scala (or Kotlin), but I think that every time when Linux loses a platform (like Mono, Adobe AIR), or a runtime it loses: choice, applications and eventually is a reason for people to not run Linux at their home. This is why we need Qt as much as Java as much as Mono. I love OpenRA (try it, is it a fun game), and is my distro will remove Mono, I will have to install other distro.

                Probably you know/noticed: Steam on Windows is .Net based, and no user is complaining on this (and they shouldn't). If they later would use Mono as their Linux client, will you remove all your Steam library because of it?

                Comment


                • #38
                  Originally posted by ciplogic View Post
                  I can say that 1:1 translation from CIL operations to C++ (using smart pointers), makes C++ code to be 16x times slower than .Net (ver 4.5).
                  I believe your point that you _can_ make C++ code that runs poorly. You _can_ make any language or toolset run poorly. That's usually not very meaningful. What's usually relevant is comparing code normally written toolset A vs B or at comparing reasonably optimized code with A vs B.

                  the blog post you linked said gcc was the fastest, then Java, then .NET, and MinGW the slowest... This isn't consistent with your assertion.

                  Originally posted by ciplogic View Post
                  The memory part as it was told, is just a Java issue, not necessarily a .Net one, just to make clear to you: adding a 1 byte variable that is a stack/value data to a List in C#, should add 1 byte as memory consumption (a List is as both in Java and C# has some capacity that is extended when a threshold is hit, sometimes the addition is zero, sometimes is bigger), but when in Java is 16 bytes: all data in Java is 8 byte rounded and you have the reference associated data + 1 byte itself (+7 bytes for padding). Given this, the extra layers you seem to talk are mostly in Java world.
                  For language debates, you can write a large ArrayList<Integer> or ArrayList<Byte> in Java to demonstrate a massive amount of Object boxing memory overhead.

                  Of course, in real life, a Java developer would just use int[] or byte[] instead and there's no boxing overhead and almost zero memory overhead at all. The ArrayList<Byte> example is true in that Java _does_ let you write bad code, and Java really does have a flaw in that it requires boxing overhead with generics for pre Java 1.4 compatibility reasons, but it's dishonest in that that isn't a realistic scenario.

                  Additionally, Scala offers Array[Int] with no boxing overhead and no performance overhead. Additionally, it doesn't even have a separate legacy array syntax with separate casting rules, so it's more elegant in that sense as well.

                  Additionally, even in C#, int[] often outperforms List<int>, so there is still the confusion and complexity there too:
                  http://www.dotnetperls.com/array-memory

                  Originally posted by ciplogic View Post
                  Maybe you can explain what you mean with "those kinds of porting layers often add a lot of unwanted complexity". You mean things like WPF? Xml, or things like that? In fact I think is just the opposite: having a framework makes you to not make the same mistake twice. The unwanted complexity is inside every library doing heavy stuff: data binding, xml processing, internationalization.
                  No, a framework or library is fine.

                  But iOS development and all the tools and libs are really designed in an extremely Apple-centric Objective-C centric world. Using a tool that lets you write in a completely different language with either some type of cross compilation or micro VM adds extra complexity.

                  Comment


                  • #39
                    Originally posted by ciplogic View Post
                    Is C# platform agnostic? It was from the day one: Rotor .Net implementation was working on BigEndinan/PowerPC/OS X, and Micro .Net was running on embedded (albeit on an interpreter). Taking Mono as running on many more platforms: Linux, iOS, Android, NaCl, makes that C# to be even more platform agnostic. In comparison the CIL is more platform agnostic than is JVM: JVM does not run in iOS, on Android the bytecodes are different (albeit are bootstrapped from the original JVM bytecodes).
                    Sure, C# is multi-platform. But it has been designed and influenced almost entirely by Microsoft, which is completely partisan vendor, which does make it less agnostic.

                    Often, C# adds features strictly to accommodate another Microsoft product, for example. The overwhelmingly dominant IDE of choice is completely Windows only. LINQ's database features are mostly MS database specific. C# does run on other platforms, but it's not a vendor agnostic, politically neutral, tool.

                    Java does run on iOS, btw, although I wouldn't advise it.

                    Comment


                    • #40
                      Originally posted by DanLamb View Post
                      I believe your point that you _can_ make C++ code that runs poorly. You _can_ make any language or toolset run poorly. That's usually not very meaningful. What's usually relevant is comparing code normally written toolset A vs B or at comparing reasonably optimized code with A vs B.

                      the blog post you linked said gcc was the fastest, then Java, then .NET, and MinGW the slowest... This isn't consistent with your assertion.
                      So let's clarify: MSIL/CIL describes some operations, like additions, loops, etc. If you translate them one to one into C++ "as is" you will get 16x slowdown. I can recommend to write some code in C#, and use CodeRefractor at level zero of optimizations to see what I mean. Probably it doesn't worth the hassle, but this is what is the statement based on.

                      What you see here when GCC gets better is the code after you get these operations written in an intermediate format, applied optimizations and after that this code is given to a C++ compiler to optimize it more. Just after somewhat advanced optimizations like a lot of propagation optimizations, loop invariant code motion, and escape analysis, you can get that C++ to perform faster than .Net, but even so, you cannot get more than 20-30%. (you can get for specific cases, "happy cases").


                      Originally posted by DanLamb View Post
                      (...) (you describe clearly that is a boxing overhead)

                      Additionally, even in C#, int[] often outperforms List<int>, so there is still the confusion and complexity there too:
                      http://www.dotnetperls.com/array-memory
                      (...)
                      No, a framework or library is fine.

                      But iOS development and all the tools and libs are really designed in an extremely Apple-centric Objective-C centric world. Using a tool that lets you write in a completely different language with either some type of cross compilation or micro VM adds extra complexity.
                      I agree and I know what you mean. First of all let's clarify: this doesn't make a person writing bad code to not have a more code usage. The "round of 8 bytes" of every data set and boxing make Java to consume much more than the dataset you want to represent. C# doesn't need this and this is a good thing.

                      Also, even you state that List<int> is slower than int[], which happens to be true, but is really marginal: the downspeed is in bounds checking and some extra data set to not make useless reaallocations inside the List structure. But in the same time it is not 10x more memory wasteful (like Java) and it doesn't need to have Hotspot to mitigate a lot of casts that are needed because of boxing.

                      In fact I don't know any real benchmark that using List<T> you will get such of a big overhead (compared with array) as is in Java world: both performance wise or Java wise.

                      Originally posted by DanLamb View Post
                      Sure, C# is multi-platform. But it has been designed and influenced almost entirely by Microsoft, which is completely partisan vendor, which does make it less agnostic.

                      Often, C# adds features strictly to accommodate another Microsoft product, for example. The overwhelmingly dominant IDE of choice is completely Windows only. LINQ's database features are mostly MS database specific. C# does run on other platforms, but it's not a vendor agnostic, politically neutral, tool.

                      Java does run on iOS, btw, although I wouldn't advise it.
                      It could be as you say, but it isn't in practice.

                      C++ was probably made for describing business logic, and metaprogramming and was targetted for Unix development. This doesn't make C++ to not be very good for other environments (including Windows).

                      In comparison, C# and Linq/database features are not related. Linq can be used from Boo, VB.Net, or any .Net language with a decent support of lambdas. It could be written in C# (which it is) but it doesn't relate with the fact that Linq (as technology) to be Windows centric. I use Linq day by day, and I don't target Windows or Sql server. Even I do programming on Windows (let's say), Linq can be used against Xmls, collections (arrays, List<T>), etc. which have no relation with the support of C#. Is like COM described earlier: is a .Net feature and the minimal C# support that it has for COM, or for enums to map WinAPI classes, it make it capable to map also C structs from GTK+, I don't see why it couldn't.

                      In fact on the face value, PInvoke was more clean than anything Java dreamed on and it was made cross platform in the first iterations of Mono. There are demos in 2008 taking WinForms applications from Windows and run them in Mono/WinForms on Linux with no code change. This doesn't happen with any Dalvik application which you run them on desktop. Isn't it? Java 7 was announced less than a week ago as supported by Dalvik, when async/await support (VS 2012 feature, VS launched in October 2012) was ready as for start of 2013 in the master branch in Mono. So the "VM differences" as for me hold less water than comparing with Java world, isn't it?

                      Comment


                      • #41
                        Originally posted by ciplogic View Post
                        you can get that C++ to perform faster than .Net, but even so, you cannot get more than 20-30%. (you can get for specific cases, "happy cases").
                        This sounds reasonable.

                        Originally posted by ciplogic View Post
                        I agree and I know what you mean. First of all let's clarify: this doesn't make a person writing bad code to not have a more code usage. The "round of 8 bytes" of every data set and boxing make Java to consume much more than the dataset you want to represent. C# doesn't need this and this is a good thing.
                        ...
                        But in the same time [C#] is not 10x more memory wasteful (like Java)
                        Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.

                        If you load a byte[] in Java or a Array[Byte] in Scala, there is very close to zero overhead. I already agreed that it is a good thing that C# generics works with value types without a boxing overhead. You are just blowing that minor benefit out of proportion. Scala basically gives you the same benefit, where you don't have boxing overhead on somethign like Array[Byte].

                        Originally posted by ciplogic View Post
                        C# and Linq/database features are not related. Linq can be used from Boo, VB.Net, or any .Net language with a decent support of lambdas. It could be written in C# (which it is) but it doesn't relate with the fact that Linq (as technology) to be Windows centric. I use Linq day by day, and I don't target Windows or Sql server. Even I do programming on Windows (let's say), Linq can be used against Xmls, collections (arrays, List<T>), etc. which have no relation with the support of C#.
                        Sure, the in-memory LINQ functionality isn't permanently bound to C# or Microsoft and it could be potentially adopted by other non-Microsoft ecosystems. And if it makes sense to do so, it should adopted, regardless of passed history and politics.

                        However, LINQ isn't an originator and isn't unique in it's functionality. Scala natively provdes the functionality of in-memory LINQ, long before LINQ ever existed, and does it more seamlessly than LINQ where it's not this disjoint syntax separate from the rest of the language. Scala has arguably better technology, it's lacking the trademarked brand name, and Microsoft marketing, and all that, which isn't important to many people.

                        Originally posted by ciplogic View Post
                        C++ was probably made for describing business logic, and metaprogramming and was targetted for Unix development. This doesn't make C++ to not be very good for other environments (including Windows).
                        Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

                        I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":

                        Originally posted by DanLamb View Post
                        Java has this horrific convention of writing getters/setters everywhere because you can't change a variable to a function without breaking source + binary compatability.

                        C# automates this with properties, but in some ways it's even worse. There is no reason C# should have both mostly redundant language constructs of variables/fields and properties. You can have a local variable, but not a local property. You can have an instance variable, but generally you can always replace it with an instance property. "readonly" works on instance/class fields, but not properties and not local variables, and it's different from const. If you want a read only property, that uses a completely separate syntax. Props can be overridden, variables can not. The "var" type inference mechanism works with local variables, but not instance variables or class variables or properties or function return values. What a complete chaotic mess!!

                        Scala has var (read/write) and val (read only) and that's it. Whether you use them as local var/vals, instance var/vals, or singleton var/vals, they work the same and use the same syntax and don't need a myriad of weird rules and legacy syntaxes and keywords. Type inference works in all cases and also works similarly with function return types.

                        null. Scala/F# support null for Java/C# interop, but native Scala/F# otherwise doesn't use null at all. Option is a much better solution than null. C#'s nullable types are a much weaker partial solution, which is why Microsoft's newer F# uses Option.

                        Arrays. C#/Java both started with arrays and added generics as a separate system later. Arrays should use the generics syntax. And they should use the same casting rules. Scala does, Java/C# do not. Java/C# have arrays that can downcast (covariance) which is a mistake that they can't fix for legacy reasons as you can write code that compiles but fails at runtime.

                        I mentioned LINQ. Scala does all the in-memory stuff that LINQ does in the core language where C# has this separate disjoint syntax bolted on.

                        Ternary operator. C/Java/C#/JavaScript use the ternary operator, because they don't have "if" expressions that return a value like Ruby, Scala, or most other modern languages. The ternary operator also doesn't extend cleanly to multiple else if conditions or multi-line expressions like an "if" expression.

                        Partial functions. C had switch/case statements which was carried over into JavaScript/C#/Java. This is similar to a mathematical partial function (a function defined for only some range of inputs like a logarithm function). Scala basically replaces the C-era switch/case with native partial function support.

                        Native support for tuples is extremely useful.

                        Native support for pattern matching is huge. This dove tails with Option btw.

                        Native support for currying. You can approximate it with C#/Java, but it's nice to have native support.

                        Look at Scala's parser combinator library for an example of some useful, practical code that really showcases the conciseness and elegance of Scala in a way that would be far more bulky in Java/C#.
                        Originally posted by ciplogic View Post
                        Java 7 was announced less than a week ago as supported by Dalvik when async/await support (VS 2012 feature, VS launched in October 2012) was ready as for start of 2013 in the master branch in Mono.
                        It's much worse than that. Dalvik doesn't support the major Java 7 enhancements, specificially the NIO.2 library which Google helped write, and Invoke Dynamic byte code. The Android toolset just supports soms superficial petty Java 7 syntax improvements, which is barely better than nothing.

                        The dated Java support is almost surely due to the legal battles with Oracle. I presume Google has been working to phase out Java and replace with something else, and that just hasn't been ready to announce.

                        IMO, there are much better languages than Java: Scala, Haskell, Ocaml, Rust, etc. But worse than Java, is using a completely out of date, legacy version of the language that is incompatabile with much of the more recent developments.

                        I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.

                        The async issue seems to be a tangent. Scala has super nice syntax for dealing with async programming, and I believe that can compile to Dalvik binaries.

                        Comment


                        • #42
                          Originally posted by DanLamb View Post
                          Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.
                          (...)
                          Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

                          I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":
                          (...)
                          I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.
                          You claimed two things here:
                          Originally posted by DanLamb View Post
                          (...)
                          C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.
                          Given this "impartial view", I think is appropriate to give this kind of responses. And the numbers are not given by a Mono enthusiast (like myself), but by Java guys like an expert working on Twitter claims that JVM is huge on memory. Taking it from his slides:
                          - smallest object: 16 bytes
                          - (empty) array of bytes: 24 bytes
                          - class A {
                          byte x;
                          }
                          class B extends A {
                          byte y;
                          }
                          new A(): 24 bytes, new B(): 32 bytes
                          -
                          class C {
                          Object obj = new Object();
                          }
                          new C() = 40 bytes
                          - Guava MapMaker.makeMap() takes 2272 bytes!
                          MapMaker.concurrencyLevel(1).makeMap() - 352 bytes

                          - Corba like Thrift can also be heavy (Thrift is a Twitter project): "It adds between 52 and 72 bytes of overhead per object."

                          So, what remained for me to "prove" are the following:
                          - Mono is not just a poor's man CLR (or .Net). Because performance wise (as was quoted) gives the same optimizations (given you pick LLVM which is not default) as a C++ runtime
                          - C# is not MS centric (it runs just well on Mono and with not impaired functionality)
                          - C# it makes sense on some platforms which are not Windows (like Linux, or iOS or Android) maybe even more than Java. The reason: at the end is created a native binary that is executed so it can run faster than let's say... Java on some devices (like Android and/or iOS). I know about RoboVM which is pre-alpha (like my tool too) and it can compile some Java apps on iOS

                          What about C# vs Scala. I don't know. I cannot comment (too much), because as much as you say, it looks to me that Scala has some ups and downs. Scala looks to me a more OOP that tries to describe as much as possible functional features, when C# added them later (via Linq). Maybe is not a clean syntax, but feature wise on practical side it looks that in some parts C# is clearly superior:
                          - PInvoke and native platform integration working with any OS (also to falsify your statement that C# is not platform agnostic)
                          - dynamic object: you can do dynamic programming. The syntax is worse than Mirah, or IronRuby or IronPython, of course, but you can do it fairly natural and the generated code is fast too.
                          - async/await is more than an actors or task based programming, and is supported on Mono (which is the topic of this article), not because it offers something more (which it does), but because the whole states are written by the compiler. This is why is so good experience running Windows Phones or modern WPF applications

                          Comment


                          • #43
                            ciplogic,

                            You clearly know your material. Your points are backed with evidence. But:

                            - You are passionate about Mono/Xamarin/.NET/C#, which is great, but many of your statements seem highly slanted as a result. I'm biased as well, but I'm trying to be reasonable about it, acknowledge some C#/Mono advantages etc.
                            - Mono's strength is runtime flexibility and integration with non-Windows OSs. The core VM isn't quite as optimized as the official Microsoft one, it runs a little slower. You don't use it to win benchmarks, you use it because you want to use C# on a non-Windows OS. That's not necessarily a "poor man's" tool, but it is what it is. RoboVM occupies a similar spot in the JVM space: people don't use it because it runs server apps faster, they use it to target OSs like iOS that the official Oracle runtime doesn't support.
                            - You may have some points on Java memory. The Java VM, and probably the Microsoft VM, have undergone too many iterations by different super serious team to just waste large amounts of memory for no reason. I can believe JVM made a different set of trade offs. For example, memory alignment generally trades memory efficiency for runtime efficiency and different VM teams optimize for different targets. But when you claim that Java wastes 10x as much memory as .NET, that just is too far outside of reason. Even when you cite Guava memory wastefulness, I have never directly used that particular Guava API, but I suspect that the Guava guys just made different trade offs and optimizations rather than just wrote a horrible product.
                            - You quote Xamarin benchmarks. Those guys are known for making completely deceptive skewed benchmark tests. They aren't a neutral party at all. Almost anyone can cook up some benchmarks and cherry pick results. They are notorious for that.
                            - I believe you are downplaying the major defficiencies of C# as a language. You are too gung ho about the related technologies to see its flaws. I think even many Microsoft people are completely aware that C# is quite dated, which is why they are priming F# for prime time when the mass audience is ready.
                            - Some of the reverse is probably true, I'm not familiar with PInvoke, but I suspect you are right that .NET has advantages in that area. Even I will give the Mono team credit for integrating their toolset into other ecosystems like PlayStation Vita much better than most other toolsets.

                            Comment


                            • #44
                              Originally posted by DanLamb View Post
                              ciplogic,

                              You clearly know your material. Your points are backed with evidence. But:

                              - You are passionate about Mono/Xamarin/.NET/C#, which is great, but many of your statements seem highly slanted as a result. I'm biased as well, but I'm trying to be reasonable about it, acknowledge some C#/Mono advantages etc.
                              - Mono's strength is runtime flexibility and integration with non-Windows OSs. The core VM isn't quite as optimized as the official Microsoft one, it runs a little slower. You don't use it to win benchmarks, you use it because you want to use C# on a non-Windows OS. That's not necessarily a "poor man's" tool, but it is what it is. RoboVM occupies a similar spot in the JVM space: people don't use it because it runs server apps faster, they use it to target OSs like iOS that the official Oracle runtime doesn't support.
                              - You may have some points on Java memory. The Java VM, and probably the Microsoft VM, have undergone too many iterations by different super serious team to just waste large amounts of memory for no reason. I can believe JVM made a different set of trade offs. For example, memory alignment generally trades memory efficiency for runtime efficiency and different VM teams optimize for different targets. But when you claim that Java wastes 10x as much memory as .NET, that just is too far outside of reason. Even when you cite Guava memory wastefulness, I have never directly used that particular Guava API, but I suspect that the Guava guys just made different trade offs and optimizations rather than just wrote a horrible product.
                              - You quote Xamarin benchmarks. Those guys are known for making completely deceptive skewed benchmark tests. They aren't a neutral party at all. Almost anyone can cook up some benchmarks and cherry pick results. They are notorious for that.
                              - I believe you are downplaying the major defficiencies of C# as a language. You are too gung ho about the related technologies to see its flaws. I think even many Microsoft people are completely aware that C# is quite dated, which is why they are priming F# for prime time when the mass audience is ready.
                              - Some of the reverse is probably true, I'm not familiar with PInvoke, but I suspect you are right that .NET has advantages in that area. Even I will give the Mono team credit for integrating their toolset into other ecosystems like PlayStation Vita much better than most other toolsets.
                              I have to start with an apology: certainly Java doesn't use 10x memory, and it was an exageration from my side. Though, I can still say that it uses more memory than a typical other VM implementations. Given this, this quote were intentionally exagerated based on the claims were provided (maybe with no intent to misinform) by you. If they were slanderous, it was not by far any intent but to give just "tit for tat".

                              Also, I want to disclaim some things about myself and the "Xamarin benchmarks". I did contribute to Xamarin products, and in fact just to only one (Xamarin Studio) some patches in code quality (and once I had also reported a bug that MonoDevelop did not open my project, but I didn't contribute anything to fix it), but all benchmarks are written by myself and they are also documented how I did the testing, etc. as my intent of writing CR is an academic endevour and my interst into compilers (too long and too personal to expand it here). The project is simply the tentative (for now successful) to translate CIL (the MSIL / .Net bytecodes) to C++. This is the reason why I know .Net internals (and Java too) as when I did convert for first time I've got more than 8x slowdown in any C++ application and I had to look in various ways to improve it.

                              At last, Java does offer tangible performance speedup in most cases, and in my view: .Net CLR is lightweight (as it maps C/C++ fairly well as semantics, just with a GC in the back) but with GCC -O1 optimizations, Java is an alien runtime (alien != slanderous, simply, it is like Self or SmallTalk or Objective Pascal on that manner, where the wrapping is not done naturally to C/C++) but with optimizations comparing with GCC -O2 (as it uses HotSpot, CHA and partially interpretrs the code). I agree for this reason with you 100%: 8 bytes alignment is for performance and less misaligned cache lines (which is really important to some extend into modern CPUs).

                              C# is not that modern? Probably, I never did a detailed testing. I tried Kotlin (which I heard that is like Scala) and I use JetBrain tools (R#), and I liked more than C#. I would love that Kotlin to work in .Net (it doesn't... )

                              But also to all fairness, the JVM bytecodes are not so well defined as CIL ones: generics are defined at the IL level in CLR world (I think if you said that Scala has "full" reified generics, they have either to make copies in implementation of bytecodes), structs too, and is not just that you make them "generic" but you can define them as parameters, Java is limited as types (and will not be able to add unsigned int in my understanding) because there are no enough bytecode numbers, and even the instructions that do math are for me a bit silly: you push two integers, and after that you have to call instruction "iadd", because you cannot add them anyway with "fadd" (addition of two floats). Java has also limitations that CLR extends them: like a function in Java can have no more than 256 parameters, but in .Net the limit is of 64K (if I recall right), so even you use code generators, you have to look sometimes of the Java generated limits.

                              So maybe the pretiest language is Scala, the fastest (in the runtime performace) is Java, but as for me are not by much. InvokeDynamic and Jigsaw are the single things I've heard in a while that are fascinating in Java world, but these two things are features made in the last 5 years of development. Maybe I wasn't impressed with the "WPF clone" (Java FX) or with their public record (with Oracle suing Google and things of this sort)

                              Comment


                              • #45
                                Originally posted by DanLamb View Post
                                Sure, Java lets you write inefficient code. No language is idiot proof. If you use a totally inappropriate data structure you can get terrible results.
                                I'm not convinced that using objects to store data in an 'object-oriented' language is 'a totally inappropriate data structure'.

                                C++, for example, would likely use no more RAM to store the values as Byte objects that just wrapped a byte value than it would for a byte array (assuming you didn't run into any stupid packing restrictions). Java can't, because of the silly 'every object is a reference' design that requires you to store pointers everywhere.

                                Comment

                                Working...
                                X