4 ms·

I don’t think any non-gc language is trivial to learn, C also. Manual memory management is hard, and either you learn from the system (C way) or learn it upfron

I don’t think any non-gc language is trivial to learn, C also. Manual memory management is hard, and either you learn from the system (C way) or learn it upfront from the language (Rust way), it’s still the same amount of concept you have to digest to write practical software.

tannhaeuser 8y ago
That's true, but the original idea of Unix is to have many small program invocations work together, not to erect a monolithical long running daemon that does it all in a single address space. Memory management for one-shot command line apps isn't hard at all and can often get away with static allocations. Even if you're screwing up your heap, process isolation will take care of recycling memory when your program terminates.
- dannypgh 8y ago
  Eh, that's the original idea of the Unix shell, sure. But Unix has many ideas. Long running daemons have been a part of Unix systems since the beginning.
  - tannhaeuser 8y ago
    BSD 4.3 introduced inetd along with TCP/IP to mainstream Unix. Quoting from [1]: > When a TCP packet or UDP packet arrives with a particular destination port number, inetd launches the appropriate server program to handle the connection. For services that are not expected to run with high loads, this method uses memory more efficiently, since the specific servers run only when needed. Furthermore, no network code is required in the service-specific programs, as inetd hooks the sockets directly to stdin, stdout and stderr of the spawned process. [1]: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd
    - dannypgh 8y ago
      I'm familiar with inetd, but I don't understand your point. Unix is more than a dozen years older than 4.3BSD. Claiming that long lived daemons is somehow anti-Unix is absurd. Just ask init or getty.
      - tannhaeuser 8y ago
        My point was that the idea of small, self-contained apps that do one thing, and do it well, was in no way limited to shell programming. Init and getty are small, self-contained system demons that are part of the O/S rather than application servers inviting long-running, single address-space processes for business logic.
- sfifs 8y ago
  Many small programs simply doesn't scale to the modern web when just the baggage associated with spinning up processes will kill you at any reasonable load. UNIX has nice ideas but recognise they were founded in the shared computer between a few dozen users environment of the 70s, not a web server serving thousands of requests a second of today
  - tonyarkles 8y ago
    Isn't this basically what "serverless" is?
    - sedachv 8y ago
      Great observation. And in fact "serverless" is the way that Unix network servers used to work: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd CGI is also the way the web used to work. Spawning processes has only gotten faster since then. The entire "process spawning doesn't scale to the modern web" argument is completely and totally bogus. Today, spawning a process in Linux is only 10-20 microseconds slower than creating a thread: http://www.bitsnbites.eu/benchmarking-os-primitives/ http://www.bitsnbites.eu/benchmarking-os-primitives/ The performance problems are elsewhere.
      - sfifs 8y ago
        What you are missing here is the fact that I/O is orders of magnitude slower than processor. Most of the time in servers is spent waiting for I/O and multiplexing green threads on processes without context switches while some execution paths are waiting on I/O gives you far higher capacity on the same hardware. See the other comment thread on GP comment.
    - sfifs 8y ago
      serverless is primarily a decentralisation/small-scale/unpredictable workloads play where you trade off fixed costs of managing a dedicated instance for higher variable per call cost. At any reasonable scale and predictability, running a dedicated server is cheaper. The folks who started at a small scale in serverless but see traffic growing and kind of are in the middle space before jumping to dedicated servers have an entire art form of keeping their functions "hot" since both Lambda and AppEngine actually keep your functions hot loaded when once it's spun up for some time. https://www.google.com.sg/search?q=serverless+warm+up&oq=serverless+warm+up https://www.google.com.sg/search?q=serverless+warm+up&oq=ser...
addicted 8y ago
It’s not just that C is hard. I can wrangle together pretty much any program in C since I used to program in C about a decade ago. However, having been so long, my greatest fear is that I wouldn’t even be aware of the footguns I have introduced in my code. C is littered with best practices which are absolutely not obvious, and unless you follow them can be massive security risks. And to a slightly lesser extent the same is true of C++ as well (although my friends tell me newer versions of C++ are much better at this. I worked with versions prior to C++11).
pjmlp 8y ago
The Basics, Pascal, Modula-2 linages are surely relatively easy to learn, while preventing 90% of the typical class of C errors.

