5 ms·

The perfect programming language has: - The compile speed of Go - The performance of Go - The single binary compilation of Go - The type system of Kotl

The perfect programming language has: - The compile speed of Go - The performance of Go - The single binary compilation of Go - The type system of Kotlin - The ecosystem of JVM (packages for anything I could dream of) - The document sytem/tests of Elixir - The ability to go "unsafe" and opt for ARC instead of GC - The result monad/option monad and match statements from OCaml/Gleam - A REPL like Kotlin or even better, OCaml - A GREAT LSP for NeoVim - A package/module system that minimizes transient dependencies - No reliance on a VM like BEAM or JVM I still dream about this "one size fits all" language.

tizzy 6mo ago
I believe there are tradeoffs which is why this doesn't exist. Isn't the compile speed of Go so good because it's type system is much simpler?
- ModernMech 6mo ago
  Yes, programming languages are designed for a purpose and importantly for a concrete system. Erlang is the way it is because it was designed for Ericsson's phone network. C is the way it is because it was designed for the PDP-11. Logo is the way it is because is was designed for young children. Go is they way it is because it was designed by Google for Googlers. You can't design an abstractly "perfect" programming language without any context. Which is why the author I think focuses on "perfectable", as in the language can be made perfect for your purpose but it's not going to be one size fits all.
  - nobleach 6mo ago
    No, I realize that. It doesn't stop me from having my "perfect language wishlist". The author calling out "perfectable" is what got me thinking. What language would I choose if I were able to "perfect" it just a bit more?
    - ModernMech 6mo ago
      But you had called your list "one size fits all".
      - nobleach 6mo ago
        ...in an imaginary world where we're still writing code, yes. It's a musing, not a directive.
- nobleach 6mo ago
  oh yeah absolutely. The moment you start blowing up Go with features (for example) the speed decreases dramatically.
- jerf 6mo ago
  "Isn't the compile speed of Go so good because it's type system is much simpler?" That, and forgoing fancy compile-time optimization steps which can get arbitrarily expensive. You can recover some of this with profile-guided optimization, but only some and my best guess based on the numbers is that it's not much compared to a more full (but much more expensive) suite of compile-time optimizations.
- matt_kantor 6mo ago
  One thing I like about TypeScript is that there's tooling for "quickly strip out the types and give me something I can run; I don't care if it's correct". You can run the (slower) type checker concurrently with that (or whenever it's convenient to do so), but type-checking doesn't necessarily block you from being able to play with runtime stuff. I understand that this workflow can't be realized in languages whose runtime semantics are derived from type-level stuff, and while that can be quite convenient I'm personally willing to give it up to unlock the aforementioned workflow.
