"Regarding the full safety “hinderance”,
part 2- one thing i’m repeatedly trying to explain: there are conversely times (and areas of a program) where flawed behaviour is better than no behaviour (because you’re trying to learn something else).
the most direct example is debug code; I don’t get why this isn’t clearer. Unless your brain has an embedded digital computer , you’re eventually going to write some sort of tests alongside your regular program - as such having a “productive” language embedded right in the same source files as your 'performant/‘safe’ language is useful
the missed opportunity here is the whole program inference - if you’re writing a test for a function next to it, one or the other is going to give the information needed
If you want syntactic sugar for defining maps it’s not overly difficult to implement yourself with a macro.
I know you can do that for declaring maps
I mean for maps in the function signatures; apple do this [K:V] .
function signatures are important because thats what you search
(repeating myself) the original rust with the ~T ~[T] etc showed unique blend between readability and performance… it was just right. You still have a concrete symbol telling you the important information (‘this is a pointer to an allocation…’) but it’s light enough to melt away and let your mind focus on what you’re actually doing. I’m amazed that people complained about it (‘too many pointer types’…) … they were very logical (‘owned allocated version of…’)
Box<T> is more like 2 extra mental steps because it’s a word and a nesting level (and yes I hate writing
unique_ptr<T> in C++… there’s always a serious temptation to revert to raw pointers. if the thing you’re supposed to use is syntactically light… thats very helpful)
there are little tweaks that could recover this. if we had the option for more inference, the signatures that you do write wouldn’t matter so much;
one idea that would turn the traits from a hinderance to a virtue (in my mind) is: if when impl-ing, you could elide the types … just copy them from the trait. Then I wouldn’t mind them. (I might write an RFC for this). Haskell of course lets you work like this - thats why I didn’t find the ‘typeclasses’ as oppressive over there
The frustrating thing is seeing this amazing underlying language engine (coming from C++ I do find the level of inference very impressive … and I do start to miss it back there ) … but then some of these decisions taken toward verbosity