Haskell has such situations as well, but usually far less verbose. Getting something to typecheck because you wrote down something incompatible uninferable still sucks. But far less than C++.

If the Rust compiler can figure out what the type should be, why doesn't it just do the cross-function inference, and leave the complicated nested implications which only obscure the intent and effect out of it?

If having the programmer specify types is an important check on the correctness of the code that is written, how is blindly copying, without understanding some 60+ character type specification string from an error message going to help demonstrate correctness? All it does is make two sections "consistent". It isn't something the programmer understands or specifies as a type check.

It could! This is an explicit design choice. There are a few different reasons. They're all sort of connected...

In general, Rust takes the position that the type signature is the contract. If you inferred the types on function signatures, changing the body of your function could change the signature, which means that breaking changes are harder to detect. It also leads to "spooky action at a distance" errors; I could change a line of code in function A, but then the compiler complains about the body of some unrelated code in a totally different part of the codebase, because that changed the signature of function A, which changed the signature of function B, which is called in function C. My error shows C is wrong, but I made a mistake in the body of A. That's confusing. Much nicer to say "Hey you said the signature of A is X but the body is Y, something is wrong here."

I am gonna handwave this one slightly because I don't fully remember all of the details, but full program inference and subtyping is undecidable. Rust doesn't have subtyping in general for this and other reasons, but lifetimes do have subtyping. I am sure this would get ugly.

Speaking of getting ugly, Rust is already criticized often for compile times. Full program inference would make this much, much worse. Again with that changing signatures issue, cascading signature change would cause even more of your program to need to be recompiled, which means that bad error message is gonna take even longer to appear in the first place.

I think there might be more but those are the biggest ones off the top of my head.

Correct. Haskell is the only language I know of with globally decidable type inference, and uses the similar hindley-milner method as Rust... but no doubt some of Rust's language features can break global inference. In Haskell, many common language extensions can also break global inference.

I think if Haskell was written today they probably wouldn't pick global inference as a goal, Haskell "best practice" types the function boundaries in the same way that Rust enforces.

A lot of the "weirder" parts of Haskell are there because early on Haskell was pretty much "LazyML" and then it started growing into something different.

Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespaces shouldn't be a big obstacle to understanding either.

It was also crystal clear that, like C++, Rust puts many barriers to true abstraction. You have to know many, many details of how a specific type is implemented, sometimes several levels deep, to correctly use it at a high level. The cognitive overhead is enormous.

Hiding them basically amounts to targeting a different domain. This is very different from being irrelevant and noisy.

For sure though, not every error has a great message and some can be cryptic. But those cases are relatively rare these days IMO

For what it's worth, I believe modern C++ compilers give much better error messages than older ones.

We're used to avoiding complexity when it comes to logic, but maybe there's less awareness when it comes to types. Maybe what we need is to have a bigger conversation around that so people realize it's something that needs to be on their radar.

The only immediate solution I can see is to keep types simple enough that the user can fit the entire relevant type-space in their head (and in the IDE dialog!), so that they themselves can determine which part is actually "wrong" (as opposed to just contradictory).

The talks were by Jason Turner, who has an ARM emulator implemented entirely as constexprs and a test suite that runs at compile time (so if it compiled, the tests passed). Obviously for actually interacting with it, its not running at compile time, but the logic has the ability to run at compile time, which is pretty cool.

"Old school" is asically the programming languages that originated in the 70s-80-90s. An incorrect but an illustrative way to describe error messages for them is "The programmer needs to suffer". They are any combination of cryptic, terse, complex, exposing internal machinery of the compilers and linkers etc. There are many reasons for this: computers were not powerful enough to afford better code analysis, parsing, backtracking etc; the users of the tools also knew the tools and could tinker with them etc.

"New school" is from late 2000s on. I usually say it started with Elm. Clear messages pinpointing the exact problem, solutions to problems inside error messages, error clarity as one of the priorities in language/compiler/tool design.

Category grammars were much better but more resource demanding, just like proper ASTs instead compiling as one goes.

Ironically there were already some attempts to Smalltalk like tooling for C++ back then, but again as you mention too much resource constraints.

In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher.

But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)

