Hacker News Reader

Comment by TulliusCicero | Hacker News Reader

> Improved type inference

> We want types, not boilerplate. Sometimes it's best to let the compiler figure out what things are by itself.

At first I thought type inference was cool too, but more and more I don't like it. I prefer being able to see a variable's type easily, even when skimming over code. Type inference makes code less readable to me.

View on HN

Type inference locally is great. Doing `val something = MyClass()` or `val something = someFunc()` . No ambiguity, just less typing and clutter. At bounds however (function input/output for instance) I prefer explicit types, less chance for mistakes and the signature acts as documentation to what the function does.

Static typing removes freedom I am addicted to with duck typing, however, I only ship TDD code which also serve as coding documentation. Both are protective but if you're not writing tests then by all means use static typing.

I'm finding this hard to relate to. Our circumstances and experiences must be pretty different. But I'm afraid to me that sentence reads a bit like "I have a lathe so I don't need a bicycle". You or I might not do bicycle jobs, or lathe jobs, but it's a bit of a stretch to imply one renders the other irrelevant.

I find it interesting that you characterise static typing as about safety. I think it's more about communication. (for me this includes "communication to myself when I wrote this seven years ago and didn't think about it since", which I appreciate may be a bit of an edge case). Tests are also a great medium of communication, but a different one - in which case the metaphor becomes swap a sonnet for a sonata? I'd like both please, but maybe not always at the same time :-D

Neither tests nor types are documentation.

> if you're not writing tests then by all means use static typing

I know you're not saying this, but your wording implies it to a bit... Tests to cover <the things covered by static typing> are only one of the uses for automated testing. There's plenty of places (most of them) where automated testing is just as useful with a statically typed language.

Duck typing (structural typing) is orthogonal to dynamic vs static. Typescript being an example of a statically typed language whose type system is centers on structural typing

> Type inference locally is great. Doing `val something = MyClass()` or `val something = someFunc()` . No ambiguity, just less typing and clutter.

As much as I can get behind val something = new MyClass(), where the type is explicitly mentioned on the line, it's a whole other story for val something = someFunc().

You have no way to know the type of that variable without looking at the function itself which is more work than should be needed.

Your IDE/Editor can show that information to you. Having it forced to be written down there just seems unnecessary to me.

The amount of time I look at code outside of an IDE is by far not zero.

Just checking quickly a repository on GitHub for example.

I agree, GitHub should consider adding this feature.

Type inference everywhere can make code less readable, but type inference when it's clearly the code author's intent that the type of the variable should not be of much interest to anyone improves readability.

A common example of this is a variable that's initialized in one line, fed into another function in the very next line, and then never used again. [1] If the function call that produces it, and the function call that consumes it is named well, the variable's type is often, but not always superfluous.

It's like naming for loop variables. Sometimes, you want a specific, detailed name for them. Other times, you just call it 'i', because what it is... Is not very important. It's a counter, counter goes up until we hit the end of a list, don't think about it too much.

[1] The two function calls could have been mashed together, but that would make the code less readable. The full variable type could have also been included, but its not very relevant to the intent of the code - which is simply[2] feeding the output of one function as an input into the other.

[2] Obviously, when contextual information (like real-world side effects of creating a particular variable - say, a thread, or a record...) that complicates the "Create -> Use" case is relevant, or if the APIs in question have a lot of function overloading, or poorly-named interfaces, or if non-trivial casting is going to take place, it may still be beneficial to explicitly provide the variable type.

Type inference w/ overlays is usually enough. The only thing I’m missing with VSCode rust overlays is they sometimes don’t show the lifetime on an inferred type which makes it a little more annoying.

One of the things that's made me the most frustrated learning rust is all the type coercion and inferencing. Sometimes code will just work when I have the wrong mental model because types are coerced but then it ends up biting me later when suddenly everything breaks because it can't coerce anymore and I find out nothing was the type I thought it was. I wish there was a way to turn it off while I'm learning just so I can understand what's really happening.

