5 ms·

I love these new additions because I like new stuff but I'll admit it's hard to keep up and use things with good taste. C# is becoming a BIG language similar t

I love these new additions because I like new stuff but I'll admit it's hard to keep up and use things with good taste. C# is becoming a BIG language similar to C++. But I guess that's the only way to get a broad user base long term.

dnautics 6y ago
Go is a relatively simple language that doesn't look like it's getting much bigger and I'm pretty sure it has a fairly broad user base.
- Igelau 6y ago
  Go has the opposite problem. It's not getting big enough. Last I checked, they couldn't be bothered to add integer exponentiation.
  - recursive 6y ago
    C# also doesn't have integer exponentiation.
    - Garvey 6y ago
      It has since .Net 4.0, but does require using BigInteger https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger.pow https://docs.microsoft.com/en-us/dotnet/api/system.numerics....
      - recursive 6y ago
        That's a stretch. There's no language support for it in terms of an operator, and it's in a package that's not referenced by default.
- emodendroket 6y ago
  Dwarfed by that of C#, but it’s also going for something rather different that was never attainable by C# in the first place. Also, I’m kind of on the fence about Go. I was charmed by how easy it is to read and their error handling strategy admittedly has benefits. But it is awfully tedious to write.
  - dnautics 6y ago
    No argument.. I strongly dislike go, myself.
  - politician 6y ago
    I wrote C# for a long time, incl. low-level systems work at the C#/C++ boundary, heavy reflection and simulation systems, and numerical processing. I prefer Go immeasurably. All of the same scope is achievable, but I'm not constantly assaulted by new syntax, unwieldy OO hierarchy towers of Babel, or broken data frameworks. foo, err := DoIt() if err != nil { return err } is a small price to pay for sane control flow in the presence of exceptions. I can debug code in Vim without needing Reflector and Visual Studio to make sense of what I'm looking at.
    - emodendroket 6y ago
      The thing is, yeah, any one of those verbose things wouldn't be a big deal. But there are actually quite a few and it adds up over time.
    - jiggawatts 6y ago
      > I can debug code in Vim without needing Reflector and Visual Studio to make sense of what I'm looking at. Every time I hear someone say something like this, I have a mental image of people manhandling 200kg crates while the forklift sits idle because they can't be bothered learning how to drive it. Reminds me of that multi-million dollar German-made road resurfacing machine that sat unused in some US city because the road crew thought it was too complicated to learn. Sure... they'd have to read the manual and learn to operate it, but that would only save millions of dollars in labour!
- dustinmoris 6y ago
  Ironically I'm mostly abandoning C# and using Go for the majority of my new development now. I really like the simplicity and stability of Go. The compiler speed, the tooling, gofmt, and lots of other goodies just make it a very refreshing change. I'm sure in 5 years time Go will also feel less refreshing, but I have a feeling that my Go code today will not look vastly different to my Go code in 5 years time and that is very attractive. Also Go really allows one to hire anyone. You can literally just hire a smart person and let them learn Go on their first day on the job which will make them good enough to start picking up the first tasks and be productive. There are not many languages which can do that.
  - emodendroket 6y ago
    That's the pitch but I'm also kind of tired of reading Java with Go syntax.
  - merb 6y ago
    > You can literally just hire a smart person and let them learn Go on their first day on the job which will make them good enough to start picking up the first tasks and be productive. you can be productive on the first tasks in any language. that is a stupid pitch. bad code can be written in any language, especially in golang. I've seen as many bad code in golang than in other languages. and fixing bad code in golang is way worse than in some other languages.
    - emodendroket 6y ago
      The thing about it, I think, it that it is very _simple_, in terms of the primitives it gives you, but it wants you to do things differently than you're probably used to.
kemiller2002 6y ago
This is my fear. C# keeps adding things to appeal to a different user base. What I've seen (anecdotally) is that most C# devs don't know or don't use the new features. This pretty much means they are useless to me, because even though I can use them and understand the new features, other people can't. The new code isn't maintainable to most people beyond me. Yes, I can go and show them and train people, but really it comes down to coding the imperative/oo way is what the majority of people are used to.
- emodendroket 6y ago
  The popularity of ReSharper really helps with this, I find. People pick up the new features because ReSharper constantly recommends them.
  - cfn 6y ago
    Resharper has also helped my code to "evolve" alongside the language. In fact I learned LINQ with it. It is also very easy to compare the different solutions for readability in each case.
    - emodendroket 6y ago
      The Linq suggestions are the only one where I frequently have to reject them for being unreadable, but overall yes I agree.
