C# is going to be even more awesome



  • TL;DR:

    • PATTERN MATCHING!!!
    • TUPLE SYNTAX!!!
    • (kinda) NON-NULLABLE REFERENCES!!!

    by a total coincidence, those are exactly the three features that made me love Rust



  • Looks nice.



  • I'm kind of wary of them adding even more features.

    The language is already feeling kind of bloated as it is. They really need to do like a "big cleanup" version and remove some of the cruft.



  • But, backwards compatibility! :scream:



  • I'm sooooo drooling for non-nullable references, that's going to solve SO many problems in our codebase.



  • Didn't. NET have code contracts or something like that that pretty much provided the functionality?

    Other than that - pattern matching looks like syntactic arsenic on a switch/case? Appreciate sorting out tuples, though, that thing was messy and it was almost universally better to write a wrapper struct.



  • @Maciejasjmj said:

    Didn't. NET have code contracts or something like that that pretty much provided the functionality?

    Not that I'm aware of.



  • @Maciejasjmj said:

    Other than that - pattern matching looks like syntactic arsenic on a switch/case?

    Pretty much - but if they do it the way I hope they'll do it, you'll be able to check for properties (and their properties), using not just exact values but also ranges (I doubt they'll implement the last one in first revision, but I can have dreams!). Also, the snippet in article shows matching the type of object under reference, which you could combine with matching for values in the same statement. Moreover, pattern matching works great with tuples.



  • @Gaska said:

    (kinda) NON-NULLABLE REFERENCES!!!

    Cool, C# is now closer to feature parity with C++! :trollface:



  • One step closer. 1386 pages of specification left.



  • @Gaska said:

    One step closer. 1386 pages of specification left.

    I found it amusing a few years ago when people were complaining about not being able to have default method parameters in C#, and Lippert or somebody was explaining why it was complicated and/or rife with potential problems, and yet we have them now.



  • @Groaner said:

    I found it amusing a few years ago when people were complaining about not being able to have default method parameters in C#, and Lippert or somebody was explaining why it was complicated and/or rife with potential problems, and yet we have them now.

    Shit that you haven't figured out how to implement yet is always going to estimate as more complex and problematic than shit you have figured out.



  • Non-trivial features are non-trivial?

    Where's my :trolleybus: :badger: at?



  • C# steals a few more Nemerle features, eh? Who knows, maybe if C# finally develops a decent macro system I might even switch back...



  • @tar said:

    Shit that you haven't figured out how to implement yet is always going to estimate as more complex and problematic than shit you have figured out.

    This is true, but one would think that allowing methods to have optional parameters with default values would have come a lot sooner than C# 4 (eight years after 1.0). I mean, how long have we been able to do that in C/C++?



  • @Groaner said:

    than C# 4 (eight years after 1.0). I mean, how long have we been able to do that in C/C++?

    C++ has had it for a long time. Then again, the C++ mentality has always been: let's throw every conceivable syntax into the next standard, and let the interactions fight it out in the real world. I suppose I should mention the whole method overloading vs overriding saga, it seems apposite.



  • @Gaska said:

    by a total coincidence, those are exactly the three features that made me love Rust

    Maybe they are taking the good features from other languages.

    In which case: good fucking job. Taking all the good features from everyone is the only way to make a good program.



  • Elighten me
    why this

    // Moving a shape using pattern matching
    void move (Shape s) {
      match (s) {
        (Rectangle r) => // Move rectangle
        (Circle c) => // Move circle
        default => // Handle default or throw
      }
    }
    

    is better than this?

    // Moving a shape using pattern matching
    void move (Rectangle r) {
        // Move rectangle
    }
    void move (Circle c) {
        // Move circle
    }
    

  • area_deu

    Because Haskell.

    @antiquarian



  • My preference would be:

    void move (Shape s)
    {
         // POLYMORPHISM, BITCHES!     
         s.move();
    }
    


  • @Gaska said:

    PATTERN MATCHING!!!

    You mean the feature Cool has?

    @Gaska said:

    TUPLE SYNTAX!!!

    You mean how Go does return values without needing tuple types?

    @Gaska said:

    (kinda) NON-NULLABLE REFERENCES!!!

    You mean like what BIT has?



  • You need pattern matching in Cool because x == y statically compiles to x.equals(y), so x == null will either return false, crash with a "dispatch to null" error, or you've done something wrong in your == method.

    def is_null(x : Any) : Boolean = x match {
    case null => true
    case x : Any => false
    };
    


  • @Groaner said:

    Cool, C# is now closer to feature parity with C++!

    The biggest feature of C# is not being able to code in it like it's 1985.

    I'm tiring of running into C++ codebase that is still using native arrays instead of lists, and using malloc to make those arrays, and then calculating the size and memsetting it to 0.

    And the worst part. People copy pasting that code into new applications because that's faster and we don't have enough time to do it right because we keep estimating tasks...

    Waiting for agile to be used right, and not just a productivity boost.



  • @xaade said:

    I'm tiring of running into C++ codebase that is still using native arrays instead of lists, and using malloc to make those arrays, and then calculating the size and memsetting it to 0.

    I see you've never used Go. The "zero value" of a type is a block of memory N bytes long that contains only zero bits. And it's a useful value for every type in the language and standard library. Also we have arrays for when you know the size at compile time (such as for a random number generator's state) and slices for when you don't (such as for the buffer you give to a file for it to read into). And you can turn a pointer to an array into a slice. And slices can be sliced. And you can take pointers to local variables and it actually works and doesn't fuck up memory safety like if you had done the same thing in C++.



  • how much is Go used for practical and business applications?



  • Ever hear of Docker? This server is running on it. It's written in Go.

    Dropbox, CloudFlare, SoundCloud, and of course, Google, use it too.



  • @xaade said:

    The biggest feature of C# is not being able to code in it like it's 1985.

    This.



  • @anonymous234 said:

    Taking all the good features from everyone is the only way to make a good program.

    Good artists copy, great artists steal.
    —Pablo Picasso



  • @xaade said:

    The biggest feature of C# is not being able to code in it like it's 1985.

    ITYM "being able to code like it's not 1985." Because, seriously, you can write FORTRAN in any language.



  • @ben_lubar said:

    You mean the feature Cool has?

    Yes, but done right.

    @ben_lubar said:

    You mean how Go does return values without needing tuple types?

    Yes, but with actual tuple types when you need them (say, if you want to store tuples in a container).

    @ben_lubar said:

    You mean like what BIT has?

    Yes, but with a dozen orders of magnitude less space requirements.

    BTW, it sucks for you that every language you use has only one great feature.

    @ben_lubar said:

    Ever hear of Docker?

    Only in rants about how fucked up it is.


  • Discourse touched me in a no-no place

    move :: Shape -> IO ()
    move (Rectangle _) = stuff
    move (Circle _) = other stuff
    move _ = default stuff
    

    The compiler will, of course bitch COMPLAIN at you if you miss a case.



  • @Jarry said:

    Elighten me
    why this

    // Moving a shape using pattern matching
    void move (Shape s) {
      match (s) {
        (Rectangle r) => // Move rectangle
        (Circle c) => // Move circle
        default => // Handle default or throw
      }
    }
    

    is better than this?

    // Moving a shape using pattern matching
    void move (Rectangle r) {
        // Move rectangle
    }
    void move (Circle c) {
        // Move circle
    }
    ```</blockquote>
    
    `match` syntax also works in places where you don't want to move your flow to a new function.


  • @Gaska said:

    every language you use has only one great feature.

    Go might be a good, even great, language, but I don't care. @Ben_lubar's constant posting about it, even when it's completely irrelevant to the topic under discussion, has caused me to develop a knee-jerk hatred for it that outweighs any good features it might have.



  • Go's lack of shared libraries makes it a non-starter for most projects anyway.



  • Oh, yes, I'd forgotten about that "feature."



  • Yeah it's weird. It's not just that Go lacks it, but it's that Go lacks it ... ON PURPOSE!

    Memory efficiency? Feh! Upgradability? Foo! Programs that want to use compiled plug-ins to change their behavior? Bah humbug!



  • What the hell are you talking about? You can build a shared library if you want.



  • Since when?



  • CBA to discosearch, but I'm pretty sure I remember discussions on the "benefits" of statically linking All The Things™.





  • Well I'm glad that backpedaled on that fucking stupid shit.

    I'd still never use Go. But maybe it's appropriate for SOME usage now.

    EDIT: that changelog notes they changed the default "GOMAXPROCS" value to one that, you know, makes fucking sense. But they seem to still not have realized that programmers are interested in Cores not Processors. Nobody gives a fuck if your 8 cores are on one processor or your 8 cores are on 4 processors, EITHER WAY IT'S 8 CORES! You're using a computer language WRITTEN BY PEOPLE WHO DO NOT KNOW HOW CPUS WORK!



  • NumCPU returns the number of logical CPUs usable by the current process.

    My computer has 1 processor, 4 cores, and 8 logical CPUs.



  • Congratulations, you have missed the point entirely.

    If your computer has 1 processor, then "GOMAXPROCS" should be set to 1, not 8. EXPLAIN THIS DISCREPANCY.



  • It's not like the first result on Google disproves your assumption or anything.

    Oh wait, yes it is.



  • ok, what the fuck? A OneDrive thing popped up when I took that screenshot and unless I disable OneDrive it gives a border of random crap from my screen.

    Here's what it looks like without OneDrive enabled:



  • @blakeyrat said:

    If your computer has 1 processor, then "GOMAXPROCS" should be set to 1, not 8.

    Why?



  • Huh?

    No it doesn't.



  • Because there's 1 processor.

    If the variable is a count of logical CPUs, it should be named something like GOMAXLOGICALCPUS.

    THIS IS REALLY SIMPLE GUYS.



  • I suppose you're also angry that Microsoft Word can handle more than one word?



  • ?

    Look, Go is brand new. Why does the variable have the wrong name? Why haven't they fixed it?

    The only conclusion is: you are using a programming language written by people who don't know what a CPU is.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.