Hacker News Reader

Comment by trio8453 | Hacker News Reader

Rust is quite complicated but people like it a lot. Python too in a way - it's quite large and complicated but it exposes the complexity in a very gradual way and you can ignore so much of the language and still get things done.

I agree with you about simple languages though. I really like Go - the "there should be only one way to do things" from the Zen of Python actually applies to Go in a way that it doesn't apply to Python at all.

View on HN

Languages like Go, is how you end up with what appears simple on the surface, while in reality is full of gotchas and boilerplate for what complex languages support out of the box.

That is how you get double nils, exception handling that pretends not to be one, url based imports that requires source code and rewrites when the host changes, generators by code patterns, generics that miss some language constructs,....

Written a few hundred kloc of go and I'd never heard of double nil. Turns out it's nasty.

    var i interface{} // (Type: nil, Value: nil) -> i == nil is TRUE
    var p *int = nil  // p is nil
    i = p             // (Type: *int, Value: nil) -> i == nil is FALSE!

While this behavior can be counterintuitive, it's easy to understand once you have the right mental model of interface values. A nil interface is an empty interface. Once p is assigned to i, then i is no longer empty: it holds a nil pointer to an int. Whether the interface is empty or not is one question, answered by comparing it against nil. Whether the value the interface holds is a nil value is another question, answered by downcasting and then checking the resulting value.

I don't blame people for being confused by this the first time they encounter it. However, anyone who finds it persistently challenging to understand is not going to have much luck with the subtler language features of C++, Rust, Typescript, etc.

Just because you can easily understand something doesn't mean it isn't a footgun.

That seems like the reasoning that given the amount of UNIX and C code in the industry, memory corruption bugs only happen to those that don't understand their job.

Never used go, but I assume interface is some kind of indirection? If so, this doesn't seem anymore confusing than:

    void *p=0;
    void **pp=0;
    assert(pp == 0);
    pp=&p;
    assert(pp != 0);
    assert(*pp == 0);

None of those are real problems in reality, I don't think Go has more gotchas than other languages.

Having gotchas is natural in language design, often times they only surface after field experience.

The problem with many Go's gotchas is the initial refusal to learn how other languages approached the same problems, the gotchas they got in the process, only to come up with some patch work afterwards, e.g. pseudo-exceptions with panic/defer/recover, rewriting import urls in go.mod,...

> url based imports that requires source code and rewrites when the host changes

This is not the case. It can be avoided quite easily with 'replace' directives and/or GOPROXY.

Yes, I meant that with my mention of rewrites, and it is design wart that such workarounds are required in first place.

This is just how I've felt writing both Rust and C++. Rust's language complexity often feels like it's there so that I don't have to think about so much complexity when interfacing with the code, whereas C++'s language complexity introduces footgun after footgun and I have to think very carefully about what everything could possibly do (e.g. if destructors even get run in certain instances when I'd expect them to).

Reply on news.ycombinator.com