6 ms·

> On the other hand, would you choose to build a long-term business on top of Go a) Absolutely and b) already done. Go is stable. The language is battle teste

> On the other hand, would you choose to build a long-term business on top of Go a) Absolutely and b) already done. Go is stable. The language is battle tested. It works as advertised. It is open source. Even if google pulled all funding (unlikely, since alot of their architecture seems to use it), the language is maintainable. And btw. Languages don't have to continuously evolve to remain viable. Modern languages seem to indicate otherwise, but that behavior is what Go actively avoids; adding everything and the kitchen sink into the language as soon as some other language has it. If Go showed one thing, it is that PLs don't need to add as many features as possible. And just to prove that point: C is still a top rated language in terms of usage. When was it last updated? C17 came out in 2017, and did not add new features. It superseded C11, which came out 6 years before that, also mainly standardising things that were already de-factos in most compilers. Before that was C99 in 1999, and before that is only ANSI-C and K&R.

crabbone 3y ago
There's a lot of misinformation, bad arguments and bad conclusions in this post. Let's pick it apart. > Go is stable. But, past isn't a guarantee of the future. It was stable before, but who's to say it will be in the future? The fact that it's "owned" by a single entity should make you scared that it wont, because the whim of that entity is what can change any property of the language. Additionally, Go has no standard, no alternative implementations to speak of. All of this should have you concerned for the future (but you seem to ignore the obvious dangers). > It works as advertised. It's the opposite. Languages with single (or one primary) implementation advertise how they work. Go is implement first document later language. The public discussion is for show because public doesn't control how things are being implemented. The Go dev. team may listen to everyone's opinion, nod in agreement, and do something else entirely, and nobody will hold them responsible for the discrepancy. > the language is maintainable. By who? How did you come to this conclusion? There's only evidence to the contrary of your argument. There isn't any other organization that's interested in maintaining Go if Google were to go away. At least nobody expressed such an intention publicly. > Languages don't have to continuously evolve to remain viable. This is demonstrably false. Hardware changes, operating system interfaces change. If you don't keep up with these changes, eventually your language becomes irrelevant. To further illustrate this point: today, versions of Python 3.7 and older cannot be built from source on modern Linux with current GCC. Python's dependencies on libffi and libssl are incompatible with their current interfaces, and so the language can only be built with older libraries (but then the operating system needs to use the older ones too) or statically linked with those libraries, but in case of libffi that doesn't help because it will not work for its intended goal. And the further back you go, the less likely it is that you will be able to build and use any version of Python. Bet, the same is true for Go. > When was it last updated? C17 came out in 2017 C standards don't get implemented on the year they are released. Bet you Microsoft probably doesn't fully implement this standard. (I don't know, it's a guess based on past experience using their tools). In more broader terms, I have no idea why did you bring C into this argument. C is an entirely different language in terms of governance, support, standardization... It's basically all things that Go isn't. Standards and multiple interested vendors ensure the survival of the language. The whole argument against using Go for long-term projects is that it's not like C. You trying to point out that C is used successfully for long-term projects doesn't help to show that Go would too. If anything, you should suspect that it won't, because Go is the opposite of C.
- Wowfunhappy 3y ago
  > This is demonstrably false. Hardware changes, operating system interfaces change. If you don't keep up with these changes, eventually your language becomes irrelevant. To further illustrate this point: today, versions of Python 3.7 and older cannot be built from source on modern Linux with current GCC. Python's dependencies on libffi and libssl are incompatible with their current interfaces, and so the language can only be built with older libraries (but then the operating system needs to use the older ones too) or statically linked with those libraries, but in case of libffi that doesn't help because it will not work for its intended goal. And the further back you go, the less likely it is that you will be able to build and use any version of Python. Bet, the same is true for Go. If Python 3.8+ didn't exist, how difficult would it be to update cypthon to target newer GCC? Correct me if I'm wrong, but my sense is this would be a relatively minor maintenance task. I suspect no one has updated Python 3.7 because there is no need (and because the Python foundation would prefer to nudge everyone to update anyway).