Yup, this is probably my main issue with Python. I love writing it when I'm working on personal projects, having to read massive Python code bases at work feels unnecessarily tedious due to how much work you have to do sometimes just to find out the type of something.

I would still recommend against using Python on a big project. Funny thing, I remember talking to my boss (a mainframe programmer) in 2010, when I solved something with a script in Python, that I wouldn't use it in production, but it's great for small things. Forward to 2020, plenty people use it in products. Maybe the Haskell will be the same, you also have many people today saying "well this is good for experiments but I wouldn't write a product in it".

I've recently been back to Clojure, and it's the same old aggravation again. It seems that, oftentimes, the only way to know what arguments a function is prepared to accept is to already know what arguments a function is prepared to accept.

I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. What I really want to challenge is the idea, popular in many dynamic typing circles, that static types just get in the way. They can also serve to communicate essential information. If you aren't communicating that information through type annotations, then it's absolutely essential that you do it by some other means.

Curious, from what and why? ML?

The lack of .h files alone is a huge grievance for me - I had to scroll past definitions even to know names and arities of class methods, read constructors to know what's in class members.

SciPy was nice enough for turning data into a picture, though.

That's an interesting point... Besides C and its derivatives, and OCaml, do other languages have separate definition files? It seems like newer languages, even statically typed, normally don't.

I suspect the reason is that you have to duplicate all definitions, which seems like rote work. It also feels less necessary with IDE tooling: IDEs I know have a view for all definitions in a file.

One place I worked used to be a Python shop, but had migrated most of its services to Java. Chatting with one of the engineering leads for a large Python system that had a lot of business logic, he said where Python actually fails to scale is lines of code and developers because lack of types makes it harder to reason about and harder to make changes safely. This obviously changed now that type annotations are a thing.

At what point do you feel like this line is crossed? "In the large" can mean different things to different people.

how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009

This means that you cannot say something like this:

  auto sepulka;
  auto bubuka = zagizuka(sepulka);

