Announcement

Collapse
No announcement yet.

Why Mono Is Desirable For Linux

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

  • I was in a similar position to the first reply on this thread:
    This article is so backwards it blows my mind... I started out as a C# developer in the .NET 1.1(if I remember correctly) days. At one point, I realized that Windows was a sinking ship, and decided to learn Linux. Naturally, migrating my C# skills directly to Linux via Mono seemed like the thing to do. WRONG.
    .NET is a memory hog. We were deploying desktop monitoring software on a bunch of school workstations and mid sized dicts/arrays (~3000 elements) would instantly blow up the VM. The application development is so fast (not in a good way) that little to no attention is paid to the optimization of data structures. Everything is an expensively large object, and there's little you can do about this beyond capturing your constructor input and reproducing it when you actually need the data.


    Mono, is, was, and always will be a turd.
    The problem with Mono is, it doesn't really solve any problems, and that goes back to its roots: .NET. Anyone targeting .NET for anything more than a CLI frontend is either a naive startup, a masochist, an incompetent, or otherwise ignorant non-developer. Sure you get faster development, but that comes at a cost, the same cost as any other language where you skip the memory and performance optimization except you CANNOT FIX IT. "From zero lines to complete application in 20 minutes!" We all know where that goes!

    Second, the .NET API was never designed to be a multi-platform vehicle. It was designed specifically for Windows (hell- it wasn't even designed to carry Windows to other architectures, where it would potentially have real utility today), and thus any implementations of it have to map concepts that don't necessarily apply to other operating systems. It's always been designed, since day one, to get the developer hooked-on-Windows(TM) and stuck-on-x86. Anyone here care to dispute how much easier it is to port TO Windows than away from it? I think even the trolls know better!

    I won't even go over ASP.NET... Sure. Keep promising us that the patent trolls will never come, and that even if they come it wont matter. .NET is losing relevance, Windows is losing relevance, Microsoft is losing relevance. Until C# (and its mindshare) detaches itself from Microsoft and gives itself a Constitution / Bill of Rights it will never take off as a multiplatform language in any form.

    After giving up on Mono, I moved to C/C++ and Qt, and discovered that it is a comparable solution to .NET. Eventually I moved more towards writing web code in Python/Django, and desktop apps in Python/PyQT, and whenever I need extreme performance, I just port functionality to C and call it from Python. Vastly superior to C# on Windows or Linux.
    I think (we all) found a better solutions in Python, Ruby, PHP, C++ and multiplatform toolkits like Qt.

    Comment


    • [QUOTE=ciplogic;287439]I did not say by default anything against Qt, it was against the claim: use no Framework! then: Use Qt! (which is a framework)

      I really got tired with gdb, with template errors, with code completion, leaks and so on that do not work.

      C# experience is obviously better, try it! It works similar with a Python one, but it runs faster.

      Linux needs software: because users need software! Python software, C++ software, C# software, Ruby one, FreePascal/Lazarus one, and all others. If you restrict one platform, you reduce your changes to take an user will use /QUOTE]

      1.) ok can be interpreted that way, my bad
      2.) mmm that is typical from anyone that learned C++ in the old times or have too much time useing to high level language[not offending just saying is a common phenomenom], using modern techniques like pointer list is really rare to have memory leaks or null pointers, int he case of templates is common from C ppl that are used to massively long code chunks and very complex types[ struct inside an struct inside another struct that take structs as items which are nested struct] in C++ [any OOL] the smaller the better and the closer to the real types the better and in the case of high level language [it happens me sometime when i spent too much on python for example] is that you get sloppy with your classes cuz forgot C++ don't have garbage collector[take some sigsegv to come back to reality jajaja]
      3.) i did try it and never liked it and i don't considere it a good place to waste to time first cuz i don't like C# syntax that much and is a second class citizen compared to his big brother, miss multiplataform capabilities[sparc ARM power systems], in low power devices behave erraticaly for my needs, not easy to integrate in the web side of things[compared to php/python/perl] and i hate the garbage collector. For linux i trully believe a better solution would be python over LLVM, since python has a massive collection of API/bindings and massively tested and used from scripting to web services[same as perl <-- another good candidate].

      im not saying Mono should not be used since i can understand that if you already have a .NET app is easier to use just mono and get on with it and i don't discuss it can even be faster than in windows[i doubt it but feel free to prove me wrong], what im saying mono has no future as linux enviroment since is an alien enviroment born in windows when we have AAA+ tools like python and perl that just could use some pimp at VM level [llvm]to be as fast or faster than mono minimzing or killing any existant need for mono beyond a .NET runtime that run on linux.
      4.) very controversial since linux don't need 1 billion pieces of software in every fast food language out there like .NET, what we need is an standard project using common set of tools[c++,qt/gtk,pyhton for scripting comobo for example] and ppl in 10 different project that do the same crap to get togheter and make a damn good one, for example but well this is one of those topics where no one is right cuz depend too much of everyone POV

      Comment


      • Originally posted by ciplogic View Post
        use no Framework! then: Use Qt! (which is a framework)
        Bullshit.
        I never claimed that.

        I said do not rely on ONE framework ONLY as then you will be screwed if it goes away.

        Comment


        • Originally posted by jrch2k8 View Post
          3.) i did try it and never liked it and i don't considere it a good place to waste to time first cuz i don't like C# syntax that much and is a second class citizen compared to his big brother, miss multiplataform capabilities[sparc ARM power systems], in low power devices behave erraticaly for my needs, not easy to integrate in the web side of things[compared to php/python/perl] and i hate the garbage collector. For linux i trully believe a better solution would be python over LLVM, since python has a massive collection of API/bindings and massively tested and used from scripting to web services[same as perl <-- another good candidate].

          im not saying Mono should not be used since i can understand that if you already have a .NET app is easier to use just mono and get on with it and i don't discuss it can even be faster than in windows[i doubt it but feel free to prove me wrong], what im saying mono has no future as linux enviroment since is an alien enviroment born in windows when we have AAA+ tools like python and perl that just could use some pimp at VM level [llvm]to be as fast or faster than mono minimzing or killing any existant need for mono beyond a .NET runtime that run on linux.
          4.) very controversial since linux don't need 1 billion pieces of software in every fast food language out there like .NET, what we need is an standard project using common set of tools[c++,qt/gtk,pyhton for scripting comobo for example] and ppl in 10 different project that do the same crap to get togheter and make a damn good one, for example but well this is one of those topics where no one is right cuz depend too much of everyone POV
          As for point 1 we both agree, and as point 2 is related with my life experience with C++, of course I agree that some people had another, where in a real project, people were more conscious, and leaks or a better environment to develop in.
          As my preference of C# maybe went in the time that C++ was for me a disappointment, going to your point 3, I can agree that C++ has some things that are better than in C#. The idea that templates are fully state machines so they really can compile formulae at compile time. I know that C# cannot do that. In this way is much powerful than generics. Also some symbols can be solved at linktime, so you can find some symbols "magically" as they are compiled for example as resources in a more transparent way than C# way. As resources, I don't only mean files, but also some code that you can run at startup, without being invoked lazily (the .Net behavior differs for this reason on singleton instantiation).
          At the end, why is an alien to Linux platform? I found that Mono in itself is a bit slower on math computations than .Net (by a little, if you don't use LLVM), but it integrates nicely with Gtk# (2.xx for now). I mean is better than for example GJS integration, or Python integration. Let me elaborate: if you call any method in Cairo, or OpenGL, if is mapped to a C type, most likely there is no copying or boxing/unboxing of the methods, so the performance penalty is certainly much smaller than any other mainstream language you can develop in Gnome (I include here: Python, Java, Ruby, JavaScript), isn't it?
          Point 4 I think makes no sense. If we would remove Mono and C#/VB.Net and some other .Net language supported (like my preference for Boo), there would still remain a lot of paradigms that are accessible in Linux. Emacs and Gimp use Lisp for 2 decades (at least), Haskell, Java languages (like Clojure or Scala), some research languages, Tex, all GCC ones (Go is the new kid in the block).
          Even C++ is multiparadigm, but if you work with Qt, you will likely work with the extension of Qt (signals+slots), JavaScript, QML, if you integrate QWebKit you will need to know Javascript, CSS, HTML5, maybe WebGL, and so forth, to not say anything about DDL/SQL.
          Languages will always appear, and what matters (in my opinion) is the mature implementation that a developer can target. As for me MonoDevelop offers some of the tooling (for Mono world), and also the closest sibling had virtually no traction (Java + Gtk) in Gnome desktop.
          There are languages which are really close(r) in Linux world: Ruby and Python, both in paradigms and in power (excluding that Ruby is slower ) but I do find that there is no need to remove one of them to "consolidate" Linux's web development platform.
          Python with LLVM better than Mono? Performance wise? Or at which level? Mono also have huge libraries, even you fully exclude the "Windows.Forms" support. From the REPL evaluator, that makes it close to Python (in dynamic ways), Xml processing, database processing, network, remote access, reflection etc. You can really find libraries for almost everything. Like in Python (or Ruby GEMs for that matter). What you can do in Mono is that you can write all your code using "dynamic" keyword, and if you need a higher performance you can put here and there some type annotations, and you bring performance in much closer terms with C/C++.

          Comment


          • Originally posted by n3wu53r View Post
            Bullshit.
            I never claimed that.

            I said do not rely on ONE framework ONLY as then you will be screwed if it goes away.
            Let's reclaim your quote, shall we?
            Good for you! Ignore all the bullshit here. This is common on phoronix.
            But don't only develop on Mono. It is never good to rely on one language/framework.
            It logically follows that Mono is the one language/platforms, isn't it? If not, you should put at least in a separate paragraph, isn't so?
            If your behind logic is that you're screwed if the one platform goes away, I can say to you at least 4 projects having various levels of supporting the CLR virtual machine (all are here):
            - Microsoft
            - Mono
            - DotGNU
            - VMKit, a project of LLVM
            So, in case a nuclear bomb hit Redmond (never hope it happens) and because of that they attack with patents and kill Xamarin as a bussiness, there will be two half-baked implementations of CLR/.Net
            In balance, let's take Qt, how many vendors support it?
            - it was Nokia
            - it is Digia now
            What if Digia discontinue Qt, how many alternative Qt implementations do you have?
            Based on raw numbers, I will pick Mono and .Net over Qt, seems much more safer, isn't so?
            Edit: Some clarification: I mean that you can develop more safer if are more implementations. And as Mono is supported itself in more platforms, if a platform is blocked (for example Android, or Mono itself, you will not lose all your code tomorrow), you have just likely to rewrite UI code. If Mono will be stuck, you still will have the some code alive. Qt offers even less warranties, excluding you target Nokia's Symbian or Meego, I don't see any other target where Qt keeps you safe(r) to sleep than Mono and his support as .Net. And eventually DotGNU and VMKit will still give a chance to use your code even if both Microsoft and Xamarin would disappear (if it would be still some interest in C# in 20 years from now)
            Last edited by ciplogic; 09-17-2012, 08:58 PM.

            Comment


            • Originally posted by ciplogic View Post
              It logically follows that Mono is the one language/platforms, isn't it? If not, you should put at least in a separate paragraph, isn't so?
              If your behind logic is that you're screwed if the one platform goes away, I can say to you at least 4 projects having various levels of supporting the CLR virtual machine (all are here):
              - Microsoft
              - Mono
              - DotGNU
              - VMKit, a project of LLVM
              So, in case a nuclear bomb hit Redmond (never hope it happens) and because of that they attack with patents and kill Xamarin as a bussiness, there will be two half-baked implementations of CLR/.Net
              In balance, let's take Qt, how many vendors support it?
              - it was Nokia
              - it is Digia now
              What if Digia discontinue Qt, how many alternative Qt implementations do you have?
              Based on raw numbers, I will pick Mono and .Net over Qt, seems much more safer, isn't so?
              No.

              But don't only develop on Mono. It is never good to rely on one language/framework.
              Look at the bold. I said not ONLY Mono. Meaning you should know other things. If the word Only was not there, you would be right.
              I said one language/framework, that does not refer to mono. If I said a instead of one you would have a point. Even if I said a that doesn't really refer to mono, but then the sentence would refer to all languages/framework.
              But perhaps, I should have been more clear.

              Now the other points.

              If a nuke hit redmond and every MS office, machines running .NET would be safe, just as machines running windows. It won't magically stop working. However it has no future. It doesn't matter that there are open source implementations. Other then MS, mono is the only practical one and there the issue arises:
              The work of hundreds of paid employees will not be at Xamarin. Many parts of MS .NET will never be included in Mono since they don't make sense and the developers have no intention of porting it.
              Mono would keep .NET alive if MS vanished, it would be much, much worse if .NET vanished and mono did not exist either. But it still is not better then Qt in this scenario.

              Why Qt has a very solid future:
              First Digia is not the only vendor. There are companies build around Qt like ICS, and KDAB. There are vendors besides Digia.

              Digia will never kill off Qt. It's a really huge product for them. Digia would have to go bankrupt, or sell of Qt. They won't discontinue. So many bigs companies are invested in and use Qt. There are legal obligations Digia must fulfill.

              Qt is open source while .NET isn't. Mono must reverse engineer Microsoft's .NET, the official implementation. While Qt's official implementation is open source and high documented.

              Why would Qt have an alternative implementation? Qt isn't a language. It's like reimplementing a library. No damn point.

              Another reason Qt has a good future: KDE.

              KDE has a legal agreement that Qt must remain open source and that there must be a major release at least once a year, or else KDE gains access to a BSD licensed version of Qt.

              Qt is open source, has other vendors, well documented, is TRULY cross platform, and has many multinational billion dollar companies invested in it.
              Qt has more platforms (except in mobile, they are only now adding iOS and android support).
              Qt works on Windows, Mac, Linux, BSD (unofficial?), QNX, VxWorks, embedded linux, and Windows CE. I think it works on some Unix flavors too.

              In relaity, both Qt and .NET have a very solid future ahead.
              Last edited by n3wu53r; 09-17-2012, 09:22 PM.

              Comment


              • Originally posted by jrch2k8 View Post
                miss multiplataform capabilities[sparc ARM power systems]
                Wait, what?

                http://ftp.de.debian.org/debian/pool....1-6_armel.deb
                http://ftp.de.debian.org/debian/pool....1-6_sparc.deb

                Comment


                • Just because a program is packaged by Debian doesn't mean it works properly.

                  Comment


                  • Originally posted by yogi_berra View Post
                    Just because a program is packaged by Debian doesn't mean it works properly.
                    Code:
                    (sid)directhex@smetana:~$ mono --version
                    Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-6)
                    Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
                    	TLS:           __thread
                    	SIGSEGV:       normal
                    	Notifications: epoll
                    	Architecture:  sparc
                    	Disabled:      none
                    	Misc:          
                    	GC:            Included Boehm (with typed GC and Parallel Mark)

                    Code:
                    directhex@abel:~/mono-2.10.8.1$ mono/mini/mono --version
                    Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-3)
                    Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
                    	TLS:           __thread
                    	SIGSEGV:       normal
                    	Notifications: epoll
                    	Architecture:  armel,soft-float
                    	Disabled:      none
                    	Misc:          softdebug 
                    	LLVM:          supported, not enabled.
                    	GC:            Included Boehm (with typed GC and Parallel Mark)
                    Wait, what? Can you show me the bugs relating to these architectures on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mono ?

                    Comment


                    • Originally posted by ciplogic View Post
                      I don't see any other target where Qt keeps you safe(r) to sleep than Mono and his support as .Net. And eventually DotGNU and VMKit will still give a chance to use your code even if both Microsoft and Xamarin would disappear (if it would be still some interest in C# in 20 years from now)
                      Enough claims. Facts:
                      • C++ / Qt work, NOW, on all platforms
                      • C# / Mono does not fully work, has caveats and bugs
                      • C++ / Qt are both very mature technologies and are proven for general purpose application development
                      • C# / Mono is not
                      • C++ / Qt are very resource friendly
                      • C# / Mono is not
                      • C++ has had massive mindshare and support for well over 20 years now
                      • C# doesn't have even close to the level of support C++ does, to this day.

                      Therefore:
                      There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.

                      Comment


                      • Originally posted by kazetsukai View Post
                        Enough claims. Facts:
                        • C++ / Qt work, NOW, on all platforms
                        • C# / Mono does not fully work, has caveats and bugs
                        Qt has better support across Linux architectures than Mono, e.g. support for HP-PA.

                        C# and Mono are better supported on mobile - Mono for Android, MonoTouch, and WP7 cover more than 90% of the US smartphone OS market. Comparatively, Qt is in "experimental pre-alpha" stage for iOS and Android and not an option for WP7. Symbian & Blackberry support in Qt accounts for less than 7% of the US smartphone OS market.

                        Support for Windows and Mac is comparable across both. Support for Linux on major architectures is equivalent across both.
                        • C++ / Qt are both very mature technologies and are proven for general purpose application development
                        • C# / Mono is not
                        Qt is about twice the age of Mono - 1992 versus 2002. In most circles, the word "mature" could be used here.

                        As for proven, again, mobile has pointed towards Mono rather than Qt. It's a more flexible choice for embedding scenarios, e.g. gluing into game engines. On the desktop Qt is far more popular, due in no small part to KDE and to the mature tools for Windows use. EA are an example of a Qt user, for their Origin client on Windows. EA are also an example of a Mono user, for The Sims 3 on Windows, Mac, 360 and PS3.
                        • C++ / Qt are very resource friendly
                        • C# / Mono is not
                        There's really very little in it between Qt and Mono for most resources. Qt may be faster for CPU usage, but that's not really something one encounters in user-interactive applications.
                        • C++ has had massive mindshare and support for well over 20 years now
                        • C# doesn't have even close to the level of support C++ does, to this day.
                        They're useful for different scenarios. Mono doesn't replace C++. And interop between the two is of major importance to users.

                        As for the Linux desktop, VERY ANGRY NERDS TYPING IN BOLD AND CAPS have been very effective at scaring users away from Mono, and keeping developers on Windows.

                        Therefore:
                        There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.
                        There are lots of legitimate reasons to choose Mono/C# over C++ and Qt. But because they're not the uses you care about, you project into all cases and say and say "never". This is silly. There are times Qt with C++ is the right choice, times with Mono with C# is the right choice, and times when some combination thereof is the right choice.

                        Comment


                        • Originally posted by kazetsukai View Post
                          Enough claims. Facts:
                          • C++ / Qt work, NOW, on all platforms
                          • C# / Mono does not fully work, has caveats and bugs
                          • C++ / Qt are both very mature technologies and are proven for general purpose application development
                          • C# / Mono is not
                          • C++ / Qt are very resource friendly
                          • C# / Mono is not
                          • C++ has had massive mindshare and support for well over 20 years now
                          • C# doesn't have even close to the level of support C++ does, to this day.

                          Therefore:
                          There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.
                          [*]C++ / Qt work, NOW, on all platforms
                          Excluding Android, iOS, Windows Phone 7 (and 8)
                          Does it have bugs?
                          https://bugreports.qt-project.org/se...avigator.jspa?
                          I just filtered bugs that are: priority greater than normal, open, and Qt
                          On the head of the list I have:
                          " Displaying issues 1 to 50 of 1235 matching issues. "

                          [*]C# / Mono does not fully work, has caveats and bugs
                          The Mono's equivalent is: " 126 bugs found.", this is without filtering by priority (based on Xamarin's Mono Runtime bug tracker)

                          [*]C++ / Qt are both very mature technologies and are proven for general purpose application development[*]C# / Mono is not
                          If you take CLang as a very mature C++ technology, may you elaborate? Mono's C# compiler is at least 5 years older by any measure. QML is proven and C#/Linq is not?
                          Proven technologies that I know that they work in Mono (and .Net) that have no equivalent in C++/Qt:
                          - faster than signal/slot performance, by at least an order or magnitude
                          - no need to automatically reference counting, and using reference memory does not require a hit in performance
                          - garbage collector (you can do it with JavaScript in QML, but not properly in Qt itself)
                          - I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)
                          - no Linq, Tulip is much more limited
                          - string manipulation class QString is a mess, at least compared with C#'s string

                          [*]C++ / Qt are very resource friendly[*]C# / Mono is not

                          Events driven code (with signals/slots) is faster in C#. If you dream that Qt is so lean, try search these words in Google box: "Amarok mem" and the proposal is "Amarok memory hog". If you try the same experiment with "Monodevelop memory" it will suggest: "MonoDevelop memory profiler", for Banshee: "banshee memory leak" (which is a much better wording that most people will define for their software). Do you have any hard numbers to point to? Or is just slander?

                          [*]C++ has had massive mindshare and support for well over 20 years now[*]C# doesn't have even close to the level of support C++ does, to this day.

                          Eventually a thing I think you are right: TIOBE index states: (source)
                          4 3 C++ 9.147% +0.30% A
                          5 4 C# 6.596% -0.22% A

                          Do you see, 9.2% in usage compared with 6.5 % usage.
                          Don't forget anyway that you can use C (19.2%) , Java (16.5%) or Objective C (9.7%), all three are more popular as both. ObjectiveC is similar as age with C++ (yet a bit younger), C is certainly older, and is crucial to write in kernel or in GCC codebase, and of course with Gtk, and ObjectiveC is critical for iOS development.
                          And if you decide to use C, for not critical performance code, if you need to write fast an UI, I recommend to you to use C#/Gtk#.
                          Last edited by ciplogic; 09-18-2012, 11:52 AM.

                          Comment


                          • LLVM Jit infrastructure only is supported in and quoting "A Just-In-Time (JIT) code generation system, which currently supports X86, X86-64, PowerPC and PowerPC-64." which should slows down mono runtime enough to consider Java or python for example.

                            additionally LLVM seems to be able to run on sparc/mips but not as a first class citizen[make sense since sparc is very oracle this days], googling seem llvm is a major headache to compile in some of this plataforms, especially in solaris/niagara2 combo.

                            note that when i say not supported doesn't mean don't work, it just means can't do anything serious until later point in time or toy for have fun but no to work.

                            Comment


                            • Originally posted by jrch2k8 View Post
                              LLVM Jit infrastructure only is supported in and quoting "A Just-In-Time (JIT) code generation system, which currently supports X86, X86-64, PowerPC and PowerPC-64." which should slows down mono runtime enough to consider Java or python for example.
                              Er, no. Mono's standard JITter and GC are still a hundred time faster than Python. Mono's LLVM support is still very early days, and is certainly not shipped in any distributions that I'm aware of.

                              Default Mono practice is to use the supplied JITter (not LLVM), and the default garbage collector (still Boehm). Mono's runtime has some support for Alpha, AMD64, ARM, HP-PA, Itanium, MIPS, PowerPC, s390, SPARC, and i386. Some of these may be bitrotted (e.g. we don't ship 31-bit s390 builds in Debian, only 64-bit).
                              Last edited by directhex; 09-18-2012, 11:58 AM.

                              Comment


                              • Originally posted by ciplogic View Post
                                [*]C++ / Qt work, NOW, on all platforms
                                Excluding Android, iOS, Windows Phone 7 (and 8)
                                Does it have bugs?
                                https://bugreports.qt-project.org/se...avigator.jspa?
                                I just filtered bugs that are: priority greater than normal, open, and Qt
                                On the head of the list I have:
                                " Displaying issues 1 to 50 of 1235 matching issues. "

                                [*]C# / Mono does not fully work, has caveats and bugs
                                The Mono's equivalent is: " 126 bugs found.", this is without filtering by priority

                                [*]C++ / Qt are both very mature technologies and are proven for general purpose application development[*]C# / Mono is not
                                If you take CLang as a very mature C++ technology, may you elaborate? Mono's C# compiler is at least 5 years older by any measure. QML is proven and C#/Linq is not?
                                Proven technologies that I know that they work in Mono (and .Net) that have no equivalent in C++/Qt:
                                - faster than signal/slot performance, by at least an order or magnitude
                                - no need to automatically reference counting, and using reference memory does not require a hit in performance
                                - garbage collector (you can do it with JavaScript in QML, but not properly in Qt itself)
                                - I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)
                                - no Linq, Tulip is much more limited
                                - string manipulation class QString is a mess, at least compared with C#'s string

                                [*]C++ / Qt are very resource friendly[*]C# / Mono is not

                                Events driven code (with signals/slots) is faster in C#. If you dream that Qt is so lean, try search these words in Google box: "Amarok mem" and the proposal is "Amarok memory hog". If you try the same experiment with "Monodevelop memory" it will suggest: "MonoDevelop memory profiler", for Banshee: "banshee memory leak" (which is a much better wording that most people will define for their software). Do you have any hard numbers to point to? Or is just slander?

                                [*]C++ has had massive mindshare and support for well over 20 years now[*]C# doesn't have even close to the level of support C++ does, to this day.

                                Eventually a thing I think you are right: TIOBE index states: (source)
                                4 3 C++ 9.147% +0.30% A
                                5 4 C# 6.596% -0.22% A

                                Do you see, 9.2% in usage compared with 6.5 % usage.
                                Don't forget anyway that you can use C (19.2%) , Java (16.5%) or Objective C (9.7%), all three are more popular as both. ObjectiveC is similar as age with C++ (yet a bit younger), C is certainly older, and is crucial to write in kernel or in GCC codebase, and of course with Gtk, and ObjectiveC is critical for iOS development.
                                And if you decide to use C, for not critical performance code, if you need to write fast an UI, I recommend to you to use C#/Gtk#.
                                1.) well that is true mono "support" more mobile devices but there is a valid reason for it, but for example mono runtime is not in google play store neither is supported for google, ios seem to be in better position but still not supported by apple in any way.i don't mean is bad for small developer studio or independants but for big studios john doe CEO is a big fat no way in hell, like they reject using ngix instead of apache for example.On the other hand qt5 was meant to be the next big mobile thing[meego/symbian combo] but our friend elop killed nokia forcing Digia/community to rethink the strategy and one thing Digia seem to understand properly is that you need to do this in a way that you can get support and acceptance from the vendors, so john doe CEO feels it doing a good investment, and so far they have made nice steps with vxworks[big fat market of industrial RT devices] and QNX[blackberry if survive tho], from the code quality POV Qt support android/ios not that far behind but is not enterprise grade ready yet.

                                2.) check bugzilla is uterlly useless and i no way represents the quality of the code and since Qt4 is much widely used and supported is ovbious the list will be bigger, you have reports in there from guys don't like the qt logo up to plasma active automated core dumps from arm systems passing all the way to ppl whining for clang support in freebsd 10 git. ofc both systems [mono/qt] have bugs that is a no brainer.

                                3.) don't get why you bring clang but Qt support clang/ICC/gcc/sun studio/portland group/ekopath/AIX compiler and many others depending the OS/cpu arch check the mkspec directory
                                4.)signal/slot is not part of any C++ ISO specification and if you used Qt like ever you will know is just a meta object that get translated to bare C++ code at compilation time, would be interesting how you measure performance impact here and as far as i know is irrelevant since you signal/slots can be maybe 1% of you total codebase[unless we are talking about some serious crappy coding]
                                5.) "no need to automatically reference counting, and using reference memory does not require a hit in performance" this is basically what a garbage collector do ... and it does hit performance a lot and require lot of memory to do so, you just don't see it cuz the GC run as another process[in some OSes hidden]
                                6.) C++ is a compiled low level language and it doesnt require a garbage collector neither is part of the ISO spec but if you know the basics keep memory in check is pretty easy and QML is not a JS VM nor is you firefox/chrome JS rendered. QML get translated to C++ code directly[JS syntax is just used to make thing easier for designers] and use the internal render API of the running OS especially in Qt5 lighthouse aka aero/gdi/cocoa/X11/opengl/openvg/egl/etc
                                7.)"- I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)" QtScript and QML and C++[bit harder]
                                8.) mmm tulip maybe maybe not depends on what you wanna do, for me works just peachy but maybe you need something i don't use
                                9.) well i particularly find QString quite powerful and easy to use, maybe a more specific example?? string manipulation is quite an extensive issue
                                10.) this is actually a classic newbie problem with linux, i mean linux try to use as much memory as is possible to cache/preload stuff preemptively and secondly you have process memory and virtual memory which can be confusing, in the case of amarok which is an KDE application need to load in memory all it dependencies[kdelibs/qt/libvisual/gstreamer/etc] so if you use gnome amarok will show a massive memory usage cuz gnome preload his libraries and dependencies[gtk/gfk/bonobo/atk/etc] not the ones from kde but if you use KDE you will see amarok actually is quite memory efficient because all those dependencies are common to any KDE application. this phenomenon occurs because unlike windows or OS X in linux don't have an unique desktop/framework[note windows do this too but hidden that is why office opens so fast is all preloaded]. so you should compare banshee and amarok running in their native enviroments and in the case of mono reading the memory of the process tree not the application. this same concept have flooded nvnews[<-- nvidia] forum for years with "OMG X11 uses 500MB of memory driver bug driver bug".
                                11.) C/C++/obj C are the same family of language with certain variation of concepts but normally you can mix the 3 of them transparently and the syntax is quite common too[since both started from C] and C/C++/objC are used by 90% of the most badass developers in the world and are the supporters of modern computing from kernels to mono/.NET innards and are used to solve in the most efficiently possible way the most complex task in the world. like i always ofc for pops and moms fast consumption facebook client is overkill[C#/python/java/etc are more appropiate for this tasks]
                                12.)"C# doesn't have even close to the level of support C++ does, to this day" this one is true but is more complex than you think, remember C and variants runs the world literally from microcontrollers in every industry in the planet to the most massive supercomputers/clusters going all the way to experimental neuronal networks without let slip the most efficient databases systems know to man and you favorite OS too and is massively supported by every major technological company in the planet[IBM/cray/oracle/microsoft/apple/HP/etc.], so you have very nasty set of proven tools commercially/open at you disposal and support in any way you like it, C# is still too young and is officially supported on 1 plataform only[windows][mono is very niche still] and is mostly used as the next generation visual basic fast food language and is too resources expensive to run outside the "PC"/highend smartphone realm nor is well received as parallel language either or properly supported in super computers/clusters since is still too young.

                                like i said the problem with mono is not that is bad or anything like it, is a decent high level language good for high level language needs, the problem is that in linux we have already good high level languages that just need to improve performance[python over llvm is FAST but is still out of tree sadly] that wont require any rewrite at all unlike migrate to C# and C# beside being easier to learn/code don't provide any sort of improvement that justifies rewrite the other 96% of the regular distro code that is already in C/C++/objC/ASM. so is kinda stuck in a limbo or a very niche position at best. another factor is that your regular linux developer dont like "assemblies hidden functionality" too much, we preffer hard visible linking and bindings[if you investigate you will notice this pattern over and over again in every high level language that is born in linux]. so mono has ended as being the wine for .NET code[and literally with wine] nothing else and since most distros don't even include mono or just have very old unmaintained versions didn't help the cause either but again the problem is mono just don't fit in linux as concept [and microsoft backing doesn't help nor microsoft care as long mono work as shield for EU sues and reduce taxes]

                                Comment

                                Working...
                                X