- usrbinbash 3y ago
  >There's a lot of misinformation, bad arguments and bad conclusions in this post. Let's pick it apart. No, there really isn't, but I had fun answering :-) > But, past isn't a guarantee of the future. It was stable before, but who's to say it will be in the future? Whos to say C will be stable tomorrow? Well, the fact that things like GCC are standards unto themself, even without any official governance (Which C has in addition). Its the same for Go. If anyone was to change that, all I have to do is check out an earlier version of this open source language, and use that. And since tons of code rely on this, that is what would happen. Languages don't become unstable because they suddenly change trajectory. This rarely ever happens. Language instability requiring constant evolvement and developer effort (both from the languages devs, as well as the languages users) is the result of feature upon feature getting heaved upon a language, along with codebases relying on these features, necessitating constant maintenance effort to keep up to date. Go, explicitly, has a completely different design trajectory. And as a result, Go code that was written in Go 1.8 will still compile today. > Go has no standard Here is the official spec of the language: https://go.dev/ref/spec https://go.dev/ref/spec Which is a de-facto standard, even according to this listing: https://en.wikipedia.org/wiki/Comparison_of_programming_languages https://en.wikipedia.org/wiki/Comparison_of_programming_lang... Btw. if you look at the listing, MOST languages, including commonly used ones, don't have an international or national standard. Many don't even have a de-facto standard. Among them are many tried and battle tested languages. > and nobody will hold them responsible for the discrepancy. Anyone unhappy with the implementation is free to fork the project and take it in a different direction. He who writes the code makes the rules. If people are unhappy with that, they can fork, or use another language. And people seem to be very happy with the language: https://madnight.github.io/githut/#/pull_requests/2023/3 https://madnight.github.io/githut/#/pull_requests/2023/3 > By who? How did you come to this conclusion? There's only evidence to the contrary of your argument. What evidence is there for the assumption that Go would vanish if Google lost interest? > This is demonstrably false. No, it is not, as demonstrated by the example I gave regarding C. The language didn't change much from C99, which itself wasn't that big a step away from ANSI-C. C99 was a quarter century ago, and C remains one of the most used languages in existence. > To further illustrate this point: today, versions of Python I am pretty sure I never used Python as an example for this. If you disagree, quote where I did. > In more broader terms, I have no idea why did you bring C into this argument. For a very simple reason: To show that a language that is mostly feature-freezed, and so stable that I can run a modern compiler on decades-old unchanged code, and still get a runnable executable, can be, and are, incredibly successful. Go has been called "C for the 21st century", and for everything other than System-Programming, that statement holds true.
pjmlp 3y ago
This year, C23 will be ratified in January 2024, and there are enough features on the pipeline for C to be "C++ without classes".
SubjectToChange 3y ago
It is open source. Even if google pulled all funding … the language is maintainable. First of all it’s not just an issue of maintaining the language itself, but all of the associated tooling as well. Second of all, it’s not just that Google could pull support, but that Google could choose to prioritize their own needs over the rest of the community. And btw. Languages don't have to continuously evolve to remain viable. … If Go showed one thing, it is that PLs don't need to add as many features as possible. Go advocates say this often enough that it’s honestly beginning to come off as an insecurity. And I would be concerned about cultivating a community around “less is more, Go should only evolve as a last resort”. Moreover, keep in mind that the primary selling point of Go were goroutines. At the time Go was particularly well suited to exploit a gap left by other languages. Fast forward to today and Go has become a significantly less compelling option. And just to prove that point: C is still a top rated language in terms of usage. When was it last updated? Projects written in pure ISO C are relatively few and far between. In fact many high profile C projects are exclusively tied to one or two compilers. Furthermore, ISO C has delegated a lot of functionality to external standards like POSIX instead of giving them first class support, not to mention the plethora of nonstandard language extensions found in many compilers[0]. In other words, ISO C has stagnated, albeit C23 is a big update, while the C language has evolved. Anyway, as I see it, golang is basically a dead end as a PL. It doesn’t interface well with other languages, it doesn’t substantially differentiate itself as a PL, any nuance you encounter with the language is likely to never be fixed, it’s a poor language for writing great libraries and/or abstractions, etc. That said, plenty of great businesses have been built on top of languages like PHP, so it can definitely work. Personally I don’t expect anything like another kubernetes coming out of the language again. [0]https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
- usrbinbash 3y ago
  > First of all it’s not just an issue of maintaining the language itself, but all of the associated tooling as well. Which is part of the language core, and distributed alongside it. > Google could choose to prioritize their own needs over the rest of the community. Which they would do why, and how specifically? This isn't a server or a database, it's a PL. What specific scenario do you see for such a change? And even in that unlikely scenario, the language is open source, and the community can fork it. > Go advocates say this often enough that it’s honestly beginning to come off as an insecurity. How anyone choses to interpret this message, is their business. We say it because it's true. > And I would be concerned about cultivating a community around “less is more Why? It seems to work exceedingly well. And there are more than enough languages following the "everything-and-the-kitchen-sink" approach already. What benefit would there be in trying to secure a tiny portion of a niche that is already overfilled? > that the primary selling point of Go were goroutines They were one of the selling points. What anyone sees as "the primary" point is a matter of opinion. For many people, the primary selling point of Go is the simplicity of the language. > Fast forward to today and Go has become a significantly less compelling option. Really? What other mainstream language uses CSPs with the same syntactic ease and core-language support? > Anyway, as I see it, golang is basically a dead end as a PL. What data specifically supports that point of view? Because, going by usage metrics, like code contributed, Go is easily among the most used languages, and still growing. If you have different metrics, please, do share them here.

