6 ms·

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

IgorPartola 11y ago
So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's written in, if it's done well. If it's done poorly, I am much more likely to look for better alternatives than to fix it (if only I had about 240 hours in a day...), so what's the advantage? To me, an advantage in usability is having a PPA with properly built .deb packages. If I have to use a language-specific package manager that I don't already use regularly, you've likely lost me, unless I really need this functionality. If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. I am much less likely to use this in any type of "production" environment if I have to maintain those pieces myself. Running things in a screen session is so "I'm running a Minecraft server". That is not to criticize your work. You've done a great job! serve2d looks very interesting and I might actually have to give it a try sometime.
- rogerbinns 11y ago
  Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.
  - cpach 11y ago
    As I alluded to below, the power of this feature should probably not be underestimated.
  - boomzilla 11y ago
    Believe it or not, you can freeze binaries for python apps too, if you like: https://wiki.python.org/moin/Freeze https://wiki.python.org/moin/Freeze
    - rogerbinns 11y ago
      I've done it for Windows, Linux and Mac before. Note that these solutions freeze the Python side of things but do not freeze the platform side. For example they do not include the system libraries. Consequently running the frozen python app on a system that is a different distro, older or newer OS version, or has different system packages installed often leads to the frozen python app not being able to start. Slide 19 of this if you are interested: http://www.bitpim.org/papers/baypiggies/siframes.html http://www.bitpim.org/papers/baypiggies/siframes.html
  - wakaflockafliz 11y ago
    @boomzilla: Go head and try it IRL. It's a huge PITA and there are plenty of gotchas.
  - poizan42 11y ago
    That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.
    - rogerbinns 11y ago
      Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
      - poizan42 11y ago
        Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
        rogerbinns 11y ago
        Because it is the normal, and only way for Go. Static linking isn't as easy for other language platforms, as some issues crop up (a google/SO search shows many questions). Often it is as simple as not having the static libraries available, or having difficulty linking with them because they still want to dynamically load other libraries. ie other languages may not work, is less tested, and not normally done.
        joushou 11y ago
        The original authors of dynamic linking concluded that the cost was way higher than the benefits, both in memory usage and general performance, but the client demanded it. Dynamic linking is the number one binary compatibility issue on Linux. Go 1.5 has mechanisms for dynamic linking, though.
    - marssaxman 11y ago
      The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order to manage it. The industry progressed, storage capacity grew dramatically, and executable sizes stopped mattering, but the use of shared libraries / DLLs continued out of inertia. As time passed, people started asking - why are we doing all this? And some of them invented a reason, which was the idea that one could swap out pieces of existing executables after installation, and thereby fix security problems in an application without needing to involve the application's developer in the process. This works about as well as you'd expect if you had spent years trying to fit all the rough edges of various third-party libraries together with varying degrees of success, but the idea caught on as a popular post-hoc justification for the huge layer of complexity we're all continuing to maintain long after its original justification became obsolete. As is no doubt obvious from my tone, I'm not buying it and am very happy to see signs of a pendulum-swing back toward static linking and monolithic executables.
- rakoo 11y ago
  The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means: - no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard way to retrieve dependencies and build the binary. (Much like the standard way of doing things in C would be ./configure && make && make install, with the added bonus point that the dependencies are also taken into account). This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower - no more having to deal with dependencies at runtime, because each binary has everything it needs inside of itself. In practice this means "scp as a deploying method". It's an even lower common denominator than packages. > If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. This is orthogonal to the choice of programming language, though. On top of that, I believe the application shouldn't deal with forking, it's the job of your supervision system to deal with daemons. All an application has to do is log whatever happens on STDERR and let the system handle that.
  - veeti 11y ago
    > This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower Static linking and bundling of dependencies is a no-no in most distributions. If anything, the Go model is a headache for package maintainers to deal with.
  - pmelendez 11y ago
    > no more having to deal with dependencies at runtime So, it is the same that linking the libraries statically? C and C++ has done that like since forever.
    - StavrosK 11y ago
      Hey, if you said "written in C", I would be similarly excited about its ease of deployment.
- rektide 11y ago
  A staid, solid, conservative outlook, a good perspective for others to realize is out there. I would say that concerns like daemon mode and logging are a lot less in vogue these days- a program ought concern itself with running, and outputting to stdout, and if you have needs past these it's expected you have tooling you can deploy that makes that happen. Daemonization is at least a fairly standard feature, but with logging there's so many people with such varied concerns that getting fancy, trying to meet people's many needs, can lead to a lot of program bloat very quickly. Instead of going at these on a case-by-case basis, and now that we are more container-centric, it makes sense to run in the foreground and put your output on stdout, let the rest of the system support that utterly uncomplex pattern.
