7 ms·

What I love in C# is, each update the language gets even faster, far more natural to write. Soo different of Javascript, where looks you are fighting against th

What I love in C# is, each update the language gets even faster, far more natural to write. Soo different of Javascript, where looks you are fighting against the language first, and then if you win, can develop something useful. I use js why I need use it, but I hope use c# instead, high hopes with webassembly, etc

spion 10y ago
Interesting, I've found the reverse is true for me with ES6. For example, ES6 already had local functions (and a very terse form of that too using lambdas) class C { method() { let localFunction = x => x + 1 function anotherLocal(a) { return a + 1; } } } ... arrays are normally used to represent tuples (or freeform objects), and it includes destructuring too: function f(x) { return [x, x*2] } let [x, xdoubled] = f(5) or function f(y) { return {y, timesTwo: y*2} } let {y, timesTwo} = f(10) It almost seemed to me that many of the features listed here were "borrowed" from the liberal style allowed by ES6 and TypeScript (am probably wrong, and both are borrowing from elsewhere).
- ZeroClickOk 10y ago
  Each release c# get more and more "functional". Previous versions you can use anonymous methods or lambdas to "simulate" local functions, but now its first class citzen. The problem with JS is you need deal with a lot of hacky legacy things too, you want try new cool things on ES6/ES7, but you need take care about compatibility, 3rd party libraries integration, etc. IMHO, I hope something like "ES10", where they forget previous versions, create from scratch a new javascript, without worries about polifilling, compatibily, shimming, etc. Then start to evolve from there.
  - dodyg 10y ago
    It's not wise to start a over a language. Perl6.
- WaxProlix 10y ago
  > (am probably wrong, and both are borrowing from elsewhere). You're right there. Tuple unpacking has existed in even stronger form (pattern matching) in most functional or functional-ish languages for ages. Python's had unpacking since God knows when. F#, which is sort of related to ML and feeds features to C# somewhat regularly, does this sort of thing as first-class syntax. It's sort of a trend for people who learn JS first (or only) to look at features that it's had stapled to it and then point out how much other languages are taking from it.
  - DougWebb 10y ago
    Python's had unpacking since it got it from Perl, back in the 90's. I'm really glad to see C# is catching up :)
  - spion 10y ago
    You're incorrect in assuming that I've only/first learnt JS. But its sort of a trend for people to look down on JS programmers, since its considered a "low-status" language ;) And I'm well aware that the direct inspiration for many of ES6's features is probably Python (and now C# with async/await, which in turn flowed there from F#) I'm assuming some cross-borrowing is happening here due to developments on the TypeScript team, and due to much higher similarities of the specifics with TypeScript. After all, F# has been around for quite a while, yet we're only seeing this development now - so if F# is the inspiration, why did it not happen much earlier?
    - jackfoxy 10y ago
      It didn't happen much earlier because the Microsoft languages team is very deliberate and careful about rolling out new features. They have to be. There are something like 1.5 billion machines running some sort of Windows, and (I don't know) on the order of 1/2 - 1 million developers who work with MS languages and tools. Lots of backward compatibility to think about. At this scale even five 9s quality ends up breaking things.
    - WaxProlix 10y ago
      Disagree strongly. I don't think looking down on JS programmers is a trend really, it's been happening for a long time now. If anything, that era has been fading with the legitimacy that runtimes like Node and adoption by high-profile companies bring to the JS ecosystem. As for JS itself, ES6 is a great step in the right direction, and I like it a lot, though I prefer Typescript for pretty much anything when I can use it. Also - I didn't say that you learned it first or only, just that I see a lot of praise for 'JS features' being adopted by other languages from people who very obviously don't know any better - and this only in the last 3 or so years. So I think it's a trend.
- int_19h 10y ago
  The borrowing kinda goes in circles. The terse syntax of ES6 lambdas is straight from C#, for example.
dested 10y ago
I'm a huge fan of http://bridge.net/ http://bridge.net/ for c# to js "transpilation". The runtime isn't too hefty and provides great feature parity to javascript.
kevin_thibedeau 10y ago
I wouldn't be surprised if Typescript becomes native in the next decade. That will address some of the sins of JS and make Webassembly less of a hack.
- klodolph 10y ago
  I emphatically disagree with the assertion that WebAssembly is a hack. Maybe asm.js is a hack... but WebAssembly is fairly well thought out. I don't expect TypeScript to compile easily to WebAssembly. You'd have to write your on GC and do a bunch of other work that you get for free when you target JavaScript... and that means that there are plenty of opportunities do make your runtime worse than your target browser's runtime, at the cost of increased code size to boot.
  - cwyers 10y ago
    The goal is for WebAssembly to get access to the same GC as JavaScript eventually, right? Not mandatory, but available.