deleted 6mo ago
[deleted]
ux266478 6mo ago
Common Lisp through SBCL fits this for everything but changing GC strategies. I'm not sure why you'd do that, though. SBCL's generational GC is faster in all cases, easy to reason about, and trivial to pause. In many of these other categories, clisp exceeds requirements. The REPL and Doc situation is so good it's honestly worth it for those alone. People put up with `):'(,@ soup for good reason.
- rootnod3 6mo ago
  Common Lisp Is exactly that. I wish I could use it at work. All my personal stuff nowadays is CL only. There is no other choice.
- anonzzzies 6mo ago
  I luckily have the freedom to work with SBCL almost fulltime. It is a joy; shame most will never get to experience it (few jobs, parenthophobia etc).
  - nobleach 6mo ago
    Alright, you and your sibling reply have me wanting to look at it. I wrote Scheme/Racket when I was going through The Little Schemer and SICP. I'll buy a common lisp book. Any recommendations?
unnouinceput 6mo ago
"The compile speed of Go" - Delphi starts laughing
matt_kantor 6mo ago
> The result monad/option monad and match statements from OCaml/Gleam Do you mean actual monads or just the specific result/option containers? If you mean a fully-fledged monad abstraction then you need a more sophisticated type system than what Kotlin provides (i.e. higher-kinded types).
- tadfisher 6mo ago
  Kotlin itself has opted for inline union types to represent error results: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441... The existing Result type was a mistake to expose to users, IMO, as it encourages exceptions-as-control-flow and error type hierarchies which complicate error-handling even further. The convenient `runCatching` API also completely breaks reasonable error-handling on the JVM and Kotlin's structured concurrency (which happens to use exceptions-as-control-flow to signal coroutine cancellation). Overall, Kotlin is moving away from higher-kinded types in the core language, not toward them.
  - matt_kantor 6mo ago
    I'm not a frequent Kotlin user but none of that surprises me. My comment was asking about nobleach's imaginary "perfect programming language", which is clearly not Kotlin.
- nobleach 6mo ago
  I'd settle for the Result/Option containers. Kotlin does have ArrowKt to attempt to achieve all the functional goodness of Scala. I think for my needs though, I'd appreciate Rust's "Result".
utopiah 6mo ago
- The reach of JavaScript
jolt42 6mo ago
performance of Go - why not Fortran? type system of Kotlin - why not Scala/Haskell? Repl like Kotlin, why not Clojure?
never_inline 6mo ago
What do you like so much about Kotlin type system, and document / testing of elixir?
speed_spread 6mo ago
The type system of Kotlin? It's the same as Java + syntactic sugar for nullability. Don't pretend otherwise.

tizzy 6mo ago

I believe there are tradeoffs which is why this doesn't exist. Isn't the compile speed of Go so good because it's type system is much simpler?

ModernMech 6mo ago
Yes, programming languages are designed for a purpose and importantly for a concrete system. Erlang is the way it is because it was designed for Ericsson's phone network. C is the way it is because it was designed for the PDP-11. Logo is the way it is because is was designed for young children. Go is they way it is because it was designed by Google for Googlers. You can't design an abstractly "perfect" programming language without any context. Which is why the author I think focuses on "perfectable", as in the language can be made perfect for your purpose but it's not going to be one size fits all.
- nobleach 6mo ago
  No, I realize that. It doesn't stop me from having my "perfect language wishlist". The author calling out "perfectable" is what got me thinking. What language would I choose if I were able to "perfect" it just a bit more?
  - ModernMech 6mo ago
    But you had called your list "one size fits all".
    - nobleach 6mo ago
      ...in an imaginary world where we're still writing code, yes. It's a musing, not a directive.
nobleach 6mo ago
oh yeah absolutely. The moment you start blowing up Go with features (for example) the speed decreases dramatically.
jerf 6mo ago
"Isn't the compile speed of Go so good because it's type system is much simpler?" That, and forgoing fancy compile-time optimization steps which can get arbitrarily expensive. You can recover some of this with profile-guided optimization, but only some and my best guess based on the numbers is that it's not much compared to a more full (but much more expensive) suite of compile-time optimizations.
matt_kantor 6mo ago
One thing I like about TypeScript is that there's tooling for "quickly strip out the types and give me something I can run; I don't care if it's correct". You can run the (slower) type checker concurrently with that (or whenever it's convenient to do so), but type-checking doesn't necessarily block you from being able to play with runtime stuff. I understand that this workflow can't be realized in languages whose runtime semantics are derived from type-level stuff, and while that can be quite convenient I'm personally willing to give it up to unlock the aforementioned workflow.

deleted 6mo ago

[deleted]

ux266478 6mo ago

Common Lisp through SBCL fits this for everything but changing GC strategies. I'm not sure why you'd do that, though. SBCL's generational GC is faster in all cases, easy to reason about, and trivial to pause. In many of these other categories, clisp exceeds requirements. The REPL and Doc situation is so good it's honestly worth it for those alone. People put up with `):'(,@ soup for good reason.

rootnod3 6mo ago
Common Lisp Is exactly that. I wish I could use it at work. All my personal stuff nowadays is CL only. There is no other choice.
anonzzzies 6mo ago
I luckily have the freedom to work with SBCL almost fulltime. It is a joy; shame most will never get to experience it (few jobs, parenthophobia etc).
- nobleach 6mo ago
  Alright, you and your sibling reply have me wanting to look at it. I wrote Scheme/Racket when I was going through The Little Schemer and SICP. I'll buy a common lisp book. Any recommendations?

unnouinceput 6mo ago

"The compile speed of Go" - Delphi starts laughing

matt_kantor 6mo ago

> The result monad/option monad and match statements from OCaml/Gleam Do you mean actual monads or just the specific result/option containers? If you mean a fully-fledged monad abstraction then you need a more sophisticated type system than what Kotlin provides (i.e. higher-kinded types).

tadfisher 6mo ago
Kotlin itself has opted for inline union types to represent error results: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441... The existing Result type was a mistake to expose to users, IMO, as it encourages exceptions-as-control-flow and error type hierarchies which complicate error-handling even further. The convenient `runCatching` API also completely breaks reasonable error-handling on the JVM and Kotlin's structured concurrency (which happens to use exceptions-as-control-flow to signal coroutine cancellation). Overall, Kotlin is moving away from higher-kinded types in the core language, not toward them.
- matt_kantor 6mo ago
  I'm not a frequent Kotlin user but none of that surprises me. My comment was asking about nobleach's imaginary "perfect programming language", which is clearly not Kotlin.
nobleach 6mo ago
I'd settle for the Result/Option containers. Kotlin does have ArrowKt to attempt to achieve all the functional goodness of Scala. I think for my needs though, I'd appreciate Rust's "Result".

utopiah 6mo ago

- The reach of JavaScript

jolt42 6mo ago

performance of Go - why not Fortran? type system of Kotlin - why not Scala/Haskell? Repl like Kotlin, why not Clojure?

never_inline 6mo ago

What do you like so much about Kotlin type system, and document / testing of elixir?

speed_spread 6mo ago

The type system of Kotlin? It's the same as Java + syntactic sugar for nullability. Don't pretend otherwise.