tannhaeuser 8y ago

That's true, but the original idea of Unix is to have many small program invocations work together, not to erect a monolithical long running daemon that does it all in a single address space. Memory management for one-shot command line apps isn't hard at all and can often get away with static allocations. Even if you're screwing up your heap, process isolation will take care of recycling memory when your program terminates.

dannypgh 8y ago
Eh, that's the original idea of the Unix shell, sure. But Unix has many ideas. Long running daemons have been a part of Unix systems since the beginning.
- tannhaeuser 8y ago
  BSD 4.3 introduced inetd along with TCP/IP to mainstream Unix. Quoting from [1]: > When a TCP packet or UDP packet arrives with a particular destination port number, inetd launches the appropriate server program to handle the connection. For services that are not expected to run with high loads, this method uses memory more efficiently, since the specific servers run only when needed. Furthermore, no network code is required in the service-specific programs, as inetd hooks the sockets directly to stdin, stdout and stderr of the spawned process. [1]: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd
  - dannypgh 8y ago
    I'm familiar with inetd, but I don't understand your point. Unix is more than a dozen years older than 4.3BSD. Claiming that long lived daemons is somehow anti-Unix is absurd. Just ask init or getty.
    - tannhaeuser 8y ago
      My point was that the idea of small, self-contained apps that do one thing, and do it well, was in no way limited to shell programming. Init and getty are small, self-contained system demons that are part of the O/S rather than application servers inviting long-running, single address-space processes for business logic.
sfifs 8y ago
Many small programs simply doesn't scale to the modern web when just the baggage associated with spinning up processes will kill you at any reasonable load. UNIX has nice ideas but recognise they were founded in the shared computer between a few dozen users environment of the 70s, not a web server serving thousands of requests a second of today
- tonyarkles 8y ago
  Isn't this basically what "serverless" is?
  - sedachv 8y ago
    Great observation. And in fact "serverless" is the way that Unix network servers used to work: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd CGI is also the way the web used to work. Spawning processes has only gotten faster since then. The entire "process spawning doesn't scale to the modern web" argument is completely and totally bogus. Today, spawning a process in Linux is only 10-20 microseconds slower than creating a thread: http://www.bitsnbites.eu/benchmarking-os-primitives/ http://www.bitsnbites.eu/benchmarking-os-primitives/ The performance problems are elsewhere.
    - sfifs 8y ago
      What you are missing here is the fact that I/O is orders of magnitude slower than processor. Most of the time in servers is spent waiting for I/O and multiplexing green threads on processes without context switches while some execution paths are waiting on I/O gives you far higher capacity on the same hardware. See the other comment thread on GP comment.
  - sfifs 8y ago
    serverless is primarily a decentralisation/small-scale/unpredictable workloads play where you trade off fixed costs of managing a dedicated instance for higher variable per call cost. At any reasonable scale and predictability, running a dedicated server is cheaper. The folks who started at a small scale in serverless but see traffic growing and kind of are in the middle space before jumping to dedicated servers have an entire art form of keeping their functions "hot" since both Lambda and AppEngine actually keep your functions hot loaded when once it's spun up for some time. https://www.google.com.sg/search?q=serverless+warm+up&oq=serverless+warm+up https://www.google.com.sg/search?q=serverless+warm+up&oq=ser...

addicted 8y ago

It’s not just that C is hard. I can wrangle together pretty much any program in C since I used to program in C about a decade ago. However, having been so long, my greatest fear is that I wouldn’t even be aware of the footguns I have introduced in my code. C is littered with best practices which are absolutely not obvious, and unless you follow them can be massive security risks. And to a slightly lesser extent the same is true of C++ as well (although my friends tell me newer versions of C++ are much better at this. I worked with versions prior to C++11).

pjmlp 8y ago

The Basics, Pascal, Modula-2 linages are surely relatively easy to learn, while preventing 90% of the typical class of C errors.