mumblemumble 6y ago
> C# is becoming a BIG language similar to C++. Yes. And they're on roughly the same trajectory: start out as a relatively small object-oriented and procedural language, and then just keep piling on more and more and more features to make the procedural programming more ergonomic. Including by pulling in more and more stuff from functional programming. On the one hand, it's hard for me to dislike adding pattern matching too much, because I do tend to prefer functional programming. On the other hand, I'm also familiar enough with OOP (it's been most my career) to know that there's a huge overlap between problems that pattern matching can solve, and problems that dynamic dispatch can solve. The thing is, in these examples of using pattern matching in a language like C# or Python, I never see anyone even considering the object-oriented solution to the problem. They just show how gross the procedural version is. Which isn't quite enough in my book. You don't just want to show that some existing language features are a poor fit for the problem at hand, you want to show that all existing language features are a poor fit. And somehow, despite these being object-oriented languages, the object-oriented solution is never even being considered anymore. Is it because OOP is that bad? Or is it because we've been badly taught? I know which answer is easier to argue for, but I'm less and less convinced that that's because it's the best answer.
- jayd16 6y ago
  In a lot of ways I think the OOP approach is just too cumbersome. If you imagine implementing a handler chain, the logic would be quite verbose and distributed. You might want to use an inline type definition. Then you might want to use an anonymous types, then lambdas. Then you realize that pattern matching is just a sugared version of the OO handler chain.
  - mumblemumble 6y ago
    I was actually thinking something simpler; just having all your types implement an interface, and then following the general "tell, don't ask" dictum. Handlers are useful for some more complex use cases, as is the visitor pattern, but they're frankly overused. It's often enough to create an interface and let the classes handle their own class-specific logic. And polymorphism is not just a sugared version of pattern matching. Each gives you a different kind of flexibility. Polymorphism makes it easy to add new types to an existing set of operations, and pattern matching makes it easier to add new operations to an existing set of types. Which one you need depends on your use case. The common knowledge can get a bit tricky here, though. For example, functional programming is often touted as being ideal for programming language experimentation, because you have pattern matching, but I have found that OOP is more to my taste in this area. The reason is because, nowadays, the set of basic operations a compiler or interpreter needs to do is fairly well-established and static. But the list of things you need to operate on - that is, the set of features in the language you're implementing - will change as you add or remove features from the language.
ed_elliott_asc 6y ago
Problem is if they don’t keep making changes people start asking why it has been abandoned

dnautics 6y ago

Go is a relatively simple language that doesn't look like it's getting much bigger and I'm pretty sure it has a fairly broad user base.

Igelau 6y ago
Go has the opposite problem. It's not getting big enough. Last I checked, they couldn't be bothered to add integer exponentiation.
- recursive 6y ago
  C# also doesn't have integer exponentiation.
  - Garvey 6y ago
    It has since .Net 4.0, but does require using BigInteger https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger.pow https://docs.microsoft.com/en-us/dotnet/api/system.numerics....
    - recursive 6y ago
      That's a stretch. There's no language support for it in terms of an operator, and it's in a package that's not referenced by default.
emodendroket 6y ago
Dwarfed by that of C#, but it’s also going for something rather different that was never attainable by C# in the first place. Also, I’m kind of on the fence about Go. I was charmed by how easy it is to read and their error handling strategy admittedly has benefits. But it is awfully tedious to write.
- dnautics 6y ago
  No argument.. I strongly dislike go, myself.
- politician 6y ago
  I wrote C# for a long time, incl. low-level systems work at the C#/C++ boundary, heavy reflection and simulation systems, and numerical processing. I prefer Go immeasurably. All of the same scope is achievable, but I'm not constantly assaulted by new syntax, unwieldy OO hierarchy towers of Babel, or broken data frameworks. foo, err := DoIt() if err != nil { return err } is a small price to pay for sane control flow in the presence of exceptions. I can debug code in Vim without needing Reflector and Visual Studio to make sense of what I'm looking at.
  - emodendroket 6y ago
    The thing is, yeah, any one of those verbose things wouldn't be a big deal. But there are actually quite a few and it adds up over time.
  - jiggawatts 6y ago
    > I can debug code in Vim without needing Reflector and Visual Studio to make sense of what I'm looking at. Every time I hear someone say something like this, I have a mental image of people manhandling 200kg crates while the forklift sits idle because they can't be bothered learning how to drive it. Reminds me of that multi-million dollar German-made road resurfacing machine that sat unused in some US city because the road crew thought it was too complicated to learn. Sure... they'd have to read the manual and learn to operate it, but that would only save millions of dollars in labour!
