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.
replyI 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.
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.
replyThat 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,....
None of those are real problems in reality, I don't think Go has more gotchas than other languages.
replyWritten a few hundred kloc of go and I'd never heard of double nil. Turns out it's nasty.
reply 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.
replyI 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.
> url based imports that requires source code and rewrites when the host changes
replyThis 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.
replyThis 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).
replyOn the one hand, almost everyone (including C++ fans) agrees that the language is too big. On the other hand, comtracts just formalize an existing and useful concept.
replyProfiles should (hopefully) rein this in by getting people to start subsetting language features in their codebases
replyLet's see, they are still a bit of a dream regarding what they wish for, and what current static analysers can achieve, especially the lifetime one.
replyI was thinking for implementing borrow-checker like rules for C but after I have seen what SMT solver can do I think it is not necessary to constrain the language in this way.
replyIIRC Rust's borrow checker analysis is more or less a subset of what SMT solving is capable of. It's "just" a question of tradeoffs made with respect to performance, complexity, precision, etc.
replyExactly. Many years ago people used to use C `struct` for objects but then that was formalized as `class`.
replyC++ "class" is the exact same user-defined type as C++ "struct" but with different defaults for privacy.
replyBut C++ "struct" has many more features than C "struct". Virtual functions aka compiler-generated invisible vtables, constructors (initialization functions) and destructors (automagically called deinitialization functions), the whole templates complex of features...
replyLots of programmers match the right language to the right job, I think the zen of C++ is embracing the ugly as a feature; there are so many subsets of that language you never have to leave it.
replyExactly, you can code like C devs (Petzold used the C subset in his famous Win32 book), go to the extreme of GUI, ORMs, Web frameworks in 1990's, inspired from Smalltalk before Java and .NET took over that role, go crazy with Haskell style programming, or chose somewhere in between.
replyI view C++ (and increasingly C# and Java) as a test bed for language features. You throw every possible feature into it and people can then see what makes sense and what doesn't. That allows others to pick features and use them for more opinionated and simpler languages.
replyThis is a cool way to think about it!
replyC++ as a reference language. That’s actually a great concept.
replyDoesn’t hurt that it has fantastic, minimal, navigable documentation.
You can see the entirety of the language on a single page: https://cppreference.com/