3 ms·

The way to go, i wonder why it took them so long to have such feature, everyone around me is using Go, part of the reason why is single native static binary It

The way to go, i wonder why it took them so long to have such feature, everyone around me is using Go, part of the reason why is single native static binary It's mind boggling that they are just now waking up, not having it makes it impossible to choose and recommend dotnet when your requisite is to be able to have something "tiny", fast and ready to go (no cold start, no runtime dependencies) We talk a lot about Go, but Java had it for years with GraalVM, it should have gave them a hint Of course there was alternative solutions for native AOT, but nothing as easy and integrated as: dotnet publish

klibertp 4y ago
> It's mind boggling that they are just now waking up It's nothing unusual. Software engineering as a field moves at a glacial pace. I see two reasons for this: one is that people don't want to learn anything radically different from what they know already, so you need generational change for new ideas to have a chance to come to fruition. It's a 10-20 years cycle. Then the other reason is that we basically don't know what we're doing, and so some of the new ideas are terrible in practice, reinforcing the first reason. How long did it take for mainstream languages to start seeing `null` as a problem and getting Option types? Depending on who you ask, it'll be 20-30 years; Haskell and other MLs had it either from day 1 or after inventing monads and Maybe (I'm not sure here), and Haskell introduced monads in early '90s. So it's at least 20 years since then, and yet we still have NullPointerExceptions here and there...
- maccard 4y ago
  > Software engineering as a field moves at a glacial pace. What other industries have you worked in that move faster than software? My experience is that the rate of change is so high and fast in so many areas it's impossible to keep up. Meanwhile in other industries version control still hasn't even gotten as far as track changes in word!
  - klibertp 4y ago
    > My experience is that the rate of change is so high and fast in so many areas Yes. The rate of change is very high. Real, actual improvements, however, are very rare. Most of the code written today in Python - my field of expertise - is written almost exactly the same way it was since 2.4, when I started using it. C10k problem[1] is known for 20+ years already, yet Python only recently got async/await - a proven, very old technique often used for addressing the problem. I learned Rust earlier this year, and they also introduced async/await very recently. pg wrote about the technique in his "On Lisp" sometime in the '90s, so it probably was well known way before that. Scheme and Smalltalk, having reified call stacks in their respective ways, supported concurrency with lightweight threads since '80s. Now you hear about Crystal introducing fibers and how great they are. Yes, they are - and were, for the past 40 years. Rediscovered, and reimplemented, again, because nobody cares about the history of the field, everyone just wants to build their own thing, and solving puzzles is more fun than studying and then standing on the giants' shoulders. Yes, git is a nice VCS, but to be honest - Subversion wasn't that bad, either. NetBSD still uses CVS for versioning and developing its packages. Yes, being able to work without a central server is an improvement, but then again: everything is hosted on Github, a central server, anyway. Some terminal emulators experiment with displaying inline images. The new ones, Kitty and its ilk. First, they try to improve the protocol designed for teletypes in the '60s (IIRC), then they give up and introduce non-standard extensions, which limits their reach and usefulness. But then again, Kitty is hardly the first attempt - IPython qtconsole is also ~15 years old, and a decade before that TCL tried the same thing (with some success I hear). One possible solution to the expression problem, namely multiple dispatch / multimethods, is a selling point of some new languages, like Raku, Nim, Clojure, and of course Julia. Multimethods are known since the '70s, too, yet not even one mainstream language has them as a feature. There's a lot to be said about the churn on the Web, and I don't want to go there, but from the outside perspective, the only real change that happened sometime in the last decade was Let's Encrypt becoming CA. IPv6 adoption is the same as always, and we still need NAT traversal techniques that we used in the '90s. Other than that, everything people do with JavaScript was already done and tested decades ago. I mean, virtual DOM? That's basically what X windows are, and every other GUI out there does it, with invalidating objects and redrawing only obscured/damaged parts of an object, with double buffering to avoid flickering. The shadow DOM and web components - though I've no idea how widely they are used - make the same promise that vendors made when shipping widgets as DLLs to Object Pascal, later renamed Delphi. The only real progress, other than adopting HTTPS everywhere, was ditching Flash, ActiveX and Java applets. It really tells a lot that the most impressive progress happened because of removing something instead of adding. There's a lot more. I don't want to dismiss the great work of a great many fabulous programmers. The progress is happening at all thanks to them. The average developer, however, is average, and does not have knowledge and skills to write something actually game-changing. They try all the time, though, because it's fun, and then the hype and mob mentality takes over on social media. You could say that machine learning was a great development, but then again - neural networks were described in the '70s. It just so happened that massively parallel GPUs were a good way to speed up otherwise very demanding computations. Computation, might I add, mostly done in Fortran (blas, lapack), to this day. I don't want to dismiss the progress we're seeing. I just wish programmers would actually, seriously study the history of our field before going off to create yet another framework. Despite being short, the history of our field is littered with incredible amounts of prior art, and improving upon that should be the goal, I think, not "rethinking and reimplementing" everything from scratch every 10 years. EDIT: I forgot to answer your question: I only worked with software for all my life, I can't say anything about any other field. Most of them, though, have centuries or millennia of history, and they seem to efficiently manage that legacy, turning it into productivity. Maybe there's less objective need for change there, or in some cases the change is impossible due to regulations? Fields that came into being due to the IT revolution seem to be similarly stuck in change-without-progress cycles. Some social activities are like this, too. It might be simply a feature all young fields have. I'm guessing a lot of early airplanes crashed, some of them because of problems that were solved already elsewhere, but without anyone else knowing. The number/rate of failed software projects is staggering, just as a lot of early flying ended with a crash. I'm not sure there's a meaningful correlation, and I'm way outside of my expertise when talking about planes, but I can't help seeing our field as immature and moving very slowly forward. The blessing in disguise is that this time around, failed project doesn't often mean someone died. [1] https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem
