<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>rtfeldman</author><text>Oh I totally agree that it&amp;#x27;s a good idea to annotate top-level functions even if you don&amp;#x27;t have to, and better compiler error messages is one of the benefits of doing that. Personally I basically always choose to annotate them except in the very specific situation of writing beginner introductory materials, when it&amp;#x27;s not a given that the reader actually knows how to read the annotations yet.&lt;p&gt;One of the practical benefits of having full inference is that these signatures can be inferred and then correctly generated by an editor. Like I can  write the implementation of my function, and then tell my editor to generate a type annotation, and it can always generate a correct annotation.&lt;p&gt;That saves me time whenever I&amp;#x27;m writing the implementation first (I often write the annotation first, but not always), even if I end up wanting to massage the generated annotation stylistically. And unlike having Copilot generate an annotation, the type inference system knows the actual correct type and doesn&amp;#x27;t hallucinate.&lt;p&gt;To me, the main benefits of type inference at the top level are that they offer beginners a more gradual introduction to the type system, and that they offer experts a way to save time through tooling.</text><parent_chain><item><author>johnfn</author><text>&amp;gt; 1. The typesystem will be sound, ML-like, and so simple that any code that doesn&amp;#x27;t interact with external data will not need _any_ type annotations.&lt;p&gt;I&amp;#x27;ve tried using languages with this promise, such as Haskell, and also spent a lot of time with TypeScript, which makes a different set of tradeoffs, and I feel like I&amp;#x27;ve spent enough time on both to know this is the wrong tradeoff to make. It sounds flashy to be able to say that no type annotations are necessary, but in practice what it ends up meaning is that you end up tracking down errors in the wrong parts of your code because the compiler can&amp;#x27;t figure out how to reconcile problems.&lt;p&gt;e.g., you have function A incorrectly call function B. How does the compiler know if A has the wrong arguments, or B has the wrong signature? It can&amp;#x27;t! I know that&amp;#x27;s a toy example, but it really does lead to a lot of real-world frustration. Sometimes the type errors are very far away from where the actual issues are, and it can lead to a lot of frustration and wasted time.&lt;p&gt;The TS approach of &amp;quot;please at least annotate all your function signatures&amp;quot; isn&amp;#x27;t nearly as flashy, but it strikes a much better utilitarian balance.</text></item><item><author>davidatbu</author><text>I&amp;#x27;m super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs:&lt;p&gt;1. The typesystem will be sound, ML-like, and so simple that any code that doesn&amp;#x27;t interact with external data will not need _any_ type annotations.&lt;p&gt;2. An aim to make it the fastest managed compiled lang around (faster than golang).&lt;p&gt;3. Functional.&lt;p&gt;4. A focus on fast compile times from the beginning (like golang).&lt;p&gt;5. Serde from rust is essentially a language builtin.&lt;p&gt;6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language).&lt;p&gt;What I&amp;#x27;m unclear about is:&lt;p&gt;1. Whether they&amp;#x27;ll support macros,&lt;p&gt;2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim from my hands).&lt;p&gt;It&amp;#x27;d be dope if anyone more familiar can comment on the above!&lt;p&gt;Also, as feedback to Richard Feldman, your podcast is (imo) great marketing for your lang! It&amp;#x27;s what&amp;#x27;s made me excited about your PL.&lt;p&gt;EDIT: Forgot another feature I&amp;#x27;m allured by: ability to run programs with type errors (as best as one can).</text></item></parent_chain></comment><story><title>Roc – A fast, friendly, functional language</title><url>https://www.roc-lang.org/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>ReleaseCandidat</author><text>The Haskell approach is &amp;quot;annotate all top level declarations&amp;quot; (even if not exported) and OCaml has module signatures. But both (and Roc) don&amp;#x27;t make up new &amp;quot;types&amp;quot; like Typescript does.</text><parent_chain><item><author>johnfn</author><text>&amp;gt; 1. The typesystem will be sound, ML-like, and so simple that any code that doesn&amp;#x27;t interact with external data will not need _any_ type annotations.&lt;p&gt;I&amp;#x27;ve tried using languages with this promise, such as Haskell, and also spent a lot of time with TypeScript, which makes a different set of tradeoffs, and I feel like I&amp;#x27;ve spent enough time on both to know this is the wrong tradeoff to make. It sounds flashy to be able to say that no type annotations are necessary, but in practice what it ends up meaning is that you end up tracking down errors in the wrong parts of your code because the compiler can&amp;#x27;t figure out how to reconcile problems.&lt;p&gt;e.g., you have function A incorrectly call function B. How does the compiler know if A has the wrong arguments, or B has the wrong signature? It can&amp;#x27;t! I know that&amp;#x27;s a toy example, but it really does lead to a lot of real-world frustration. Sometimes the type errors are very far away from where the actual issues are, and it can lead to a lot of frustration and wasted time.&lt;p&gt;The TS approach of &amp;quot;please at least annotate all your function signatures&amp;quot; isn&amp;#x27;t nearly as flashy, but it strikes a much better utilitarian balance.</text></item><item><author>davidatbu</author><text>I&amp;#x27;m super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs:&lt;p&gt;1. The typesystem will be sound, ML-like, and so simple that any code that doesn&amp;#x27;t interact with external data will not need _any_ type annotations.&lt;p&gt;2. An aim to make it the fastest managed compiled lang around (faster than golang).&lt;p&gt;3. Functional.&lt;p&gt;4. A focus on fast compile times from the beginning (like golang).&lt;p&gt;5. Serde from rust is essentially a language builtin.&lt;p&gt;6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language).&lt;p&gt;What I&amp;#x27;m unclear about is:&lt;p&gt;1. Whether they&amp;#x27;ll support macros,&lt;p&gt;2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim from my hands).&lt;p&gt;It&amp;#x27;d be dope if anyone more familiar can comment on the above!&lt;p&gt;Also, as feedback to Richard Feldman, your podcast is (imo) great marketing for your lang! It&amp;#x27;s what&amp;#x27;s made me excited about your PL.&lt;p&gt;EDIT: Forgot another feature I&amp;#x27;m allured by: ability to run programs with type errors (as best as one can).</text></item></parent_chain></comment><story><title>Roc – A fast, friendly, functional language</title><url>https://www.roc-lang.org/</url></story>