Nobody forces you to rely on type inference. It’s perfectly valid Rust where you type everything if you so wish. This might actually be a good way to learn the ins and outs of the type system.

EDIT: Also, what do you mean by type ‘coercion’? As far as I know the types in Rust are never silently coerced to anything. They just are what they are.

They mean inference. Generics get resolved to different types (and lifetimes) depending on surrounding code.

wow, I never contemplated before whether that kind of language design could be evil, but you make me think it might be. Maybe not in the ordinary course of sensible use, but in some horrible "I didn't think of that". Then I feel a bit hypocritical because I'm sure I've relied on a hundred more problematic abstractions without worrying about it.

Far from evil, it's amazingly useful, and is why things like `let x: Vec<_> = foo.collect();` work (the return type of the `collect` method is generic). Rust stops type inference at function boundaries, so the precise type of something is never far away if you need it.

I concur. Rust does it very sensible and elegantly. I will note that the other thing rust does is let you under specify the lifetimes of a function signature but when compile errors happen they tell you what they ended up inferring and you can always correct it when you need something slightly different. The two features are critical in making Rust code easy to read and write as the types and lifetimes can get tedious and most of you have to specify it literally everywhere.

> As far as I know the types in Rust are never silently coerced to anything.

There are some specific coercion sites and kinds: https://doc.rust-lang.org/reference/type-coercions.html

True, although coercion in Rust is quite limited (it doesn't even coerce smaller ints into larger ones), and the coercions that exist are pretty harmless IMO (like letting you call a function that accepts a `&foo` if all you have is a `&mut foo`). I suspect they're referring to something else, as I've never seen coercion highlighted as a pain point before.

types are not coerced in rust? you have to implement explict `From` traits and call `into`.

I think they meant to say “inferred”

I've never written rust, so maybe this is way off. But could the code editor display the inferred type right next to the variable declaration?

Yes, I believe rust-analyzer language server + vscode extension is the setup I have that does this for me.

Yes, highly recommend this setup. Displaying inferred type + compiler errors has been amazing while learning Rust.

It could, but then you put off grumpy people like me with old editors that don't do that kind of thing. Plus you need fancy tools to look at patches. And none of it is going to work inside tokio's select macro (or other useful macros), which could be a lot of your code, depending on what you're writing.

I'd rather work in a language where nobody has type information. It's a much more even playing field. ;p

What are you using for an editor? Both emacs and vim can do that kind of thing.

I use joe. I've been using it for 25 years at this point, and it works enough, and I'm not interested in changing. About 15 years ago, I upgraded to a version of joe with syntax highlighting which was pretty cool, but I'm not much interested in more than that. I do occasionally poke around with things in fancy IDEs (it's easier to fiddle with Arduino projects with an IDE than otherwise, because nobody writes about how to do the pieces individually... but maybe I can drive platform.io from the command line in the future), but I'm much happier with a simple as dirt editor, and another terminal to run Make in (or whatever, using Rust for work now, so running cargo instead of make).

IMO a decent editor is a must for statically typed languages - it's such a productivity boost to navigate by type information, type safe refactoring, etc.

Main benefit of static typing is enabling tooling to reason about your code - not using IDEs is throwing a huge chunk of it away. Historically it was easy to get projects that would be too large for real-time tooling - but these days the IDEs got better and you can get 32 or even 64 GB ram into a workstation trivially - I haven't seen a scenario like that in years.

I've also noticed GitHub supports type navigation in some languages, but yeah for nontrivial reviews I'll usually do a checkout anyway.

I get what you mean but it does come across a bit as "why would anyone want C compiler, ASM provides a much more even playing field". All of the "old" editors that people still use have LSP plugins these days, so feel free to treat yourself any day now. :)