- wpietri 11y ago
  I think the the "100% Go" stuff is appealing in that you just have one file that works across OSes, with minimal screwing around. For things that become part of the OS, yes, I'd rather they come via some install approach that includes the necessary integration. But for anything else, I think a lot of our packaging approaches are dedicated to saving disk space and RAM, which is something that matters way less to me now than it did 15-20 years ago when CPAN and APT were designed. In 2000, disk prices were circa $10/GB [1]; now we're looking at $0.50/GB of zippy SSD [2] or $0.03/GB of spinning rust [3]. RAM is similarly about 2 orders of magnitude cheaper. [4] Given that, it makes a lot more sense to burn space to minimize the chance of a library version conflict or other packaging issue. Another thing that has changed greatly is the pace of updates. 15-20 years ago, weekly releases sounded impossible to most. Now it's common, and some places are releasing hourly or faster. [5] Thanks to things like GitHub, the whole notion of a release is getting hazy: I see plenty of things where you just install from the latest; every merge to master is in effect a new release. Given that, I think both Go and Docker are pioneering approaches that are much more in sync with the current computing environment. I'm excited to see where they get to. [1] http://www.mkomo.com/cost-per-gigabyte-update http://www.mkomo.com/cost-per-gigabyte-update [2] http://techreport.com/review/27824/crucial-bx100-and-mx200-solid-state-drives-reviewed/7 http://techreport.com/review/27824/crucial-bx100-and-mx200-s... [3]http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&IsNodeId=1&N=100007603%20600083978 http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Is... [4] http://www.jcmit.com/mem2015.htm http://www.jcmit.com/mem2015.htm [5] www.slideshare.net/InfoQ/managing-experimentation-in-a-continuously-deployed-environment slide 27
- viraptor 11y ago
  I think we're learning pretty quickly that 100% Go (or Rust, or Python, or Perl, or OCaml, or ...) is a good idea for security. Especially is you're dispatching between ssh and ssl services. Go has advantage over scripting in speed, over C/C++ in memory management, over strict FP languages in popularity, and over Rust in being stable and known for longer.
cpach 11y ago
”This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)” Great! This seems to be a very good Selling Point for go!
Hello71 11y ago
previously: https://github.com/JamesDunne/sslmux https://github.com/JamesDunne/sslmux
- wakaflockafliz 11y ago
  That looks like a start but implements only a fraction of the usefulness.

That is certainly part of the inspiration and legacy behind serve2d. This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)

IgorPartola 11y ago

So here's what hopefully won't be considered a trolling question: I have seen a lot of "100% Go" projects over the past several years and that's usually presented as a big feature. Some pretty trivial things have been redone as brand new in Go, and then suddenly gain lots of attention. What is so magical about a project written in Go vs C, Python, Ruby, Rust, JS, etc.? As a user of the software I won't care what it's written in, if it's done well. If it's done poorly, I am much more likely to look for better alternatives than to fix it (if only I had about 240 hours in a day...), so what's the advantage? To me, an advantage in usability is having a PPA with properly built .deb packages. If I have to use a language-specific package manager that I don't already use regularly, you've likely lost me, unless I really need this functionality. If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. I am much less likely to use this in any type of "production" environment if I have to maintain those pieces myself. Running things in a screen session is so "I'm running a Minecraft server". That is not to criticize your work. You've done a great job! serve2d looks very interesting and I might actually have to give it a try sometime.

rogerbinns 11y ago
Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.
- cpach 11y ago
  As I alluded to below, the power of this feature should probably not be underestimated.
- boomzilla 11y ago
  Believe it or not, you can freeze binaries for python apps too, if you like: https://wiki.python.org/moin/Freeze https://wiki.python.org/moin/Freeze
  - rogerbinns 11y ago
    I've done it for Windows, Linux and Mac before. Note that these solutions freeze the Python side of things but do not freeze the platform side. For example they do not include the system libraries. Consequently running the frozen python app on a system that is a different distro, older or newer OS version, or has different system packages installed often leads to the frozen python app not being able to start. Slide 19 of this if you are interested: http://www.bitpim.org/papers/baypiggies/siframes.html http://www.bitpim.org/papers/baypiggies/siframes.html
- wakaflockafliz 11y ago
  @boomzilla: Go head and try it IRL. It's a huge PITA and there are plenty of gotchas.