ralusek 10y ago
What are you talking about? What are you finding unnatural about the direction JS has gone in? class Guy { sayHello() { console.log('Hello.'); } } const guy = new Guy(); guy.sayHello(); Or for practical code: Get IDs of users named Mike db.users.fetch({firstName: 'Mike'}, {limit: 10}) .then(users => users.map(user => user.id)); The language is so popular to shit on, with absolutely no basis.
untog 10y ago
You're fighting JS more than you fight C# because you don't know JS as well as you know C#. As someone who has coded in both I won't deny for a second that C# is the better language, but I spend most of my time in JS these days I don't "fight against" it at all. I know how it works, and I use it accordingly.
ken47 10y ago
Javascript has taken a quantum leap with es6, and if you look at what Typescript and Flow are doing, another quantum leap in that dimension. C# is great, but I think the latter, especially Typescript, bring the Javascript community into the same ballpark.
johnfn 10y ago
It's funny you say that, because as someone more experienced in JS, I found myself saying "oh look, C# is coming up to par with ES6!" e.g. Tuple types and destructuring, which are a part of ES6.
- nulagrithom 10y ago
  I thought the reverse with ES6. :) "Oh look, arrow functions! Finally!" It's fun to see how languages influence each other.
  - johnfn 10y ago
    Hah, that was actually ES5 ;-) but I assure you the entire JS community was celebrating. :) I actually think C# is a better language than JS, but it's nice to see how they get the best features from each other.
    - nulagrithom 10y ago
      ES6 actually! Pretty recent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Specifications https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      - johnfn 10y ago
        Weird, it feels like they've been around longer... too many transpilers.
- louthy 10y ago
  > Tuple types and destructuring, which are a part of ES6. And part of many, many languages prior to ES6.
  - johnfn 10y ago
    I don't see how bringing this up is necessary or relevant. These types of comments seemed to me to be nothing more than a snarky aside. "You're happy about X feature? Well it already existed in Y language."
jfroma 10y ago
I worked for 6 years on C#, I was C# MVP and I really enjoyed the language. 4 years ago I started to work more with js and then node.js until I stopped working on c#. Js has been for me a gateway to transition to other languages and get paid for that. I learned bash, python, a bit of ruby, go, etc. If I see c# code today I don't understand what it does. Sure every version has a lot of new very useful stuff but it also introduces noise, "why he used out x instead of the new shiny out var x, he might not know about it, lets send PR". Along the way I have learned to appreciate simpler languages that does not change that often. Where there are few or just one way to do something. I think I read an interview to Mitchel Hashimoto (hashicorp) and he said he choose Go over all languages because it was boring. A boring and simple language allows you to focus on the problem you are solving. A language that doesn't change for years allows people to catch up and master the tool. It also means that you can open a file written by someone else years ago and understand what it does. IMHO js was in that sweet spot until ES6.
- swlkr 10y ago
  You should give clojure a try, the community resists change not because their luddites, but because change is risk.
- mattchew 10y ago
  I agree. After watching the Go developers push back against noisy changes, I'm much more appreciative of determined simplicity in language design. > If I see c# code today I don't understand what it does. I am not surprised. The C# team should be more concerned about this. I love C#, but it is getting more complicated and arcane and therefore more unfriendly to newbies. Some of this is probably unavoidable, but some of it could be avoided. The language has to stay attractive to newcomers to survive in the long run.
- buzzybee 10y ago
  Go is indeed attractive for this. Although it's a little bit too far to the end of "no extendability" for me. Oberon-07 and Lua are also great examples of making it work.
- ShinTakuya 10y ago
pmarreck 10y ago
> Out variables This is pretty much a terrible language design idea. (Not the "out int x" change, but the whole idea of "out" in an argument list to begin with to indicate values coming out via the arguments.) The path out of mutable argument bug-hell is not to declare that the values of some argument variables will intentionally get changed by the function in the scope where it is called. It is to make arguments immutable (like they are in the traditional mathy definition of "function"), period, and allow multiple assignment to the function call. What I mean is that, conceptually, ideally, values and state should only flow into the function arguments and only back out of the function call itself. So for example instead of > p.GetCoordinates(out int x, out int y); I think the following would lead to reduced cognitive load and thus fewer bugs: > int x, int y = p.GetCoordinates; or even better (color me biased by Erlang/Elixir): > {x, y} = p.GetCoordinates; # as a pattern match Instead of a smoothly mentally-traceable flow of values into function arguments and out of function returns, we have this monstrosity of conflating mutable arguments (where values go in and then come back out changed in the scope of the function call) with this "out int x" business which seems to be indicating it intends to "push values upstream", as it were.
- tdestan 10y ago
  Did you read far enough to see the tuple return value syntax? var (first, middle, last) = LookupName(id1); Seems like what you're suggesting, no?
  - pmarreck 10y ago
    Better. But the id1 argument can still be mutated by LookupName in this scope, no?
    - tdestan 10y ago
      Depends. Based on my hazy memory of C#, if id is a struct/value type it is copied, but if it is a class type, there's nothing preventing the method call from mutating it. Which is unfortunate, I agree.