pjc50 4y ago
> why it took them so long to have such feature The demand is not so strong, and the Windows world is extremely used to having bits of dynamic runtime; the entirety of COM, for example. It does illustrate the tug of war that .NET has always struggled with. The things Microsoft want it for within the Windows ecosystem vs the "normal language" running server-side applications on Linux that a lot of the customers want.
pjmlp 4y ago
It is there since .NET 1.0, see NGEN. However it is done at installation time with dynamic linking only. And Mono has had it since ages, used by Unity and Xamarin. This is the porting of UWP .NET Native to mainline .NET.
- Shadonototra 4y ago
  You miss the point go build and you get 1 portable tiny executable ngen, .net native, mono etc, you need more steps, and you get a folder with a bunch of files and folders that's why these solutions didn't took off
  - vips7L 4y ago
    dotnet publish -p:PublishSingleFile=true
    - pjc50 4y ago
      This produces a self-unpacking executable that drops all the assemblies somewhere and then runs it. There can be surprising side effects. https://github.com/dotnet/runtime/issues/59715 https://github.com/dotnet/runtime/issues/59715 And check the small print on your platform as to whether it's really single file not requiring any other dependencies alongside it.
      - vips7L 4y ago
        > This produces a self-unpacking executable that drops all the assemblies somewhere and then runs it. This no longer happens since .net 5.
  - pjmlp 4y ago
    You miss the point go build and you get 1 portable tiny executable, provided it is 100% Go code, without any dependency on cgo or OS APIs not packaged into the Go runtime. These solutions did take off, how do you think Unity games for PS, Xbox, Wii, Switch, Windows 10 UWP, and Xamarin apps for iOS/Android get delivered?

klibertp 4y ago

> It's mind boggling that they are just now waking up It's nothing unusual. Software engineering as a field moves at a glacial pace. I see two reasons for this: one is that people don't want to learn anything radically different from what they know already, so you need generational change for new ideas to have a chance to come to fruition. It's a 10-20 years cycle. Then the other reason is that we basically don't know what we're doing, and so some of the new ideas are terrible in practice, reinforcing the first reason. How long did it take for mainstream languages to start seeing `null` as a problem and getting Option types? Depending on who you ask, it'll be 20-30 years; Haskell and other MLs had it either from day 1 or after inventing monads and Maybe (I'm not sure here), and Haskell introduced monads in early '90s. So it's at least 20 years since then, and yet we still have NullPointerExceptions here and there...