[1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%...

[2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Mar...

[1] shows how hard it is to make right type system with inheritance. I believe these slides mention 25 years of collaborative effort. Compare that to [2] where it took 8 years to design intuitionistic type theory (1971-1979) by mostly single person.

It has a much simpler type deduction system where the type of an object is deduced from its initializing expression, i.e. deduction always flows in one direction.

It is nowhere as powerful, but it does cover a lot of use cases.

One advantage (in addition to the ease of implementation) is that, except for circular definitions, there are no undecidable cases and it is not necessary to restrict the type system to prevent them.

for example

  def sepulka(zagizuga)
    zagizuga.doSomething()
    zagizuga.doSomethingElse()

maybe i missed something...

E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.

for example, in swift you cant even inherit from two protocols that have default implementations... and i think in c++ you also cant call the method without specifying namespace...

so, i suppose, if you wanted to go all the way, you could even do namespace inference

  def sepulka(zagizuga)
    zagizuga::Something.doSomething()
    zagisuga.doSomethingElse()

though that seems getting a bit fragile irl maybe...

A culture of writing code assuming inference and structural typing is quite different than it merely being available.

Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on.

The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that direction.

Or has Haskell added structural typing?

Only that the types can be analysed structurally (ie., pattern matched).

In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.

Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.

String foo = "bar"; String baz = foo;

The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

or auto&&. Did you really intend to make a copy?

If it was instead

    String foo = "bar";
    auto baz = foo;

I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.

But languages that have type inference but allow type annotations at least allow you to try to hit that balance.

Type inference doesn't make these errors go away.

And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.

Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time.

C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.

I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it.

    void foo(MyType mt, const MyOtherType& mot);

However, it maybe doesn't work that well with things like class member names. YMMV

    using B64String = std::string;

    B64String encode(const std::string& text);
    std::string decode(const B64String b64);

The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.

> I can have an array of T, but I can't specify that T is Numeric?

Sure you can. If you have C++20 concepts:

  template<class T>
  concept Numeric = std::integral<T> || std::floating_point<T>;
  
  template<Numeric T>
  T twice(T x)
  { return x + x; }

  template<class T>
  typename std::enable_if<
    std::is_arithmetic<T>::value,
    T>::type twice(T x)
  { return x + x; }

    Numeric auto twice(Numeric auto x)
    { return x + x; }

And imagine what would happen when you get a few more 'auto' variables in the return expression. Suddenly your return type will depend on the implementation of your callees. And the code can then quickly become impossible to understand.

auto is overused.

Why would that be a problem ? It's super common in templates and has never troubled me the least

1. "My return type is whatever I happen to return" circumvents the ability of the type checker to ensure correctness.

2. More generally, the purpose of a specification (a function declaration in this case) is to declare what is required of a compliant implementation, and to provide a way to check the validity of that implementation. But when you make the types all become auto-deduced, you're basically reducing the specification to a ~ shoulder shrug "it does whatever it does" ~.

3. Moreover, as I alluded to in the comment, it quickly becomes near-impossible to meaningfully separate the definition from the declaration, whether that's because you want to hide it or because you want to compile it separately. Simply put, you lose modularity. It seems like a minor thing when (as in the example) the return value doesn't depend on types inferred from other callees' return values, but as soon as that ceases to be true, you suddenly tie together the implementations of multiple functions. At that point, your functions lose much of their power to abstract away anything, since as soon as you change the return expression for one function, it has the potential to break code (up to and including causing compilation errors) in the the entire chain of callers. (!)

4. Templates end up getting re-instantiated far more often than they need to be (which can slow down both the compilation and the runtime efficiency). You almost certainly don't want '0' and '(size_t)0' to result in duplicate instantiations when dealing with sizes, for instance.

5. Issue #4 can also result warnings/errors/bugs, since now you have a function that returns a different concrete type than you likely intended, which can result in everything from spurious warnings (signed/unsigned casts, for instance) to actual bugs (later truncation of other variables whose types were inferred incorrectly as a result).

6. The code becomes difficult for a human to read too. You now no longer have any idea what types some variables are supposed to be. Not only does this hamper your ability to cross-check the correctness of the implementation itself (just as with the declarations, in #1) but unless your function is trivial, this quickly makes it harder to even understand what the code is doing in the first place, never mind what it's supposed to do.

7. Proxy types become impossible to implement, since they won't undergo the intended conversions anymore.

All this just to reduce keystrokes might be a common trade-off, but a poor one. I can come up with more reasons, but hopefully this gets the point across.

> I can have an array of T, but I can't specify that T is Numeric?

This is what type-traits and 'concepts' are for, right?

> The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.

This is what std::is_integral gives you.

https://en.cppreference.com/w/cpp/types/is_integral

Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soon, one in python and one in ocaml. Perhaps that will provide a datapoint about learning the languages but maybe there will just be a lot of selection bias or library or environment or teacher differences. And how easy it is to learn a language probably isn’t the main datapoint to care about anyway.

Oh, I think there are great evidences, such as: dialyzer, or ruby3 and python3 shifting towards type signatures everywhere and gradual typing, or recent racket focus on typed racket. Oh, and the rise of typescript of course.

I mean, I've abandoned Python years ago, and I was quite surprised when I discovered python people are adding type annotations everywhere.

Sure, gradual typing is not a strictly enforced as in statically typed languages, but seems people are agree that modularity and abstraction without type signatures is painful in sufficiently large programs.

I don’t feel like this anecdote is evidence because I don’t think it’s inconsistent with the trend towards more static types over the last 5-10 years or so. For this anecdote to be convincing I would need to think that programming language design happens because of carefully thought out and researched decisions and quick feedback as good languages are used and bad languages are dropped, but I don’t believe this.

Yes, this is not a sound rigid empirical proof, it's an observation (i.e. unlike the case of anecdotal, you can measure the marketshare of user, how many do use dialyzer or typescript, etc etc). We can't simply ignore any observations that are not scientifically rigid, otherwise the whole edifice of philosophy or even some natural sciences should simply perish.

I don't think you can just omit that. I'm a fan of Lakatos here, if I have some observation, I think one need at least as convincing evidence or more rigid one to prove otherwise.

> because of carefully thought out and researched decisions

I think it's a better evidence exactly because it's what language users are asking about, and what large chunk of language users choose to use when they got a choice. This shows that quite a big share if not majority of programmers value type annotations.

To be clear, this is where I disagree. I don’t want to claim that people don’t think hard about language design or that users aren’t asking for these features as I think both of those statements are true. But I strongly disagree that languages doing things (and those languages being popular) is good evidence that those things are good.

I think a lot of language design is driven by fashion (ie keeping up with what similar languages are doing) and I claim that this is a more convincing reason for python having some gradual typing.

I think large number of people is moving to/from from python for gradual typing in aggregate, and I don’t think it’s happening on the margin either. I think any wise decisions about languages are more likely to be driven by practical considerations (what do people know, what are they used to, what can people be hired for, what libraries are available, what platforms are supported, what performance is required, and so on).

Just because python has a large market share, it doesn’t mean it’s users are supporters of gradual typing, it just means that they thought python was a good idea when they first started using it and they haven’t justified the cost of changing to something else. The users didn’t choose gradual typing they just chose “upgrade the language to the next version”

Even if I agreed with your claim that many users asked for gradual typing, I don’t agree that in aggregate users ask for things that will be good for them or good in general. Maybe users are just trying to figure out a way to say “we want our programs to be less buggy” and think this might help. I think there are better examples in programming language design of what can happen if you keep giving users what they are asking for.

In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.

dynamic languages (like smalltalk) were designed for live coding where the results are immediate, when that is broken and coding is done in a "dead" environment of course dynamic typing will cause problems that arent caught until runtime... but the original idea was one shouldnt have had to wait until runtime in the first place!

Any others?

Unfortunately the same amount of effort that has been applied to static type checking has not been applied to dynamic language environments.

It would have been very interesting to see what could be possible with the more advancement.

You cannot get mad at errors you don't know about.

Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.

Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object"

Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.

The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.

I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.

I've never thought of it that way, but that totally makes sense.

But I've worked with people who saw all compiler errors as things of the devil and wanted to defer as much as possible to runtime.

"go play with it"

"look it up"

"google it"

"read the fudging manual"

Of course, there are many great faculty who _do_ care greatly about teaching and always help students.

Sometimes there would be some proffessors there too to help you out.

When selecting a language for a recent project, that needed to run correctly, without extensive debugging that would be hard to simulate (too many states and interactions), I had a couple of important criteria:

0) checked static typing

1) ADTs (that are reasonably easy to use, read and write)

2) pattern matching (no way I'll get all the if/else right)

3) reasonably easy to write static const (pure functional) code

