[nobleach]

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.

[ux266478]

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.

[anonzzzies]

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]

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?

[rootnod3]

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.

[tizzy]

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]

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]

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]

But you had called your list "one size fits all".

[nobleach]

...in an imaginary world where we're still writing code, yes. It's a musing, not a directive.

[matt_kantor]

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.

[jerf]

"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.

[nobleach]

oh yeah absolutely. The moment you start blowing up Go with features (for example) the speed decreases dramatically.

[unnouinceput]

"The compile speed of Go" - Delphi starts laughing

[jolt42]

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

[matt_kantor]

> 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]

Kotlin itself has opted for inline union types to represent error results: 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]

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]

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".

[never_inline]

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

[speed_spread]

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

[utopiah]

- The reach of JavaScript