A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Yea, nothing is full proof; anything can go down, doesn't mean its not a viable option. When config variables are updated, they keep the same entry point ex. config/DB_PASSWORD/v1. Only the value is changed, this is how an paper trail is kept.
When that .env is updated the updated has full access to all secrets, no matter how secure that file is nothing will change that. My point wasn't that the file couldn't be stored properly.
The creaters of dotenv tell you not to commit it in your repo. Look below, tons of comments say the sme thing.
Summary
Please re-read the article, your points are not aligning with what I was saying. Yea its widely adopted, but change takes time.
Crazy and passionate Front-end Developer. In love with the details of app-dev. Always eager to bring ❤️ to the world in the shape of software and knowledge 😺
Location
Stuttgart, Germany
Education
14 years of autonomous learning of software architecture for web and smart home development
I have read the article. I am very certain I understand what you propose. It does not work for the environments I work with and I know I am not alone. For the regular self hosted app running on a virtual private server, I would argue you also won't have a need for config servers.
I build industrial applications in demilitarized zones - low trust environments. The customer decides when to go online. We can't expect that an internet connection is there all the time unlike in a cloud application. Not when setting up the software, not when starting the software and also not when updating the software.
This is not a hobby project and it really misses a lot of tooling that yet has to be invented. Because neither docker, k8s or any tooling helps you in continuously rolling out your applications and updates to non-cloud environments. You need to have a very narrow Google-esque vision to assume every app is deployed, managed and run by some cloud.
The problem is a whole lot bigger than ".env files are not secure and don't version". There is a huge gap between the tooling and infrastructure a cloud provides, and the mostly self-baked solutions you have to apply for every tier below that. Docker and docker-compose does work for deploying, but there is an entire slew of tooling that we lack to properly update and version applications that don't run in the cloud.
You mostly have 3 ways of running your apps:
In the Cloud you probably have your complete kubernetes cluster and the entire infrastructure needed to run, monitor, update, version control and deploy your app and its dependencies. There you probably don't have a need for .env files. Even static site cloud hosts like netlify allow you to tune the env from a web ui.
On a virtual private server you have to come up with your own infrastructure. You can't expect everyone to run k8s for a business application. Even then, having too many moving parts can kill your software, as I outlined in my previous post. If I can avoid having a separate runtime dependency, I will avoid it.
All other external systems - A git repository, a CI server, a public key infrastructure, a letsencrypt ssl service, a monitoring service are all optional by design. You can still deploy an app if your CI server gets down. You can still build and package the software locally if your git repo is down. You just don't get monitoring data if sentry is down - the app will continue to run. A certificate will be stored locally and make your app at least secure for ~3 months. But your app won't even start, if your config server is not reachable or has other problems. Even for VPS I would use an .env file.
On bare metal - hardware demilitarized zones and low trust environments are very valid use cases for IoT or public service applications - Both industrial and homebrewn (e.g. smart home). You can't expect that the customer connects to the internet only to get some env vars when starting, installing or updating their app. And I also wouldn't recommend a nuclear power plant to connect to the internet - no matter how secure your communication is. Even for modern industries, sensor data is sacred and they want to very tightly control when software is allowed to synchronize its data with some cloud application. Your across-the-board suggestions "stop using .env files" stops to work here completely.
For Development For development and for documentation, .env files are still great. Setting environment variables for development on windows is a nightmare. In Linux you can at least do DB_PORT=3306 DB_HOST=whatever.com npm run start. But it still convoluted for development. Try to convey what environment variables are needed for your app in order to run to your coworkers. An .env file will document and communicate just that - a set of env vars required for your app to run. Configurable in one place.
We are very far away from having best practices or tools for running software on non-cloud environments.
Docker and compose make it easier, by having predictable deployments. But everything between is left as an exercise to the developer/devops guy deploying the application.
Before I start to figure out how to get rid of a well working tool like .env, I'd rather find out how to fill in the gap of all the missing tooling. Nx is a good job in providing better building tools, combining a slew of independent tools to make build less painful. GitLab is collapsing more and more tools into one tool - since we have experienced in the past years that running and combining a separate repository, a separate CI and a separate container registry is painful. I'd bet my money on these guys.
Crazy and passionate Front-end Developer. In love with the details of app-dev. Always eager to bring ❤️ to the world in the shape of software and knowledge 😺
Location
Stuttgart, Germany
Education
14 years of autonomous learning of software architecture for web and smart home development
Web and Software Frontend Developer. Used to work in Full-stack JavaScript.Been at this for a few years now, and think I now understand my specific domain pretty well. Still a lot to learn though.
Location
Manchester, UK
Education
Web Systems Design BSc at Sheffield Hallam University, Sheffield, UK
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Hard to believe that when most of my responses are well typed and counter-points, and most of who disagrees are the ones who assume I'm wrong, haven't read it, and don't listen.
Recently, I've decided to leave this article in the past for now. Take care!
Web and Software Frontend Developer. Used to work in Full-stack JavaScript.Been at this for a few years now, and think I now understand my specific domain pretty well. Still a lot to learn though.
Location
Manchester, UK
Education
Web Systems Design BSc at Sheffield Hallam University, Sheffield, UK
From what I understand , he's more like talking about a file-based config management solution, with git-based version control, meaning a dedicated private git service to manage the config file versions not exposed to outside access, that is quite different from "commit it in your repo" which means more about committing it in your application code repo.
Also you can easily have a system that automatically merge multiple config files into one .env file, which should not be directly accessible to anyone, so people updating the individual config files won't have access to configs in other files.
Like I said, you can have a file-based solution that achieves more or less the same goals as a database-based solution, which may be easier or harder to implement depending on your specific situation and needs. After all, databases are file-based solutions themselves, they too store data in files (well, some store non-persistent data in memory, but you get the idea :P )
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Sounds interesting but still opening one .env exposes all secrets in it. A config server mitigates that risk while giving feature like audit logs and automatic secret rotation.
You also get the benefit of a ui if you care about that.
The point is in such a file-based config management solution no one should be able to directly open the .env file, it should be dynamically generated and managed by the system, more akin to a "flat database file" if you like to think that way. And features like audit logs and automatic secret rotation can be implemented with no more than a couple dozen lines of code, without the need of a config server. Like I said, the main point of your post is actually not about "config servers" (albeit you are advocating their usage), but rather about storing the config data in remote databases vs. local files/environments.
And the existence of a UI can be a pro or con in the case of config administration depending on specific needs. It's also quite trivial to setup a simple database admin UI if you decide to store config data in remote databases anyway.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Honestly at this point you are just implementing a config server yourself. Every feature I mention you are saying just write it. If that's what you want to do by all means. We can agree to meet in the middle at this point.
That means you can just implement a file-based "config server" with .env files, and your "config server" itself would also use .env files for config, and it could have better security, cleaner code, and maybe even easier and faster to implement than trying to deploy and adapt to use one of those enormous "config servers" you mentioned in the post depending on your particular needs.
Which is exactly the point:
1) .env files (or config files in general) based config management solutions are not inherently worse than those based on remote databases. Don't just blindly diss config file based systems in favor of those based on remote databases, they both have their pros and cons, and one may be improved very easily over the other depending on your particular needs.
2) for experienced devops, it's usually quite trivial to implement a bespoke config management system for things like config versioning, sharing and access control, and it could likely be the preferred way over using one of those enormous "config server" with tons of code and myriads of dependencies.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Yea, just like you can implement a no sql database with json files, we have tools built for various use-cases. How do you know config servers are enormous, have you used or checked one out? How is tons of code a useful measurement in this conversation again?
All these features you are saying that are trivial to mention can also grow into these "enormous" config servers you keep mentioning. OOOR you can use an already established and battle-tested implementation to avoid introducing the very bugs you are talking about.
And not to be rude, but how much experience do you have?
I have checked the "config server" you mentioned in the post,, it has hundreds of dependencies and more than 600k lines of code, which is really ENORMOUS considering the fact that only several hundreds of lines of code are needed to realize the features you mentioned most in the post.
log4j was established and battle-tested, struts2 was established and battle-tested, and when there are orders of magnitude of difference in the amount of code involved, then it's a useful measurement. When it comes to managing important sensitive data like passwords in devops, I'd always trust 600 lines of code written by myself with a handful dependencies than 600k lines of code written by other people with 500 dependencies, when they basically serve the same goals for my particular needs.
And nope a simple bespoke config management solution is next to impossible to grow into those enormous config servers, for example if you code a simple server with koa and several self-made middlewares for your particular needs, it will never grow anywhere near the size of Spring or Rails. From what your post suggests, using a "config server" with 600k lines of code and 500 dependencies just to address pain points like version control, config sharing, access control, data encryption and secret rotation kind of stuff, that sounds like you wanting to deploy an entire Spring Cloud infrastructure just to serve a simple website. Or like wanting to use a NoSQL database when a plain JSON file is more than sufficient to store your data.
And like I said, the solutions to those pain points mentioned in your post is really not about config servers vs. dotenv files, but more about centralized remote databases vs. local config files.
I'll just say I have lead teams of devops with 5 to 10 years of experience, using many kinds of configuration management solutions across various projects of various sizes, from simple bespoke solutions based on config files and/or centralized databases, to distributed systems based on things like zookeeper, and tools for k8s, etc. From what I can see, those "config servers" mentioned in your post are simply WAY overkill as replacements for some config files to just address those handful pain points you mentioned in the post.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Again. WHY DO YOU KEEP BRINGING UP LINES OF CODE AS A METRIC OF USEFULNESS??
About half of HashiCorp Vault's code is unit, system, and integration tests.
They thoroughly test the front-end and the back-end. And to take it a step forward they have end-to-end tests and acceptance tests.
Tests written to avoid these "vulnerbilities" that you keep preaching have multiple lines of code create.
Ok then you can write a config server yourself if you are scared of vulernerbilities. While you are at it MySQL has a vulnerbility back in May so you might want to write your own database engine while your at it.
Also, Chrome just recently had a vulnerbility too. Don't forget to build a while web browser as well. Actually, Dev.to has a bug page, yikes you might wanna re-write this website too.
I mentioned in the article that config servers are usually accessed form VPCs so even if one of those "hundreds of dependencies" has a bug, the config server is protected from the internet.
Also I find what your saying kinda funny.
If a project uses tons of dependencies, then the project is bad. Instead, if they write the features by hand which increases the lines of code, that also makes the project bad.
You really need to read what others' saying before replying completely irrelevant things. If I just need to store 1k of data, I'll not use MySQL, I'll just use a JSON file. If I just want to download a file, I'll not use Chrome, I'll just use curl or wget. You must have some serious problems with your eyes IF you can't properly read what others write.
I clearly said those handful of pain points you mentioned in your post does NOT require those enormous "config servers" to address. Those are some simple goals achievable with some very simple config management solutions based on config files, or if you want, with centralized databases, which may take even less time and easier to implement than deploying and adapting to one of those "config servers" mentioned in your post. If you want to call such simple config management solutions "config servers" too, fine. I guess you can call both koa and Spring as "web frameworks", but their differences are huge.
Like I said, using one of those enormous "config servers" to address those pain points mentioned in your post is like deploying an entire Spring Cloud infrastructure to just serve a simple website with features that can be done by using just koa and a handful simple self-made middlewares. Yes you can try deploy a complete Spring Cloud stack to just serve a simple website, but it will take more time, use more resources, and exposed to more potential vulnerabilities UNNECESSARILY, so noone would recommend that.
When you can address all your pain points regarding dotenv files with some simple bespoke solution of several hundreds lines of code, deploying and adapting to an enormous "config server" mentioned in your post to achieve the same goals is really not something to recommend.
Next time try really read and understand what others have said first.
===
You seem to really have some serious problems with your eyes, or your English comprehension skills. What I said is that achieving the same goals with less code is good, and if by orders of magnitude less amount of code, then that's really really good. More dependencies usually means more code in total to achieve your goals.
And about the lines of code as a useful measurement, yes they are when the differences are ORDERS OF MAGNITUDE kind of huge. A simple "Hello World" program practically has zero bug (of course it has next to nil functionality too), 600k lines of code may not differ from 500k lines of code much in terms of complexity and potential bugginess, but if THE SAME GOALS can be achieved by 600 lines of code instead of 600k lines of code, that's some big difference.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
I don't think we are going to get anywhere, we are clearly at a disconnect and throwing insults isn't going to solve much. Let's just agree to meet in the middle on this.
no insults, just curious, is English your first language? I kinda understand what you are trying to say with "agree to meet in the middle" here, but that sounds really a little odd here, just saying.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Yes english is my first langauge. What i mean by meet in the middle, I'm saying we both respectfully acknowledge the other person side and agree to disagree.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
I'm not sure you read the article completely.
Yea, nothing is full proof; anything can go down, doesn't mean its not a viable option. When config variables are updated, they keep the same entry point ex.
config/DB_PASSWORD/v1. Only the value is changed, this is how an paper trail is kept.When that .env is updated the updated has full access to all secrets, no matter how secure that file is nothing will change that. My point wasn't that the file couldn't be stored properly.
The creaters of dotenv tell you not to commit it in your repo. Look below, tons of comments say the sme thing.
Summary
Please re-read the article, your points are not aligning with what I was saying. Yea its widely adopted, but change takes time.
I have read the article. I am very certain I understand what you propose. It does not work for the environments I work with and I know I am not alone. For the regular self hosted app running on a virtual private server, I would argue you also won't have a need for config servers.
I build industrial applications in demilitarized zones - low trust environments. The customer decides when to go online. We can't expect that an internet connection is there all the time unlike in a cloud application. Not when setting up the software, not when starting the software and also not when updating the software.
This is not a hobby project and it really misses a lot of tooling that yet has to be invented. Because neither docker, k8s or any tooling helps you in continuously rolling out your applications and updates to non-cloud environments. You need to have a very narrow Google-esque vision to assume every app is deployed, managed and run by some cloud.
The problem is a whole lot bigger than ".env files are not secure and don't version". There is a huge gap between the tooling and infrastructure a cloud provides, and the mostly self-baked solutions you have to apply for every tier below that. Docker and docker-compose does work for deploying, but there is an entire slew of tooling that we lack to properly update and version applications that don't run in the cloud.
You mostly have 3 ways of running your apps:
In the Cloud you probably have your complete kubernetes cluster and the entire infrastructure needed to run, monitor, update, version control and deploy your app and its dependencies. There you probably don't have a need for .env files. Even static site cloud hosts like netlify allow you to tune the env from a web ui.
On a virtual private server you have to come up with your own infrastructure. You can't expect everyone to run k8s for a business application. Even then, having too many moving parts can kill your software, as I outlined in my previous post. If I can avoid having a separate runtime dependency, I will avoid it.
All other external systems - A git repository, a CI server, a public key infrastructure, a letsencrypt ssl service, a monitoring service are all optional by design. You can still deploy an app if your CI server gets down. You can still build and package the software locally if your git repo is down. You just don't get monitoring data if sentry is down - the app will continue to run. A certificate will be stored locally and make your app at least secure for ~3 months. But your app won't even start, if your config server is not reachable or has other problems. Even for VPS I would use an
.envfile.On bare metal - hardware demilitarized zones and low trust environments are very valid use cases for IoT or public service applications - Both industrial and homebrewn (e.g. smart home). You can't expect that the customer connects to the internet only to get some env vars when starting, installing or updating their app. And I also wouldn't recommend a nuclear power plant to connect to the internet - no matter how secure your communication is. Even for modern industries, sensor data is sacred and they want to very tightly control when software is allowed to synchronize its data with some cloud application. Your across-the-board suggestions "stop using .env files" stops to work here completely.
For Development For development and for documentation, .env files are still great. Setting environment variables for development on windows is a nightmare. In Linux you can at least do
DB_PORT=3306 DB_HOST=whatever.com npm run start. But it still convoluted for development. Try to convey what environment variables are needed for your app in order to run to your coworkers. An .env file will document and communicate just that - a set of env vars required for your app to run. Configurable in one place.We are very far away from having best practices or tools for running software on non-cloud environments.
Docker and compose make it easier, by having predictable deployments. But everything between is left as an exercise to the developer/devops guy deploying the application.
Before I start to figure out how to get rid of a well working tool like
.env, I'd rather find out how to fill in the gap of all the missing tooling. Nx is a good job in providing better building tools, combining a slew of independent tools to make build less painful. GitLab is collapsing more and more tools into one tool - since we have experienced in the past years that running and combining a separate repository, a separate CI and a separate container registry is painful. I'd bet my money on these guys.Would love to have @jarrodhroberson opinion on this :)
They read it, you're just ignoring anyone who disagrees with your opinion and assuming they're wrong, rather than listening
Hard to believe that when most of my responses are well typed and counter-points, and most of who disagrees are the ones who assume I'm wrong, haven't read it, and don't listen.
Recently, I've decided to leave this article in the past for now. Take care!
I'm pretty sure you are the one who doesn't read counter-points of others, and doesn't listen to those who make them
From what I understand , he's more like talking about a file-based config management solution, with git-based version control, meaning a dedicated private git service to manage the config file versions not exposed to outside access, that is quite different from "commit it in your repo" which means more about committing it in your application code repo.
Also you can easily have a system that automatically merge multiple config files into one .env file, which should not be directly accessible to anyone, so people updating the individual config files won't have access to configs in other files.
Like I said, you can have a file-based solution that achieves more or less the same goals as a database-based solution, which may be easier or harder to implement depending on your specific situation and needs. After all, databases are file-based solutions themselves, they too store data in files (well, some store non-persistent data in memory, but you get the idea :P )
Sounds interesting but still opening one .env exposes all secrets in it. A config server mitigates that risk while giving feature like audit logs and automatic secret rotation.
You also get the benefit of a ui if you care about that.
The point is in such a file-based config management solution no one should be able to directly open the .env file, it should be dynamically generated and managed by the system, more akin to a "flat database file" if you like to think that way. And features like audit logs and automatic secret rotation can be implemented with no more than a couple dozen lines of code, without the need of a config server. Like I said, the main point of your post is actually not about "config servers" (albeit you are advocating their usage), but rather about storing the config data in remote databases vs. local files/environments.
And the existence of a UI can be a pro or con in the case of config administration depending on specific needs. It's also quite trivial to setup a simple database admin UI if you decide to store config data in remote databases anyway.
Honestly at this point you are just implementing a config server yourself. Every feature I mention you are saying just write it. If that's what you want to do by all means. We can agree to meet in the middle at this point.
That means you can just implement a file-based "config server" with .env files, and your "config server" itself would also use .env files for config, and it could have better security, cleaner code, and maybe even easier and faster to implement than trying to deploy and adapt to use one of those enormous "config servers" you mentioned in the post depending on your particular needs.
Which is exactly the point:
1) .env files (or config files in general) based config management solutions are not inherently worse than those based on remote databases. Don't just blindly diss config file based systems in favor of those based on remote databases, they both have their pros and cons, and one may be improved very easily over the other depending on your particular needs.
2) for experienced devops, it's usually quite trivial to implement a bespoke config management system for things like config versioning, sharing and access control, and it could likely be the preferred way over using one of those enormous "config server" with tons of code and myriads of dependencies.
Yea, just like you can implement a no sql database with json files, we have tools built for various use-cases. How do you know config servers are enormous, have you used or checked one out? How is tons of code a useful measurement in this conversation again?
All these features you are saying that are trivial to mention can also grow into these "enormous" config servers you keep mentioning. OOOR you can use an already established and battle-tested implementation to avoid introducing the very bugs you are talking about.
And not to be rude, but how much experience do you have?
I have checked the "config server" you mentioned in the post,, it has hundreds of dependencies and more than 600k lines of code, which is really ENORMOUS considering the fact that only several hundreds of lines of code are needed to realize the features you mentioned most in the post.
log4j was established and battle-tested, struts2 was established and battle-tested, and when there are orders of magnitude of difference in the amount of code involved, then it's a useful measurement. When it comes to managing important sensitive data like passwords in devops, I'd always trust 600 lines of code written by myself with a handful dependencies than 600k lines of code written by other people with 500 dependencies, when they basically serve the same goals for my particular needs.
And nope a simple bespoke config management solution is next to impossible to grow into those enormous config servers, for example if you code a simple server with koa and several self-made middlewares for your particular needs, it will never grow anywhere near the size of Spring or Rails. From what your post suggests, using a "config server" with 600k lines of code and 500 dependencies just to address pain points like version control, config sharing, access control, data encryption and secret rotation kind of stuff, that sounds like you wanting to deploy an entire Spring Cloud infrastructure just to serve a simple website. Or like wanting to use a NoSQL database when a plain JSON file is more than sufficient to store your data.
And like I said, the solutions to those pain points mentioned in your post is really not about config servers vs. dotenv files, but more about centralized remote databases vs. local config files.
I'll just say I have lead teams of devops with 5 to 10 years of experience, using many kinds of configuration management solutions across various projects of various sizes, from simple bespoke solutions based on config files and/or centralized databases, to distributed systems based on things like zookeeper, and tools for k8s, etc. From what I can see, those "config servers" mentioned in your post are simply WAY overkill as replacements for some config files to just address those handful pain points you mentioned in the post.
Again. WHY DO YOU KEEP BRINGING UP LINES OF CODE AS A METRIC OF USEFULNESS??
About half of HashiCorp Vault's code is unit, system, and integration tests.
They thoroughly test the front-end and the back-end. And to take it a step forward they have end-to-end tests and acceptance tests.
Tests written to avoid these "vulnerbilities" that you keep preaching have multiple lines of code create.
Ok then you can write a config server yourself if you are scared of vulernerbilities. While you are at it MySQL has a vulnerbility back in May so you might want to write your own database engine while your at it.
Also, Chrome just recently had a vulnerbility too. Don't forget to build a while web browser as well. Actually, Dev.to has a bug page, yikes you might wanna re-write this website too.
I mentioned in the article that config servers are usually accessed form VPCs so even if one of those "hundreds of dependencies" has a bug, the config server is protected from the internet.
Also I find what your saying kinda funny.
If a project uses tons of dependencies, then the project is bad. Instead, if they write the features by hand which increases the lines of code, that also makes the project bad.
You really need to read what others' saying before replying completely irrelevant things. If I just need to store 1k of data, I'll not use MySQL, I'll just use a JSON file. If I just want to download a file, I'll not use Chrome, I'll just use curl or wget. You must have some serious problems with your eyes IF you can't properly read what others write.
I clearly said those handful of pain points you mentioned in your post does NOT require those enormous "config servers" to address. Those are some simple goals achievable with some very simple config management solutions based on config files, or if you want, with centralized databases, which may take even less time and easier to implement than deploying and adapting to one of those "config servers" mentioned in your post. If you want to call such simple config management solutions "config servers" too, fine. I guess you can call both koa and Spring as "web frameworks", but their differences are huge.
Like I said, using one of those enormous "config servers" to address those pain points mentioned in your post is like deploying an entire Spring Cloud infrastructure to just serve a simple website with features that can be done by using just koa and a handful simple self-made middlewares. Yes you can try deploy a complete Spring Cloud stack to just serve a simple website, but it will take more time, use more resources, and exposed to more potential vulnerabilities UNNECESSARILY, so noone would recommend that.
When you can address all your pain points regarding dotenv files with some simple bespoke solution of several hundreds lines of code, deploying and adapting to an enormous "config server" mentioned in your post to achieve the same goals is really not something to recommend.
Next time try really read and understand what others have said first.
===
You seem to really have some serious problems with your eyes, or your English comprehension skills. What I said is that achieving the same goals with less code is good, and if by orders of magnitude less amount of code, then that's really really good. More dependencies usually means more code in total to achieve your goals.
And about the lines of code as a useful measurement, yes they are when the differences are ORDERS OF MAGNITUDE kind of huge. A simple "Hello World" program practically has zero bug (of course it has next to nil functionality too), 600k lines of code may not differ from 500k lines of code much in terms of complexity and potential bugginess, but if THE SAME GOALS can be achieved by 600 lines of code instead of 600k lines of code, that's some big difference.
I don't think we are going to get anywhere, we are clearly at a disconnect and throwing insults isn't going to solve much. Let's just agree to meet in the middle on this.
no insults, just curious, is English your first language? I kinda understand what you are trying to say with "agree to meet in the middle" here, but that sounds really a little odd here, just saying.
Yes english is my first langauge. What i mean by meet in the middle, I'm saying we both respectfully acknowledge the other person side and agree to disagree.
Yeah I know what it means, just don't see it usually used like this.
I don't want to keep pinging you so I'll make this the last message, but I'm curious, how do you normally see the phrase used?
usually when there's no compromise it's just agree to disagree.