crabbone 3y ago

There's a lot of misinformation, bad arguments and bad conclusions in this post. Let's pick it apart. > Go is stable. But, past isn't a guarantee of the future. It was stable before, but who's to say it will be in the future? The fact that it's "owned" by a single entity should make you scared that it wont, because the whim of that entity is what can change any property of the language. Additionally, Go has no standard, no alternative implementations to speak of. All of this should have you concerned for the future (but you seem to ignore the obvious dangers). > It works as advertised. It's the opposite. Languages with single (or one primary) implementation advertise how they work. Go is implement first document later language. The public discussion is for show because public doesn't control how things are being implemented. The Go dev. team may listen to everyone's opinion, nod in agreement, and do something else entirely, and nobody will hold them responsible for the discrepancy. > the language is maintainable. By who? How did you come to this conclusion? There's only evidence to the contrary of your argument. There isn't any other organization that's interested in maintaining Go if Google were to go away. At least nobody expressed such an intention publicly. > Languages don't have to continuously evolve to remain viable. This is demonstrably false. Hardware changes, operating system interfaces change. If you don't keep up with these changes, eventually your language becomes irrelevant. To further illustrate this point: today, versions of Python 3.7 and older cannot be built from source on modern Linux with current GCC. Python's dependencies on libffi and libssl are incompatible with their current interfaces, and so the language can only be built with older libraries (but then the operating system needs to use the older ones too) or statically linked with those libraries, but in case of libffi that doesn't help because it will not work for its intended goal. And the further back you go, the less likely it is that you will be able to build and use any version of Python. Bet, the same is true for Go. > When was it last updated? C17 came out in 2017 C standards don't get implemented on the year they are released. Bet you Microsoft probably doesn't fully implement this standard. (I don't know, it's a guess based on past experience using their tools). In more broader terms, I have no idea why did you bring C into this argument. C is an entirely different language in terms of governance, support, standardization... It's basically all things that Go isn't. Standards and multiple interested vendors ensure the survival of the language. The whole argument against using Go for long-term projects is that it's not like C. You trying to point out that C is used successfully for long-term projects doesn't help to show that Go would too. If anything, you should suspect that it won't, because Go is the opposite of C.

Wowfunhappy 3y ago
> This is demonstrably false. Hardware changes, operating system interfaces change. If you don't keep up with these changes, eventually your language becomes irrelevant. To further illustrate this point: today, versions of Python 3.7 and older cannot be built from source on modern Linux with current GCC. Python's dependencies on libffi and libssl are incompatible with their current interfaces, and so the language can only be built with older libraries (but then the operating system needs to use the older ones too) or statically linked with those libraries, but in case of libffi that doesn't help because it will not work for its intended goal. And the further back you go, the less likely it is that you will be able to build and use any version of Python. Bet, the same is true for Go. If Python 3.8+ didn't exist, how difficult would it be to update cypthon to target newer GCC? Correct me if I'm wrong, but my sense is this would be a relatively minor maintenance task. I suspect no one has updated Python 3.7 because there is no need (and because the Python foundation would prefer to nudge everyone to update anyway).
usrbinbash 3y ago
>There's a lot of misinformation, bad arguments and bad conclusions in this post. Let's pick it apart. No, there really isn't, but I had fun answering :-) > But, past isn't a guarantee of the future. It was stable before, but who's to say it will be in the future? Whos to say C will be stable tomorrow? Well, the fact that things like GCC are standards unto themself, even without any official governance (Which C has in addition). Its the same for Go. If anyone was to change that, all I have to do is check out an earlier version of this open source language, and use that. And since tons of code rely on this, that is what would happen. Languages don't become unstable because they suddenly change trajectory. This rarely ever happens. Language instability requiring constant evolvement and developer effort (both from the languages devs, as well as the languages users) is the result of feature upon feature getting heaved upon a language, along with codebases relying on these features, necessitating constant maintenance effort to keep up to date. Go, explicitly, has a completely different design trajectory. And as a result, Go code that was written in Go 1.8 will still compile today. > Go has no standard Here is the official spec of the language: https://go.dev/ref/spec https://go.dev/ref/spec Which is a de-facto standard, even according to this listing: https://en.wikipedia.org/wiki/Comparison_of_programming_languages https://en.wikipedia.org/wiki/Comparison_of_programming_lang... Btw. if you look at the listing, MOST languages, including commonly used ones, don't have an international or national standard. Many don't even have a de-facto standard. Among them are many tried and battle tested languages. > and nobody will hold them responsible for the discrepancy. Anyone unhappy with the implementation is free to fork the project and take it in a different direction. He who writes the code makes the rules. If people are unhappy with that, they can fork, or use another language. And people seem to be very happy with the language: https://madnight.github.io/githut/#/pull_requests/2023/3 https://madnight.github.io/githut/#/pull_requests/2023/3 > By who? How did you come to this conclusion? There's only evidence to the contrary of your argument. What evidence is there for the assumption that Go would vanish if Google lost interest? > This is demonstrably false. No, it is not, as demonstrated by the example I gave regarding C. The language didn't change much from C99, which itself wasn't that big a step away from ANSI-C. C99 was a quarter century ago, and C remains one of the most used languages in existence. > To further illustrate this point: today, versions of Python I am pretty sure I never used Python as an example for this. If you disagree, quote where I did. > In more broader terms, I have no idea why did you bring C into this argument. For a very simple reason: To show that a language that is mostly feature-freezed, and so stable that I can run a modern compiler on decades-old unchanged code, and still get a runnable executable, can be, and are, incredibly successful. Go has been called "C for the 21st century", and for everything other than System-Programming, that statement holds true.