4) memory-safe

I've considered rust, but settled on haskell, as I needed it fast and I know haskell. While technically any Turing-complete language would work, I don't think C++ would be a fit for must-work code, even disregarding (4).

While I haven't used C++ in a while, it seems to me, encoding the constraints would be 3-10x as much code, or even more, with many checks/cracks left, and a lot of readability gone.

Clean and correct functional haskell code took a bit longer to write than say happy-path imperative python, but after fixing 2 or so bugs that manifested on pretty much the first (partial) use (like incorrect "<" vs. ">" and a bad constant), it has been running happily ever since. I didn't even bother simulating a full system configuration before a real-world customer acceptance test, because components worked on 1-2 inputs I tried, setting up a system would take a couple of hours and I couldn't think of reasonable failure scenarios. I haven't experienced similar correctness in other languages.

I know not much of Java, but my sentiments concerning C++ are even worse.

I do not regularly program in Haskell and far more often in Rust.

For what it's worth, C++ has HKTs in the form of template template parameters, making it possible to write, e.g., monad transformers, which cannot be done in Rust, last I checked. Now as for whether you'd actually want to do this in a production codebase...

It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.

Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).

Fast forward a decade and I'm evangelizing statically typed FP at conferences. The value of the compiler is redeemed after self-teaching and learning the "Whys".

Code that always upsets me is something like `Map<String, Object>` where a concrete type would work so much better (and faster).

Using a statically typed language, the most important thing you can do is USE IT. Let the type system save you from problems. Encode whatever you can in the types.

Bypassing it by casting always causes headaches.

This is the key bit, this is called static analysis, you don't need a type system in your language to do this, and you don't need to force doing it at compile time

Most developers appear to conflate the two, uncoupling static analysis and type systems would benefit most workflows

What assembly instructions should the compiler emit if you write sum ["foo", "bar"] ?