[HN Gopher] Twenty years of C# with Anders Hejlsberg [audio]
___________________________________________________________________
Twenty years of C# with Anders Hejlsberg [audio]
Author : binarynate
Score : 64 points
Date : 2022-02-10 20:33 UTC (2 hours ago)
(HTM) web link (www.dotnetrocks.com)
(TXT) w3m dump (www.dotnetrocks.com)
| binarynate wrote:
| I thought it was interesting when Anders mentioned that 30% of C#
| developers use Unity. Unity doesn't use Microsoft's CoreCLR
| runtime, but instead uses the Mono runtime or an AOT compiler
| Unity created called IL2CPP, which converts IL code generated by
| the C# compiler to C++ that gets compiled to native code. One of
| the reasons for this is that CoreCLR supports Windows, macOS and
| Linux, whereas Mono and IL2CPP together support every platform,
| including consoles. Anyway, it's interesting to me that a
| significant number of developers are using C# but are using a
| runtime other than Microsoft's CoreCLR runtime.
| DizzyDoo wrote:
| It's worth mentioning that there's now a _third_ way C# is
| utilised in Unity which is via their new 'Burst' compiler,
| part of their wider move to an Entity Component System they've
| called DOTS[1]. It supports a subset of C# that gets compiled
| into memory safe jobs that can run safely on and spread across
| different threads. I'm using the Burst compiler + jobs in my
| full-time game project and the performance is seriously good
| for whenever you just need to process a lot of data. You can
| use Burst with both Mono and IL2CPP script modes.
|
| The go-to deep dive on how DOTS/Burst works is pretty much
| everything Jackson Dunstan has ever written on the matter [2]
| but specifically the article that digs into how IL2CPP calls
| Burst is interesting.[3]
|
| [1] -
| https://docs.unity3d.com/Packages/com.unity.entities@0.17/ma...
|
| [2] - https://www.jacksondunstan.com/?s=burst
|
| [3] - https://www.jacksondunstan.com/articles/5251
| mikewarot wrote:
| loic-sharma wrote:
| Why is supporting .NET evil?
| mikewarot wrote:
| It locks you in to Microsoft (or it did back then), it's
| unnecessary. It serves no actual purpose, other than to
| support that lockin.
|
| A win32 exe will run on Windows 95 through Windows 10, for
| the most part. You don't need .NET for that to happen.
|
| It's a trap, in other words.
| timomax2 wrote:
| C# is what python programmers wish they had.
| CodeGlitch wrote:
| As a Python programmer I completely agree. Only last week
| I started to look into C# and the cross platform
| capabilities. I have to say it looks really good these
| days. Wish I learnt C# years ago now...
| binarynate wrote:
| Microsoft's .NET runtime and C# compiler have been open
| source and cross platform for a long time now. Even before
| then, MS published ECMA standards for .NET and C# since the
| beginning, and the Mono runtime and compiler for C# have
| been open source and cross platform since the early 2000s:
|
| https://en.wikipedia.org/wiki/Mono_(software)#History
| aninteger wrote:
| Yes, of course this is true but the tooling ecosystem
| still hasn't made great strides over to Linux. Rider does
| exist but is not open source. As far as I know the
| debugger is not open source as well.
| WalterGR wrote:
| So much goalpost moving.
| smackeyacky wrote:
| It's biggest competitor (Java) has exactly the same
| ownership issues.
|
| C# and .NET Core in particular give me the ability to
| deploy server or utility software on pretty much anything.
| You can build a completely self contained executable which
| is fantastic for deploying software on machines where you
| can't control the infrastructure.
|
| So, sort of the opposite of lock in.
| onemoresoop wrote:
| I suggest downloading the file locally first so you can skip over
| the reverberated bathroom part.
| binarynate wrote:
| For context, Anders is the creator of C# and TypeScript:
|
| https://en.wikipedia.org/wiki/Anders_Hejlsberg
| ejb999 wrote:
| Interesting - never heard of him, that I can remember anyway,
| over my career my three favorite programming languages were (in
| order from oldest to newest) - Turbo Pascal, C# and now
| Typescript - and apparently he created all three.
| spaetzleesser wrote:
| He certainly knows how to create programming languages that
| last.
| Reitet00 wrote:
| And also the author of Delphi and Turbo Pascal.
| ejb999 wrote:
| loved turbo pascal a long time ago - got my professional
| start there - but I will forgive him for Delphi anyway :>)
| lostmsu wrote:
| What did you use between TurboPascal and C#? o-O
| ejb999 wrote:
| VB/VB6, with some Clipper and Foxpro mixed in.
|
| Switched to c# instead of picking up vb.net - in
| retrospect a good call.
| zwieback wrote:
| Classic progression - some of us came from VB Classic to
| C# others from C++ (at least in the Windows world). Now
| we're all one big happy family.
| nottorp wrote:
| > I will forgive him for Delphi anyway
|
| Sounds like you never used Delphi. Modern C sharp with
| whatever MS calls the GUI classes this week doesn't hold a
| candle to how fast you chouls whip up an UI in Delphi and
| then concentrate on actual functions.
|
| Edit: talking about the Delphi before Microsoft offered
| Hejlsberg 1 million extra per year and Borland refused to
| match...
| intrasight wrote:
| I can't believe that I've been hacking C# for 20 years
| polskibus wrote:
| I wish he came back to evolving C#. Progress from v1 to v5 was
| enormous in contrast to v6 to v10.
| tester756 wrote:
| It feels like 6-10 is mostly handy stuff and performance
| related
|
| https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...
|
| Meanwhile 2 and 3 were giant, holy shit.
| dgritsko wrote:
| As a fellow C# aficionado, what do you think it's lacking right
| now? The main thing I really would like to see is support for
| discriminated unions - but outside of that, it's pretty
| awesome.
| binarynate wrote:
| I'd love to see support for structural typing. There are some
| proposals for that:
|
| - https://github.com/dotnet/csharplang/discussions/164
|
| - https://github.com/dotnet/csharplang/discussions/2548
| polskibus wrote:
| Nullable references are far from what they could be. When you
| use them a lot, you often have to override compiler with !
| because it is too stupid. I'd also like to have better
| support for const references as in c++.
|
| I'd like to see more powerful generics, so that something
| akin to partial template specialisation is possible without
| going through boxing and unboxing too much.
|
| With regards to safety, well rust has shown what is possible.
| Async/ await has introduced function colouring which is a
| kind of bloat.
|
| All in all there are many things that could reduce the bloat,
| instead of some tiny features that help with value types or
| to optimise some rare case.
| jayd16 wrote:
| People call async/await function coloring bloat but I think
| it's exactly where it needs to be. IMO execution yielding
| needs to be explicit not implicit for use cases where
| thread identity matters. How are you going to write a UI
| framework if thread context can change unexpectedly?
| coder543 wrote:
| Go doesn't need "coloring bloat", but you can still
| handle the need to run code on a specific thread using
| LockOSThread.[0] If you absolutely need your code that
| interacts with the OS GUI functions to be running on the
| first thread the OS spawned, the documentation even tells
| you how to do that.
|
| This is an exceptionally low level detail that very few
| people should ever have to think about. Is there
| something else you can point to that's pertinent to more
| developers?
|
| Having written Go for years (as well as a good bit of
| Rust), I love not having to worry about async/await being
| the concurrency model, and thread identity is never
| something I think about. With the upcoming Go release
| that brings generics, I think there are some code
| patterns that inherently benefit from an async/await
| style pattern where you spawn several tasks and await
| their results, so I'm looking forward to having a generic
| pattern to spawn goroutines that return a value into a
| Promise... but the infectious nature of "real"
| async/await is not something I would consider beneficial
| in most languages. Rust is a language that is _all_ about
| low level details and performance, so it actually makes
| sense there, but that 's a rare exception, in my opinion.
|
| Developers generally shouldn't need to worry about things
| a good runtime can take care of, just like you don't need
| to worry about when you're going to free an object in
| C#... the runtime takes care of these details that are
| rarely relevant meeting the developer's objectives. When
| you absolutely need that control, there are usually
| escape hatches. If the application you're writing
| frequently requires unlimited control, you should
| probably be using an unmanaged language like Rust to
| begin with.
|
| [0]: https://pkg.go.dev/runtime#LockOSThread
| tester756 wrote:
| >With regards to safety, well rust has shown what is
| possible. Async/ await has introduced function colouring
| which is a kind of bloat.
|
| I do wonder how much effort it'd require
| VincentEvans wrote:
| I wish for just one thing: native AOP (aspect oriented
| programming) aka Python-style decorators and context
| managers. Everything else I need C# already covers
| adequately.
| tester756 wrote:
| You mean Java's "Annotation Oriented Programming"?
|
| like @Transactional?
|
| If yes, then I'd really do not want those "magic-like,
| tricky when it comes to debugging" features
| VincentEvans wrote:
| Last time I used Java, it looked to me that AOP is
| supported with compile-time byte-code rewriting, which
| might explain why it may feel like magic and be hard to
| debug. .Net also has a IL-rewriting 3rd party toolkits
| that enable AOP, namely Postsharp - but my experience
| with it wasn't great for similar reasons you stated.
| Maybe I did something incorrectly, but my impression of
| tools that generate code at compile time - is that you
| can't step through the resulting code. Python on the
| other hand is both flexible and simple. The decorator
| code simply wraps the function it decorates (you get a
| lambda variable that will contain the function you
| annotate, so you do whatever it is you need to do, and
| then call the original function. Or not, your choice. )
| and doesn't feel complicated at all. Debugging is simple.
|
| Try it and you might change your mind - perhaps C#
| designers could use a similar source of inspiration.
| jayd16 wrote:
| I think Kotlin's type delegation is probably a better way
| to handle method overrides/wrapping. Fits into the language
| better.
| giaour wrote:
| > aka Python-style decorators and context managers
|
| Genuinely curious: aren't Python decorators basically the
| same as C# annotations, and aren't context managers
| covering the same ground as a C# using statement?
| binarynate wrote:
| If you want to skip past the intro segments, you can use a
| different player like the Apple Podcasts site. The actual
| interview starts at 10:00:
|
| https://podcasts.apple.com/us/podcast/twenty-years-of-c-with...
| mattferderer wrote:
| You can also use their website that's linked to. Just need to
| hit play & than close the pop up & you should see the player
| which you can skip around on.
|
| Not the best website user experience but it's a great podcast,
| even if you're not interested in .NET. Highly recommend all
| their Geek Out episodes.
| zwieback wrote:
| I vividly remember when I started using C#, I can say that 20
| years later I only feel a little bit bad about leaving C++
| (mostly) behind and glad I didn't have to go the Java route.
| softfalcon wrote:
| Why does the intro ad sound like it was recorded in an Elementary
| School hallway?
| binarynate wrote:
| I think they added some reverb to Richard's voice for part of
| the intro and accidentally reverbed all of the ads, too
| binarynate wrote:
| I just sent Carl a heads-up about the reverb:
| https://twitter.com/binarynate/status/1491890009674244107
| [deleted]
| [deleted]
| daok wrote:
| The lack of possibility to scroll in time (to skip that part)
| is what bothered me the most.
___________________________________________________________________
(page generated 2022-02-10 23:00 UTC)