Non-sarcastically: type systems have their place but are not quite there yet. I say this as someone currently doing Advent of Code in Haskell, which surely cannot be accused of being lacking in type safety. What I would love to see in a type system is the flexibility that (for example) Rails' ActiveRecord adds to a class while still being type-safe. AFAIK, no such system exists (yet) but I would love to be proven wrong sometime in the future.

Most editors (or plugins for them) that support a LSP, like rust analyzer[0], can do it. This includes afaik (neo)vim (via coc.nvim), vscode (via rust-analyzer extension), emacs and Clion.

[0]: https://rust-analyzer.github.io/

>(neo)vim (via coc.nvim)

I think vim-lsp and Neovim's native LSP both have it too

Thank you for pointing these out. I personally use coc but vim lsp was also a good experience. This lost is by far not complete as many other editprs also support LSP servers, like helix.

I already know Rust, and unexpected implicit refs and derefs in match/if let expressions or method calls still trip me up when writing or reading new code (especially now that match ergonomics can make `match &Option<T> { Some(x)` compile but not the way you expect). Nowadays I avoid higher-order generic functions like .filter(|...| ...) so don't hit unexpected &&T etc. there, but matching on Entry and regex searches still trips me up.

You should consider configuring your editor to display types inline, it's awesome. It'll provide annotations next to the code with relevant types, so you don't have to click or anything to display the type. I found it also sped up my learning process by increasing the bandwidth of the feedback loop between me and the language, so I developed an intuition for type inference rules & the return types of stdlib functions faster.

https://stackoverflow.com/questions/66174400/how-to-get-type...

Rather than turn off type coercion and inference, it sounds like you want a way to see the coerced/inferred types right in your editor. Rust Analyzer does this for you — there's a plugin for VSCode that will show inferred types as inline hints in your editor next to each expression, so you're never left guessing.

Personally, I agree, Rust is nigh impossible to write without types in your editor; thankfully Rust Analyzer provides them.

My IDE can show me inferred types as an overlay in my editor (even in languages with dynamic types like Ruby, jetbrains inference is pretty good when the code is simple), perhaps look for an extension for your preferred editor?

If GitHub could dd support for it, then that would be amazing.

As it stands, type inference has a tendency to make code reviews more difficult.

Why Github? I'm assuming you mean their code review interface, which is so incredibly lacking I don't even bother with it anymore and I just pull the branch locally and use my IDE.

It is lacking, but I haven't found practical ways to review it. I tried the github extension in VS code but the experience was even worse for me.

Could you share details about how do you do it? I'm very interested!

The IntelliJ editor lets me navigate all changed files, full intellisense and lets me add comments and do approvals directly from my IDE interface.

Then you need that support in every related place, as the other comment about GitHub points out.

The problem is when you get things like:

var someLongThing <application.someHierarchy.someLongAssPackage.someLongThing> = new application.someHierarchy.someLongAssPackage.someLongThing()

    class class1<T extends Comparable<T> >
        implements SmallestLargest<T> 
        T[] values;

This is a spot where inference doesn't work, but has the same problem as the relatively tame example you used.

The solution here is not to eliminate the type signatures. The solution is not to wait until compile time to figure out the type of a thing. Nominal typing, as in named types, is the solution here. If you have a 'thing', which also happens to be an application.someHierarchy.someLongAssPackage.someLongThing implements application.someHierarchy.someLongAssPackage.someInterface, anotherLongAssDefinitionForTheReturnTypes but that's an implementation detail, not a type description.

It's an Address, or a customer impression, or a similar product, or a fuel tank. Just fucking call it what it is instead of pretending like you're working on your PhD thesis. Your coworkers aren't robots, or academics, they're human beings who've got real work to do and kissing your architectural astronaut butt/complementing your farts are not on the list. Name things like a human. A wise human, but a human.