spion 10y ago

Interesting, I've found the reverse is true for me with ES6. For example, ES6 already had local functions (and a very terse form of that too using lambdas) class C { method() { let localFunction = x => x + 1 function anotherLocal(a) { return a + 1; } } } ... arrays are normally used to represent tuples (or freeform objects), and it includes destructuring too: function f(x) { return [x, x*2] } let [x, xdoubled] = f(5) or function f(y) { return {y, timesTwo: y*2} } let {y, timesTwo} = f(10) It almost seemed to me that many of the features listed here were "borrowed" from the liberal style allowed by ES6 and TypeScript (am probably wrong, and both are borrowing from elsewhere).

ZeroClickOk 10y ago
Each release c# get more and more "functional". Previous versions you can use anonymous methods or lambdas to "simulate" local functions, but now its first class citzen. The problem with JS is you need deal with a lot of hacky legacy things too, you want try new cool things on ES6/ES7, but you need take care about compatibility, 3rd party libraries integration, etc. IMHO, I hope something like "ES10", where they forget previous versions, create from scratch a new javascript, without worries about polifilling, compatibily, shimming, etc. Then start to evolve from there.
- dodyg 10y ago
  It's not wise to start a over a language. Perl6.
WaxProlix 10y ago
> (am probably wrong, and both are borrowing from elsewhere). You're right there. Tuple unpacking has existed in even stronger form (pattern matching) in most functional or functional-ish languages for ages. Python's had unpacking since God knows when. F#, which is sort of related to ML and feeds features to C# somewhat regularly, does this sort of thing as first-class syntax. It's sort of a trend for people who learn JS first (or only) to look at features that it's had stapled to it and then point out how much other languages are taking from it.
- DougWebb 10y ago
  Python's had unpacking since it got it from Perl, back in the 90's. I'm really glad to see C# is catching up :)
- spion 10y ago
  You're incorrect in assuming that I've only/first learnt JS. But its sort of a trend for people to look down on JS programmers, since its considered a "low-status" language ;) And I'm well aware that the direct inspiration for many of ES6's features is probably Python (and now C# with async/await, which in turn flowed there from F#) I'm assuming some cross-borrowing is happening here due to developments on the TypeScript team, and due to much higher similarities of the specifics with TypeScript. After all, F# has been around for quite a while, yet we're only seeing this development now - so if F# is the inspiration, why did it not happen much earlier?
  - jackfoxy 10y ago
    It didn't happen much earlier because the Microsoft languages team is very deliberate and careful about rolling out new features. They have to be. There are something like 1.5 billion machines running some sort of Windows, and (I don't know) on the order of 1/2 - 1 million developers who work with MS languages and tools. Lots of backward compatibility to think about. At this scale even five 9s quality ends up breaking things.
  - WaxProlix 10y ago
    Disagree strongly. I don't think looking down on JS programmers is a trend really, it's been happening for a long time now. If anything, that era has been fading with the legitimacy that runtimes like Node and adoption by high-profile companies bring to the JS ecosystem. As for JS itself, ES6 is a great step in the right direction, and I like it a lot, though I prefer Typescript for pretty much anything when I can use it. Also - I didn't say that you learned it first or only, just that I see a lot of praise for 'JS features' being adopted by other languages from people who very obviously don't know any better - and this only in the last 3 or so years. So I think it's a trend.
int_19h 10y ago
The borrowing kinda goes in circles. The terse syntax of ES6 lambdas is straight from C#, for example.

dested 10y ago

I'm a huge fan of http://bridge.net/ http://bridge.net/ for c# to js "transpilation". The runtime isn't too hefty and provides great feature parity to javascript.

kevin_thibedeau 10y ago

I wouldn't be surprised if Typescript becomes native in the next decade. That will address some of the sins of JS and make Webassembly less of a hack.

klodolph 10y ago
I emphatically disagree with the assertion that WebAssembly is a hack. Maybe asm.js is a hack... but WebAssembly is fairly well thought out. I don't expect TypeScript to compile easily to WebAssembly. You'd have to write your on GC and do a bunch of other work that you get for free when you target JavaScript... and that means that there are plenty of opportunities do make your runtime worse than your target browser's runtime, at the cost of increased code size to boot.
- cwyers 10y ago
  The goal is for WebAssembly to get access to the same GC as JavaScript eventually, right? Not mandatory, but available.

ralusek 10y ago

What are you talking about? What are you finding unnatural about the direction JS has gone in? class Guy { sayHello() { console.log('Hello.'); } } const guy = new Guy(); guy.sayHello(); Or for practical code: Get IDs of users named Mike db.users.fetch({firstName: 'Mike'}, {limit: 10}) .then(users => users.map(user => user.id)); The language is so popular to shit on, with absolutely no basis.

