Programming Languages

1167 readers

1 users here now

Hello!

This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.

The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:

This community is dedicated to the theory, design and implementation of programming languages.

Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.

This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.

This is the right place for posts like the following:

"Check out this new language I've been working on!"
"Here's a blog post on how I implemented static type checking into this compiler"
"I want to write a compiler, where do I start?"
"How does the Java compiler work? How does it handle forward declarations/imports/targeting multiple platforms/?"
"How should I test my compiler? How are other compilers and interpreters like gcc, Java, and python tested?"
"What are the pros/cons of ?"
"Compare and contrast vs. "
"Confused about the semantics of this language"
"Proceedings from PLDI / OOPSLA / ICFP / "

See /r/ProgrammingLanguages for specific examples

Related online communities

founded 1 year ago

MODERATORS

armchair_progamer@programming.dev

Type inference was a mistake (borretti.me)

submitted 7 months ago by SuperFola@programming.dev to c/programming_languages@programming.dev

46 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] firelizzard@programming.dev 2 points 7 months ago (1 children)

To me this is an argument for why Go should not add type inference to function/method declarations. Go is like Rust (I guess, I haven't used Rust) - type inference works for declaring a variable (or const) and generic type parameters but not for type declarations, methods, functions, etc. I was in the "more inference is always better" camp but now I'm thinking Go has the perfect level of inference. Except for function literals/lambdas. I really want go to infer the argument and return types when I'm passing a function literal/lambda to a function.

[–] BatmanAoD@programming.dev 5 points 7 months ago* (last edited 7 months ago)

The thing about Rust's type inference that seems wild to anyone who hasn't seen Hindley-Milner/ML style type systems before is that it's "bidirectional" (in quotes because that's not a proper type theory term as far as I know). The type of the left-side of an assignment can determine the type (and behavior!) of the right side. For instance, this is ambiguous:

let foo = [("a", 1), ("b", 2)].into_iter().collect();

The expression creates an iterator over the (letter, number) pairs, and collect() stores the elements in a newly created container. But which container type? Here are two valid variants:

let foo: Vec<_> = [("a", 1), ("b", 2)].into_iter().collect();

This creates a vector with items ("a", 1) and ("b", 2).

let foo: HashMap<_, _> = [("a", 1), ("b", 2)].into_iter().collect();

This creates a mapping where "a" and "b" are keys, and 1 and 2 are the corresponding values.

Playground link in case you'd like to mess with this concept: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=76f999f4db600415643b0c58c19c69b7