maccard 4y ago
> Software engineering as a field moves at a glacial pace. What other industries have you worked in that move faster than software? My experience is that the rate of change is so high and fast in so many areas it's impossible to keep up. Meanwhile in other industries version control still hasn't even gotten as far as track changes in word!
- klibertp 4y ago
  > My experience is that the rate of change is so high and fast in so many areas Yes. The rate of change is very high. Real, actual improvements, however, are very rare. Most of the code written today in Python - my field of expertise - is written almost exactly the same way it was since 2.4, when I started using it. C10k problem[1] is known for 20+ years already, yet Python only recently got async/await - a proven, very old technique often used for addressing the problem. I learned Rust earlier this year, and they also introduced async/await very recently. pg wrote about the technique in his "On Lisp" sometime in the '90s, so it probably was well known way before that. Scheme and Smalltalk, having reified call stacks in their respective ways, supported concurrency with lightweight threads since '80s. Now you hear about Crystal introducing fibers and how great they are. Yes, they are - and were, for the past 40 years. Rediscovered, and reimplemented, again, because nobody cares about the history of the field, everyone just wants to build their own thing, and solving puzzles is more fun than studying and then standing on the giants' shoulders. Yes, git is a nice VCS, but to be honest - Subversion wasn't that bad, either. NetBSD still uses CVS for versioning and developing its packages. Yes, being able to work without a central server is an improvement, but then again: everything is hosted on Github, a central server, anyway. Some terminal emulators experiment with displaying inline images. The new ones, Kitty and its ilk. First, they try to improve the protocol designed for teletypes in the '60s (IIRC), then they give up and introduce non-standard extensions, which limits their reach and usefulness. But then again, Kitty is hardly the first attempt - IPython qtconsole is also ~15 years old, and a decade before that TCL tried the same thing (with some success I hear). One possible solution to the expression problem, namely multiple dispatch / multimethods, is a selling point of some new languages, like Raku, Nim, Clojure, and of course Julia. Multimethods are known since the '70s, too, yet not even one mainstream language has them as a feature. There's a lot to be said about the churn on the Web, and I don't want to go there, but from the outside perspective, the only real change that happened sometime in the last decade was Let's Encrypt becoming CA. IPv6 adoption is the same as always, and we still need NAT traversal techniques that we used in the '90s. Other than that, everything people do with JavaScript was already done and tested decades ago. I mean, virtual DOM? That's basically what X windows are, and every other GUI out there does it, with invalidating objects and redrawing only obscured/damaged parts of an object, with double buffering to avoid flickering. The shadow DOM and web components - though I've no idea how widely they are used - make the same promise that vendors made when shipping widgets as DLLs to Object Pascal, later renamed Delphi. The only real progress, other than adopting HTTPS everywhere, was ditching Flash, ActiveX and Java applets. It really tells a lot that the most impressive progress happened because of removing something instead of adding. There's a lot more. I don't want to dismiss the great work of a great many fabulous programmers. The progress is happening at all thanks to them. The average developer, however, is average, and does not have knowledge and skills to write something actually game-changing. They try all the time, though, because it's fun, and then the hype and mob mentality takes over on social media. You could say that machine learning was a great development, but then again - neural networks were described in the '70s. It just so happened that massively parallel GPUs were a good way to speed up otherwise very demanding computations. Computation, might I add, mostly done in Fortran (blas, lapack), to this day. I don't want to dismiss the progress we're seeing. I just wish programmers would actually, seriously study the history of our field before going off to create yet another framework. Despite being short, the history of our field is littered with incredible amounts of prior art, and improving upon that should be the goal, I think, not "rethinking and reimplementing" everything from scratch every 10 years. EDIT: I forgot to answer your question: I only worked with software for all my life, I can't say anything about any other field. Most of them, though, have centuries or millennia of history, and they seem to efficiently manage that legacy, turning it into productivity. Maybe there's less objective need for change there, or in some cases the change is impossible due to regulations? Fields that came into being due to the IT revolution seem to be similarly stuck in change-without-progress cycles. Some social activities are like this, too. It might be simply a feature all young fields have. I'm guessing a lot of early airplanes crashed, some of them because of problems that were solved already elsewhere, but without anyone else knowing. The number/rate of failed software projects is staggering, just as a lot of early flying ended with a crash. I'm not sure there's a meaningful correlation, and I'm way outside of my expertise when talking about planes, but I can't help seeing our field as immature and moving very slowly forward. The blessing in disguise is that this time around, failed project doesn't often mean someone died. [1] https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem

pjc50 4y ago

> why it took them so long to have such feature The demand is not so strong, and the Windows world is extremely used to having bits of dynamic runtime; the entirety of COM, for example. It does illustrate the tug of war that .NET has always struggled with. The things Microsoft want it for within the Windows ecosystem vs the "normal language" running server-side applications on Linux that a lot of the customers want.

pjmlp 4y ago

It is there since .NET 1.0, see NGEN. However it is done at installation time with dynamic linking only. And Mono has had it since ages, used by Unity and Xamarin. This is the porting of UWP .NET Native to mainline .NET.

Shadonototra 4y ago
You miss the point go build and you get 1 portable tiny executable ngen, .net native, mono etc, you need more steps, and you get a folder with a bunch of files and folders that's why these solutions didn't took off
- vips7L 4y ago
  dotnet publish -p:PublishSingleFile=true
  - pjc50 4y ago
    This produces a self-unpacking executable that drops all the assemblies somewhere and then runs it. There can be surprising side effects. https://github.com/dotnet/runtime/issues/59715 https://github.com/dotnet/runtime/issues/59715 And check the small print on your platform as to whether it's really single file not requiring any other dependencies alongside it.
    - vips7L 4y ago
      > This produces a self-unpacking executable that drops all the assemblies somewhere and then runs it. This no longer happens since .net 5.
- pjmlp 4y ago
  You miss the point go build and you get 1 portable tiny executable, provided it is 100% Go code, without any dependency on cgo or OS APIs not packaged into the Go runtime. These solutions did take off, how do you think Unity games for PS, Xbox, Wii, Switch, Windows 10 UWP, and Xamarin apps for iOS/Android get delivered?