Live data from Hacker News

Half a decade with Go

blog.golang.org

191–200 of 257 posts

Re: Half a decade with Go

#191
post #164

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?

Would rust's "traits" count as structural typing? (I know Rust may not count as "relevant (used outside of academia)" yet, but maybe in the future.)

Re: Half a decade with Go

#192
post #184
post #177

Earlier 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!

> 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

#193
post #185
post #141

Earlier 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.

Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers.

Anyway Go has its use cases, and it is already an improvement if less C code gets written.

Re: Half a decade with Go

#194

Earlier 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.

Python doesn't verify the interface is met until run time.

Re: Half a decade with Go

#195
post #182
post #126

Earlier 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/

The stock price of Standard Chartered is 939 GBX currently.

Re: Half a decade with Go

#196
post #164

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?

Haskell's typeclass provide it.

Re: Half a decade with Go

#199
post #141
post #88

Earlier 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.

I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.

Re: Half a decade with Go

#200
post #194

Earlier 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.

With all the cases were Go pushes you to use interface{} that's the case in Go a lot of the time too.

If it had Generics that would be another thing.

Post reply on HN