- poizan42 11y ago
  That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.
  - rogerbinns 11y ago
    Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
    - poizan42 11y ago
      Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
      - rogerbinns 11y ago
        Because it is the normal, and only way for Go. Static linking isn't as easy for other language platforms, as some issues crop up (a google/SO search shows many questions). Often it is as simple as not having the static libraries available, or having difficulty linking with them because they still want to dynamically load other libraries. ie other languages may not work, is less tested, and not normally done.
      - joushou 11y ago
        The original authors of dynamic linking concluded that the cost was way higher than the benefits, both in memory usage and general performance, but the client demanded it. Dynamic linking is the number one binary compatibility issue on Linux. Go 1.5 has mechanisms for dynamic linking, though.
  - marssaxman 11y ago
    The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order to manage it. The industry progressed, storage capacity grew dramatically, and executable sizes stopped mattering, but the use of shared libraries / DLLs continued out of inertia. As time passed, people started asking - why are we doing all this? And some of them invented a reason, which was the idea that one could swap out pieces of existing executables after installation, and thereby fix security problems in an application without needing to involve the application's developer in the process. This works about as well as you'd expect if you had spent years trying to fit all the rough edges of various third-party libraries together with varying degrees of success, but the idea caught on as a popular post-hoc justification for the huge layer of complexity we're all continuing to maintain long after its original justification became obsolete. As is no doubt obvious from my tone, I'm not buying it and am very happy to see signs of a pendulum-swing back toward static linking and monolithic executables.
rakoo 11y ago
The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means: - no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard way to retrieve dependencies and build the binary. (Much like the standard way of doing things in C would be ./configure && make && make install, with the added bonus point that the dependencies are also taken into account). This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower - no more having to deal with dependencies at runtime, because each binary has everything it needs inside of itself. In practice this means "scp as a deploying method". It's an even lower common denominator than packages. > If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. This is orthogonal to the choice of programming language, though. On top of that, I believe the application shouldn't deal with forking, it's the job of your supervision system to deal with daemons. All an application has to do is log whatever happens on STDERR and let the system handle that.
- veeti 11y ago
  > This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower Static linking and bundling of dependencies is a no-no in most distributions. If anything, the Go model is a headache for package maintainers to deal with.
- pmelendez 11y ago
  > no more having to deal with dependencies at runtime So, it is the same that linking the libraries statically? C and C++ has done that like since forever.
  - StavrosK 11y ago
    Hey, if you said "written in C", I would be similarly excited about its ease of deployment.
rektide 11y ago
A staid, solid, conservative outlook, a good perspective for others to realize is out there. I would say that concerns like daemon mode and logging are a lot less in vogue these days- a program ought concern itself with running, and outputting to stdout, and if you have needs past these it's expected you have tooling you can deploy that makes that happen. Daemonization is at least a fairly standard feature, but with logging there's so many people with such varied concerns that getting fancy, trying to meet people's many needs, can lead to a lot of program bloat very quickly. Instead of going at these on a case-by-case basis, and now that we are more container-centric, it makes sense to run in the foreground and put your output on stdout, let the rest of the system support that utterly uncomplex pattern.
wpietri 11y ago
I think the the "100% Go" stuff is appealing in that you just have one file that works across OSes, with minimal screwing around. For things that become part of the OS, yes, I'd rather they come via some install approach that includes the necessary integration. But for anything else, I think a lot of our packaging approaches are dedicated to saving disk space and RAM, which is something that matters way less to me now than it did 15-20 years ago when CPAN and APT were designed. In 2000, disk prices were circa $10/GB [1]; now we're looking at $0.50/GB of zippy SSD [2] or $0.03/GB of spinning rust [3]. RAM is similarly about 2 orders of magnitude cheaper. [4] Given that, it makes a lot more sense to burn space to minimize the chance of a library version conflict or other packaging issue. Another thing that has changed greatly is the pace of updates. 15-20 years ago, weekly releases sounded impossible to most. Now it's common, and some places are releasing hourly or faster. [5] Thanks to things like GitHub, the whole notion of a release is getting hazy: I see plenty of things where you just install from the latest; every merge to master is in effect a new release. Given that, I think both Go and Docker are pioneering approaches that are much more in sync with the current computing environment. I'm excited to see where they get to. [1] http://www.mkomo.com/cost-per-gigabyte-update http://www.mkomo.com/cost-per-gigabyte-update [2] http://techreport.com/review/27824/crucial-bx100-and-mx200-solid-state-drives-reviewed/7 http://techreport.com/review/27824/crucial-bx100-and-mx200-s... [3]http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&IsNodeId=1&N=100007603%20600083978 http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Is... [4] http://www.jcmit.com/mem2015.htm http://www.jcmit.com/mem2015.htm [5] www.slideshare.net/InfoQ/managing-experimentation-in-a-continuously-deployed-environment slide 27
viraptor 11y ago
I think we're learning pretty quickly that 100% Go (or Rust, or Python, or Perl, or OCaml, or ...) is a good idea for security. Especially is you're dispatching between ssh and ssl services. Go has advantage over scripting in speed, over C/C++ in memory management, over strict FP languages in popularity, and over Rust in being stable and known for longer.

cpach 11y ago

”This advantages of serve2 is that it is 100% go and can be integrated and used without any extra dependencies or multi-setup :)” Great! This seems to be a very good Selling Point for go!

Hello71 11y ago

previously: https://github.com/JamesDunne/sslmux https://github.com/JamesDunne/sslmux

wakaflockafliz 11y ago
That looks like a start but implements only a fraction of the usefulness.