3 ms·

Eh... I'd argue against quite a lot of those being "easier" than doing things manually. Docker is a prime example. It's supposedly easier to spin up a docker c

Eh... I'd argue against quite a lot of those being "easier" than doing things manually. Docker is a prime example. It's supposedly easier to spin up a docker container for a basic web server stack, but to be honest I'd rather install PHP/MySQL and an SSL certificate manually, rather than spend time finding a decent container from a trustworthy source, and then spend 20 minutes trying to figure out how and why it's been configured the way it has, etc. etc. Plus there's the need to actually install docker itself and learn how to use it in the first place. Every one of these comes with its own learning curve which isn't always better than just learning how the actual tools underneath work.

unnouinceput 5y ago
So once you did your own trusted setup - who is stopping you to create a docker container to your liking and use that onward? I don't trust anything, hence all my docker containers are created personally and use them moving forward. At first it will seems like it's a never ending job to create another docker, but eventually you'll have all your needs fulfilled. Nowadays it can go a month without needing to create another one since I already did this A+B+C combination in the past.
cm2187 5y ago
In .net, mandatory async/await for new API is also making things that were easy harder. Async introduces multithreading where there wasn’t, breaks call stacks (debugging harder), deadlocks in certain conditions but not others (asp or winform vs console), forces you to handle what happens if the user interacts with the UI before your function is done executing, etc.
- Too 5y ago
  > forces you to handle what happens if the user interacts with the UI before your function is done executing Thank goodness for that. No more of UI suddenly freezing completely and stops accepting input just because internet connection is flaky. Async or other slow operations should not be running on the UI thread.
- kingcharles 5y ago
  This is definitely true. Just trying to download a file can become an async chain hell-hole.. it's asyncs all the way down!
  - jcims 5y ago
    The pain in the chain is mainly in the main().
xxs 5y ago
indeed, concurrency being 'easy', nice one. Concurrency is only 'easy' if there is no shared mutable state.
dimgl 5y ago
I highly disagree here. Within seconds I can have all the technology I want running in a Docker container with little to no setup. Just make a docker-compose.yml file with the services I want, say Postgres and Redis, mount my local folder to a Golang Docker image, and then I just do `docker compose up` and all three are running and communicating with each other with little to no effort.
- flumpcakes 5y ago
  I don't think these points address the original post's points. Specifically they highlighted the issues of _finding_ images to run and having the _knowledge_ on how to use these tools in the first place for abstraction.
- bonoboTP 5y ago
  Thats how you get people who have no idea what the underlying tools can do and bloat the high level abstraction. Complexity has to go somewhere. If something is easier, something else is harder. These things may make the bog standard use case easy but woe to you if you ever try to go another path or change something. Then you need to figure out if the abstraction layer allows you to tweak the underlying software layer, or invent your own way of reaching into that layer which may break when any update comes in a higher layer etc. Its more learning upfront to get familiar with the basic Linux tools and services, but it is very versatile and flexible and will stay mostly the same for decades.
  - axiosgunnar 5y ago
    I understand you manually manage the kernel and wrote your own TCP library? I sure hope you didn‘t just pass all of that complexity down!
    - bonoboTP 5y ago
      There are well designed abstractions that are helpful. It's very hard to come up with them. Mycrotoque aims at those who quickly jump to introduce new abstractions into their workflow before they understand what they are doing. It very often results in pain. It helps in the short term, because you are up and running faster but these shiny new frameworks are often immature and, like Potemkin villages, only look good from the correct angle, and have no meat. Once you try to use them for custom scenarios, you end up having to route around the abstraction layer because it wasn't designed so well. To take an example outside of cloud management etc, in deep learning frameworks: there were competing libraries some years ago: caffe, theano, tensorflow etc. François Chollet decided to create an abstraction layer that could unify multiple low level frameworks. Called Keras. Did it work? No. Because the different implementations were different enough that they couldn't usefully be coerced under the same abstraction layer. I mean it worked for some time, to some extent. But very soon after, they dropped support for anything but Tensorflow. Creating good abstractions is very hard especially if the underlying layer is unstable and gets big conceptual changes. With kernels it's not the case. We've had them in similar Form for like half a century.