dustinmoris 6y ago
Ironically I'm mostly abandoning C# and using Go for the majority of my new development now. I really like the simplicity and stability of Go. The compiler speed, the tooling, gofmt, and lots of other goodies just make it a very refreshing change. I'm sure in 5 years time Go will also feel less refreshing, but I have a feeling that my Go code today will not look vastly different to my Go code in 5 years time and that is very attractive. Also Go really allows one to hire anyone. You can literally just hire a smart person and let them learn Go on their first day on the job which will make them good enough to start picking up the first tasks and be productive. There are not many languages which can do that.
- emodendroket 6y ago
  That's the pitch but I'm also kind of tired of reading Java with Go syntax.
- merb 6y ago
  > You can literally just hire a smart person and let them learn Go on their first day on the job which will make them good enough to start picking up the first tasks and be productive. you can be productive on the first tasks in any language. that is a stupid pitch. bad code can be written in any language, especially in golang. I've seen as many bad code in golang than in other languages. and fixing bad code in golang is way worse than in some other languages.
  - emodendroket 6y ago
    The thing about it, I think, it that it is very _simple_, in terms of the primitives it gives you, but it wants you to do things differently than you're probably used to.

kemiller2002 6y ago

This is my fear. C# keeps adding things to appeal to a different user base. What I've seen (anecdotally) is that most C# devs don't know or don't use the new features. This pretty much means they are useless to me, because even though I can use them and understand the new features, other people can't. The new code isn't maintainable to most people beyond me. Yes, I can go and show them and train people, but really it comes down to coding the imperative/oo way is what the majority of people are used to.

emodendroket 6y ago
The popularity of ReSharper really helps with this, I find. People pick up the new features because ReSharper constantly recommends them.
- cfn 6y ago
  Resharper has also helped my code to "evolve" alongside the language. In fact I learned LINQ with it. It is also very easy to compare the different solutions for readability in each case.
  - emodendroket 6y ago
    The Linq suggestions are the only one where I frequently have to reject them for being unreadable, but overall yes I agree.

mumblemumble 6y ago

> C# is becoming a BIG language similar to C++. Yes. And they're on roughly the same trajectory: start out as a relatively small object-oriented and procedural language, and then just keep piling on more and more and more features to make the procedural programming more ergonomic. Including by pulling in more and more stuff from functional programming. On the one hand, it's hard for me to dislike adding pattern matching too much, because I do tend to prefer functional programming. On the other hand, I'm also familiar enough with OOP (it's been most my career) to know that there's a huge overlap between problems that pattern matching can solve, and problems that dynamic dispatch can solve. The thing is, in these examples of using pattern matching in a language like C# or Python, I never see anyone even considering the object-oriented solution to the problem. They just show how gross the procedural version is. Which isn't quite enough in my book. You don't just want to show that some existing language features are a poor fit for the problem at hand, you want to show that all existing language features are a poor fit. And somehow, despite these being object-oriented languages, the object-oriented solution is never even being considered anymore. Is it because OOP is that bad? Or is it because we've been badly taught? I know which answer is easier to argue for, but I'm less and less convinced that that's because it's the best answer.

jayd16 6y ago
In a lot of ways I think the OOP approach is just too cumbersome. If you imagine implementing a handler chain, the logic would be quite verbose and distributed. You might want to use an inline type definition. Then you might want to use an anonymous types, then lambdas. Then you realize that pattern matching is just a sugared version of the OO handler chain.
- mumblemumble 6y ago
  I was actually thinking something simpler; just having all your types implement an interface, and then following the general "tell, don't ask" dictum. Handlers are useful for some more complex use cases, as is the visitor pattern, but they're frankly overused. It's often enough to create an interface and let the classes handle their own class-specific logic. And polymorphism is not just a sugared version of pattern matching. Each gives you a different kind of flexibility. Polymorphism makes it easy to add new types to an existing set of operations, and pattern matching makes it easier to add new operations to an existing set of types. Which one you need depends on your use case. The common knowledge can get a bit tricky here, though. For example, functional programming is often touted as being ideal for programming language experimentation, because you have pattern matching, but I have found that OOP is more to my taste in this area. The reason is because, nowadays, the set of basic operations a compiler or interpreter needs to do is fairly well-established and static. But the list of things you need to operate on - that is, the set of features in the language you're implementing - will change as you add or remove features from the language.

ed_elliott_asc 6y ago

Problem is if they don’t keep making changes people start asking why it has been abandoned