Not really, that is solved with aliases. The problem really comes to life when using strongly typed generic functions that must be generic over their return type. This most notably occurs with Rust iterators. Try writing out the type of this thing explicitly:

    let pos_nums = v.iter().map(|s| s.parse::<u64>().unwrap()).filter(|n| n > 0);

Hint: you literally can't in current Rust because closures have Voldemort types, you can't name their type. And even if you could, the resulting type would be horrendous.

Explicit types are useful in some places. Type inference doesn't mean you can't use them, just that you don't have to spell them out everywhere even when they aren't useful.

yeah, to be fair I only know it through the C++ `auto` keyword, but I dislike its overuse. It's great for weird templated iterator types but I prefer to see the concrete type if it's a reasonable length.

With C++’s implicit conversions, it makes that less of an issue though. Like a function returning long and assigning to an int “just works” and can silently trunctate. With auto, both are long

that's more an issue of editor integration. F# in Vscode for example overlays what types it has inferred automatically.

And what happens in every other tool that displays source code?

Who cares? That's the point of an integrated editor...

I think this can be a downside/cost that should be considered.

I wouldn't say "because type inference can be harder to read in some places, it should always be avoided".

I try to avoid using it where the type isn't obvious from the context. But when it is, I like it a lot.

> I prefer being able to see a variable's type easily, even when skimming over code. Type inference makes code less readable to me.

An IDE can still show the inferred types!

Or the question you should always ask: What if the compiler gets it wrong? Is there a way for you to tell?

Compiler/runtime bugs are always painful, I don't see that type inference is a special case there.

Fortunately such bugs are pretty uncommon.

Is it a bug if the compiler thinks that maybe the value could grow too large to fit in an integer so it promotes it to a floating point type. But then you compare it to a value that is converted out of a string of ASCII digits and the comparison is off by 1 because 4 != 3.99999999996 and this causes your code to iterate one additional loop which doesn't cause an immediate problem except about 1 in every 256 times it causes a boundary condition where the next packet will have a corrupt first byte?

Technically the compiler technically did nothing wrong, but you are still left with a head scratcher because all of the logic seems sound and yet it produces occasional garbage.

type inference isn't magic. It would absolutely be a bug for the compiler to change the type of a variable from an int to a float because it thinks there will be overflow.

> Technically the compiler technically did nothing wrong

I don't know a single language where integers are "promoted" to floats when they get large; certainly no statically typed language. You could argue JavaScript does this, but it's neither compiled nor does it actually have integers. So yes, if a compiler did that it would be a bug.

What compiler does that? What you're describing sounds like a weirdly designed type system, not a compiler that implements it.

That said, this is an example of the compiler being wrong.

If a value is changed to a data representation with different comparison semantics, and later compared to a different value of a different representation, it means the original optimization (hand wave over the definition of that) was unsound in the first place. AOT compilers would classify this as a bug that needs to be fixed imminently, and JIT compilers that do this kind of thing use something called dynamic deoptimization to remove the change once its been invalidated.

Scala's compiler used to widen prematurely and apply implicit conversions similarly to what you described.

Scala 3 doesn't do that [1]. The new inference algorithm will, however, prefer a generic method over the same named method without a generic argument in scope when no typing hints are present in the source code when there are two possible matches for an inference completion. This can then cause problems when the generic expects some kind of given parameter:

    def foo: String = ...
    def foo[A:SomeRequiredThing]:A = ...

    //in some other place
    foo shouldBe("hello") // foo[String](using SomeRequiredThing[String])
                          // gets preferentially selected by the scala 3
                          // inference algorithm, which can lead to surprising
                          // though not "incorrect" results [also 1]

[1] https://www.youtube.com/watch?v=lMvOykNQ4zs

Yes, promoting an integer to a float is 100% wrong and should result in a compilation error (if you dislike overflows) or an integer overflow (if you dislike compilation errors) or even a promotion to a BigInt type (if you dislike both other alternatives). Promotion to a float is always wrong.

Reply on news.ycombinator.com