paulnpace 5y ago
I don't have any issues with containers, but it seems like many newer projects in the last five years or so the developers are nearly exclusively developing for containers. My current impression is this violates the spirit of POSIX, because figuring out configurations without containers can become a non-trivial effort, especially for those of us who have not yet learned how to configure containers.

unnouinceput 5y ago

So once you did your own trusted setup - who is stopping you to create a docker container to your liking and use that onward? I don't trust anything, hence all my docker containers are created personally and use them moving forward. At first it will seems like it's a never ending job to create another docker, but eventually you'll have all your needs fulfilled. Nowadays it can go a month without needing to create another one since I already did this A+B+C combination in the past.

cm2187 5y ago

In .net, mandatory async/await for new API is also making things that were easy harder. Async introduces multithreading where there wasn’t, breaks call stacks (debugging harder), deadlocks in certain conditions but not others (asp or winform vs console), forces you to handle what happens if the user interacts with the UI before your function is done executing, etc.

Too 5y ago
> forces you to handle what happens if the user interacts with the UI before your function is done executing Thank goodness for that. No more of UI suddenly freezing completely and stops accepting input just because internet connection is flaky. Async or other slow operations should not be running on the UI thread.
kingcharles 5y ago
This is definitely true. Just trying to download a file can become an async chain hell-hole.. it's asyncs all the way down!
- jcims 5y ago
  The pain in the chain is mainly in the main().

xxs 5y ago

indeed, concurrency being 'easy', nice one. Concurrency is only 'easy' if there is no shared mutable state.

dimgl 5y ago

I highly disagree here. Within seconds I can have all the technology I want running in a Docker container with little to no setup. Just make a docker-compose.yml file with the services I want, say Postgres and Redis, mount my local folder to a Golang Docker image, and then I just do `docker compose up` and all three are running and communicating with each other with little to no effort.

flumpcakes 5y ago
I don't think these points address the original post's points. Specifically they highlighted the issues of _finding_ images to run and having the _knowledge_ on how to use these tools in the first place for abstraction.
bonoboTP 5y ago
Thats how you get people who have no idea what the underlying tools can do and bloat the high level abstraction. Complexity has to go somewhere. If something is easier, something else is harder. These things may make the bog standard use case easy but woe to you if you ever try to go another path or change something. Then you need to figure out if the abstraction layer allows you to tweak the underlying software layer, or invent your own way of reaching into that layer which may break when any update comes in a higher layer etc. Its more learning upfront to get familiar with the basic Linux tools and services, but it is very versatile and flexible and will stay mostly the same for decades.
- axiosgunnar 5y ago
  I understand you manually manage the kernel and wrote your own TCP library? I sure hope you didn‘t just pass all of that complexity down!
  - bonoboTP 5y ago
    There are well designed abstractions that are helpful. It's very hard to come up with them. Mycrotoque aims at those who quickly jump to introduce new abstractions into their workflow before they understand what they are doing. It very often results in pain. It helps in the short term, because you are up and running faster but these shiny new frameworks are often immature and, like Potemkin villages, only look good from the correct angle, and have no meat. Once you try to use them for custom scenarios, you end up having to route around the abstraction layer because it wasn't designed so well. To take an example outside of cloud management etc, in deep learning frameworks: there were competing libraries some years ago: caffe, theano, tensorflow etc. François Chollet decided to create an abstraction layer that could unify multiple low level frameworks. Called Keras. Did it work? No. Because the different implementations were different enough that they couldn't usefully be coerced under the same abstraction layer. I mean it worked for some time, to some extent. But very soon after, they dropped support for anything but Tensorflow. Creating good abstractions is very hard especially if the underlying layer is unstable and gets big conceptual changes. With kernels it's not the case. We've had them in similar Form for like half a century.

paulnpace 5y ago

I don't have any issues with containers, but it seems like many newer projects in the last five years or so the developers are nearly exclusively developing for containers. My current impression is this violates the spirit of POSIX, because figuring out configurations without containers can become a non-trivial effort, especially for those of us who have not yet learned how to configure containers.