3 ms·

Why do you need to know what/what not is a delayed operation? Seem like the worse languages are ones you have to do that, instead of just caring about the compu

by nsonha 3y ago

Why do you need to know what/what not is a delayed operation? Seem like the worse languages are ones you have to do that, instead of just caring about the computation. Polluting your function signatures with some abstraction that has nothing to do with the domain is pretty lame too.

neonsunset 3y ago
"The group I belong to is obviously right and the other group is obviously wrong" Forcibly hiding away the nature of the call shifts the priorities from easy concurrency especially when there are multiple calls in-flight to only logically sequential code being convenient to write with all other options requiring significantly more boilerplate (which is the case for both Go and Java). It is a tradeoff, and I think it is a bad one for the domain that both Java and Go are usually applied to. Java had to retrofit a GT approach because async/await would be unfeasible at this point. It was a good choice in the context, but maybe not so if one were to reinvent it from the ground up. On the other hand, Go took a similar route but for completely different reasons - it was specifically tailor made to first and foremost solve Google issues with internal dev culture and scaling of the organization (e.g. syntax styling being the function visibility modifier) and strictly prioritized being as quick to on-board as possible. It resulted in Go being a language that is, as someone neatly put it here on HN, "Newbie friendly but professional unfriendly". This is further evidenced by the amount of surrounding code generation tooling and code written in DSL required to maintain an average complex project written in Golang (remember the HN post on a multi-million dollar project in dev hours to just work around Go's issues with nils?), something that is often a sign of inherent language limitations or its overall inadequacy (e.g. the criticism regarding C#'s source generators/interceptors or Java Lombok is valid because they exist for the same reason).

by nsonha 3y ago

neonsunset 3y ago

"The group I belong to is obviously right and the other group is obviously wrong" Forcibly hiding away the nature of the call shifts the priorities from easy concurrency especially when there are multiple calls in-flight to only logically sequential code being convenient to write with all other options requiring significantly more boilerplate (which is the case for both Go and Java). It is a tradeoff, and I think it is a bad one for the domain that both Java and Go are usually applied to. Java had to retrofit a GT approach because async/await would be unfeasible at this point. It was a good choice in the context, but maybe not so if one were to reinvent it from the ground up. On the other hand, Go took a similar route but for completely different reasons - it was specifically tailor made to first and foremost solve Google issues with internal dev culture and scaling of the organization (e.g. syntax styling being the function visibility modifier) and strictly prioritized being as quick to on-board as possible. It resulted in Go being a language that is, as someone neatly put it here on HN, "Newbie friendly but professional unfriendly". This is further evidenced by the amount of surrounding code generation tooling and code written in DSL required to maintain an average complex project written in Golang (remember the HN post on a multi-million dollar project in dev hours to just work around Go's issues with nils?), something that is often a sign of inherent language limitations or its overall inadequacy (e.g. the criticism regarding C#'s source generators/interceptors or Java Lombok is valid because they exist for the same reason).