pjmlp 3y ago

This year, C23 will be ratified in January 2024, and there are enough features on the pipeline for C to be "C++ without classes".

SubjectToChange 3y ago

It is open source. Even if google pulled all funding … the language is maintainable. First of all it’s not just an issue of maintaining the language itself, but all of the associated tooling as well. Second of all, it’s not just that Google could pull support, but that Google could choose to prioritize their own needs over the rest of the community. And btw. Languages don't have to continuously evolve to remain viable. … If Go showed one thing, it is that PLs don't need to add as many features as possible. Go advocates say this often enough that it’s honestly beginning to come off as an insecurity. And I would be concerned about cultivating a community around “less is more, Go should only evolve as a last resort”. Moreover, keep in mind that the primary selling point of Go were goroutines. At the time Go was particularly well suited to exploit a gap left by other languages. Fast forward to today and Go has become a significantly less compelling option. And just to prove that point: C is still a top rated language in terms of usage. When was it last updated? Projects written in pure ISO C are relatively few and far between. In fact many high profile C projects are exclusively tied to one or two compilers. Furthermore, ISO C has delegated a lot of functionality to external standards like POSIX instead of giving them first class support, not to mention the plethora of nonstandard language extensions found in many compilers[0]. In other words, ISO C has stagnated, albeit C23 is a big update, while the C language has evolved. Anyway, as I see it, golang is basically a dead end as a PL. It doesn’t interface well with other languages, it doesn’t substantially differentiate itself as a PL, any nuance you encounter with the language is likely to never be fixed, it’s a poor language for writing great libraries and/or abstractions, etc. That said, plenty of great businesses have been built on top of languages like PHP, so it can definitely work. Personally I don’t expect anything like another kubernetes coming out of the language again. [0]https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

usrbinbash 3y ago
> First of all it’s not just an issue of maintaining the language itself, but all of the associated tooling as well. Which is part of the language core, and distributed alongside it. > Google could choose to prioritize their own needs over the rest of the community. Which they would do why, and how specifically? This isn't a server or a database, it's a PL. What specific scenario do you see for such a change? And even in that unlikely scenario, the language is open source, and the community can fork it. > Go advocates say this often enough that it’s honestly beginning to come off as an insecurity. How anyone choses to interpret this message, is their business. We say it because it's true. > And I would be concerned about cultivating a community around “less is more Why? It seems to work exceedingly well. And there are more than enough languages following the "everything-and-the-kitchen-sink" approach already. What benefit would there be in trying to secure a tiny portion of a niche that is already overfilled? > that the primary selling point of Go were goroutines They were one of the selling points. What anyone sees as "the primary" point is a matter of opinion. For many people, the primary selling point of Go is the simplicity of the language. > Fast forward to today and Go has become a significantly less compelling option. Really? What other mainstream language uses CSPs with the same syntactic ease and core-language support? > Anyway, as I see it, golang is basically a dead end as a PL. What data specifically supports that point of view? Because, going by usage metrics, like code contributed, Go is easily among the most used languages, and still growing. If you have different metrics, please, do share them here.