untog 10y ago

You're fighting JS more than you fight C# because you don't know JS as well as you know C#. As someone who has coded in both I won't deny for a second that C# is the better language, but I spend most of my time in JS these days I don't "fight against" it at all. I know how it works, and I use it accordingly.

ken47 10y ago

Javascript has taken a quantum leap with es6, and if you look at what Typescript and Flow are doing, another quantum leap in that dimension. C# is great, but I think the latter, especially Typescript, bring the Javascript community into the same ballpark.

johnfn 10y ago

It's funny you say that, because as someone more experienced in JS, I found myself saying "oh look, C# is coming up to par with ES6!" e.g. Tuple types and destructuring, which are a part of ES6.

nulagrithom 10y ago
I thought the reverse with ES6. :) "Oh look, arrow functions! Finally!" It's fun to see how languages influence each other.
- johnfn 10y ago
  Hah, that was actually ES5 ;-) but I assure you the entire JS community was celebrating. :) I actually think C# is a better language than JS, but it's nice to see how they get the best features from each other.
  - nulagrithom 10y ago
    ES6 actually! Pretty recent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Specifications https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - johnfn 10y ago
      Weird, it feels like they've been around longer... too many transpilers.
louthy 10y ago
> Tuple types and destructuring, which are a part of ES6. And part of many, many languages prior to ES6.
- johnfn 10y ago
  I don't see how bringing this up is necessary or relevant. These types of comments seemed to me to be nothing more than a snarky aside. "You're happy about X feature? Well it already existed in Y language."

jfroma 10y ago

I worked for 6 years on C#, I was C# MVP and I really enjoyed the language. 4 years ago I started to work more with js and then node.js until I stopped working on c#. Js has been for me a gateway to transition to other languages and get paid for that. I learned bash, python, a bit of ruby, go, etc. If I see c# code today I don't understand what it does. Sure every version has a lot of new very useful stuff but it also introduces noise, "why he used out x instead of the new shiny out var x, he might not know about it, lets send PR". Along the way I have learned to appreciate simpler languages that does not change that often. Where there are few or just one way to do something. I think I read an interview to Mitchel Hashimoto (hashicorp) and he said he choose Go over all languages because it was boring. A boring and simple language allows you to focus on the problem you are solving. A language that doesn't change for years allows people to catch up and master the tool. It also means that you can open a file written by someone else years ago and understand what it does. IMHO js was in that sweet spot until ES6.

swlkr 10y ago
You should give clojure a try, the community resists change not because their luddites, but because change is risk.
mattchew 10y ago
I agree. After watching the Go developers push back against noisy changes, I'm much more appreciative of determined simplicity in language design. > If I see c# code today I don't understand what it does. I am not surprised. The C# team should be more concerned about this. I love C#, but it is getting more complicated and arcane and therefore more unfriendly to newbies. Some of this is probably unavoidable, but some of it could be avoided. The language has to stay attractive to newcomers to survive in the long run.
buzzybee 10y ago
Go is indeed attractive for this. Although it's a little bit too far to the end of "no extendability" for me. Oberon-07 and Lua are also great examples of making it work.
ShinTakuya 10y ago

pmarreck 10y ago

> Out variables This is pretty much a terrible language design idea. (Not the "out int x" change, but the whole idea of "out" in an argument list to begin with to indicate values coming out via the arguments.) The path out of mutable argument bug-hell is not to declare that the values of some argument variables will intentionally get changed by the function in the scope where it is called. It is to make arguments immutable (like they are in the traditional mathy definition of "function"), period, and allow multiple assignment to the function call. What I mean is that, conceptually, ideally, values and state should only flow into the function arguments and only back out of the function call itself. So for example instead of > p.GetCoordinates(out int x, out int y); I think the following would lead to reduced cognitive load and thus fewer bugs: > int x, int y = p.GetCoordinates; or even better (color me biased by Erlang/Elixir): > {x, y} = p.GetCoordinates; # as a pattern match Instead of a smoothly mentally-traceable flow of values into function arguments and out of function returns, we have this monstrosity of conflating mutable arguments (where values go in and then come back out changed in the scope of the function call) with this "out int x" business which seems to be indicating it intends to "push values upstream", as it were.

tdestan 10y ago
Did you read far enough to see the tuple return value syntax? var (first, middle, last) = LookupName(id1); Seems like what you're suggesting, no?
- pmarreck 10y ago
  Better. But the id1 argument can still be mutated by LookupName in this scope, no?
  - tdestan 10y ago
    Depends. Based on my hazy memory of C#, if id is a struct/value type it is copied, but if it is a class type, there's nothing preventing the method call from mutating it. Which is unfortunate, I agree.