Earlier quoted context omitted.
> Because of the implicit thing! Known as structural typing and available in most modern languages.
available in most modern languages Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?
Half a decade with Go
191–200 of 257 posts
Re: Half a decade with Go
#192Earlier quoted context omitted.
D and C++ templates for example. F# also supports it, given its ML linage. C# tricks with dynamic, although in this case it is dynamic typing, so not really the same thing.
The disadvantage of C++ templates is the structural type is implicit - you only know if the input object satisfies the type if you read the documentation, code, or can decipher the error message that occurs if it didn't. Concepts would have fixed this, but we don't have concepts and maybe never will!
enable_if and type traits are a workaround for the time being.
Concepts lite will definitely be in the next revision.
Re: Half a decade with Go
#193Earlier quoted context omitted.
> In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.
Anyway Go has its use cases, and it is already an improvement if less C code gets written.
Re: Half a decade with Go
#194Earlier quoted context omitted.
Go has nothing unique (and maybe that makes it special). I mean that sincerely, everything it has, has been done dozens of times. Interfaces in Go are implicit (which is important, IMHO) and really, tremendously simple. These two features make them exceptional easy to use, and ACTUALLY used. I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitl…
replace Go with Python in the text, and you won't see a difference: there are iterable, keyable, file-like interfaces, etc. And creating your own is trivial.
Re: Half a decade with Go
#195Earlier quoted context omitted.
If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't? Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?
> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't? Like these? https://www.haskell.org/haskellwiki/Haskell_in_industry https://www.erlang-solutions.com/industries https://ocaml.org/learn/companies.html http://fsharp.org/testimonials/
Re: Half a decade with Go
#196Earlier quoted context omitted.
> Because of the implicit thing! Known as structural typing and available in most modern languages.
available in most modern languages Well, "modern" is an ill-defined concept. As far as I'm aware, structural typing is not really that common, is it? Besides OCaml and Scala, is there any relevant (used outside of academia) language that supports it?
Re: Half a decade with Go
#197Re: Half a decade with Go
#198Re: Half a decade with Go
#199Earlier quoted context omitted.
The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.
> In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
Re: Half a decade with Go
#200Earlier quoted context omitted.
replace Go with Python in the text, and you won't see a difference: there are iterable, keyable, file-like interfaces, etc. And creating your own is trivial.
Python doesn't verify the interface is met until run time.
If it had Generics that would be another thing.