3 ms·

I want a language with: - the memory, thread safety, and build system of Rust - the elegant syntax of OCaml and Haskell - the expressive type system of Haske

by prmph 8mo ago

I want a language with: - the memory, thread safety, and build system of Rust - the elegant syntax of OCaml and Haskell - the expressive type system of Haskell and TypeScript - the directness and simplicity of JavaScript Think coding agents can help here?

gcr 8mo ago
Nim comes close to what you want. Looking a bit further out, F# and Swift also come close.
viraptor 8mo ago
You have conflicting requirements there - expressive type systems are not direct and simple. And elegant is subjective. But seriously though: have you tried to see how far you can get with the design right now? You can start iterating on it already, even if the implementation will lag.
- prmph 8mo ago
  I do not have conflicting requirements. Expressive type system ARE direct and simple. Expressive power is the ratio how strongly/clearly you can encode invariants to how complex and ceremonious the syntax of it needs to be. See how JS, a language usually seen as a middling/mediocre language, can distill the basic good parts of OOP into very direct and clear idioms? I can just create an object literal and embed simple methods on them that receive the "this" pointer and use it. The constructor would be just a regular function. None of the cruft of standard OOP. See how you define an enumerable union in TypeScript? Very simple. And yet I can think of many major languages that do not have this, certainly not with a lot of ceremony and complexity. And I can go on.
  - viraptor 8mo ago
    > the expressive type system of Haskell > Expressive type system ARE direct and simple. Those result in a conflict because given expressive types, people will make them not simple. For example, you realise why Haskell continuously gets academic papers like "Functor is to Lens as Applicative is to Biplate; Introducing Multiplate"? There's no reason for something like that in Go for example, because it's less expensive and the signatures are trivial. > JS (...) can distill the basic good parts of OOP into very direct and clear idioms? Clear in that one specific project context that you need to know. Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place.
    - prmph 8mo ago
      > There's no reason for something like that in Go for example, because it's less expensive [sic] [1] and the signatures are trivial. Whoah, Are you saying, for example, that generics are not useful? That's quite the claim. In that case, to make things even simpler, let's remove recursion, functions as data, even type systems altogether, because they lead to "complex" code. See where your reasoning leads? Any language feature can be abused. In the same vein, you also say: > Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place. One can create OOP in any most modern Turing-Complete languages, so this is not a strong argument. [1] I believe you meant "expressive" here
      - viraptor 8mo ago
        > Are you saying, for example, that generics are not useful? That's quite the claim. That's why I didn't make that claim. If you just want to invent straw men, I'm out.
        prmph 8mo ago
        That is your implied claim. If that is not it I'm not sure what your arguments is. You mentioned that Go does not have certain advanced features and thus does not lend itself to tying oneself up in complexities. I'm asking you where you draw the line.
embedding-shape 8mo ago
All of those things have been built before, you're even referencing existing languages that have those "features". Parent seemingly was asking for people to build something completely novel, that doesn't have any FOSS code available that done that thing before. And yes, LLMs/agents can help you do it for sure, I'm currently building the lisp of my dreams in my freetime, and already have compiler, interpreter, UI framework and some other things already done in a way I'm happy with.
- prmph 8mo ago
  Yeah, the "novel" bit is about integrating all those aspects into one language. And trust me, such a language that captures enough mindshare is absolutely needed. People thought Rust was going to be it, but it got taken over by the idea of it being the next C++. IF LLMs are what you make them out to be, it shouldn't have been long before we saw serious attempts at such languages, but I suspect LLMs are of barely any help here beyond some basic implementation tasks.
  - embedding-shape 8mo ago
    > Yeah, the "novel" bit is about integrating all those aspects into one language. But do you think GP, who I initially wrote that comment to, would agree with that? All those features and integrations have examples in the FOSS world already, wouldn't the LLM just use what it learned from that? > but I suspect LLMs are of barely any help here beyond some basic implementation tasks. Disagree, as mentioned I've already managed to get together my own language that works for my purposes, and they did more than just "basic implementation tasks" although of course I've been reviewing and deciding stuff, no vibe coding here.
artpar 8mo ago
I tried that over a month except '- the directness and simplicity of JavaScript' https://github.com/artpar/guage https://github.com/artpar/guage But somehow the language feels so foreign. it can obviously do hello world, but I don't have a real use case PS: the "Pure symbols only" is no longer true, most symbols have been converted to English names and, the "days" you see there in the markdowns are "claude code sessions", not actual days

by prmph 8mo ago

gcr 8mo ago

Nim comes close to what you want. Looking a bit further out, F# and Swift also come close.

viraptor 8mo ago

You have conflicting requirements there - expressive type systems are not direct and simple. And elegant is subjective. But seriously though: have you tried to see how far you can get with the design right now? You can start iterating on it already, even if the implementation will lag.

prmph 8mo ago
I do not have conflicting requirements. Expressive type system ARE direct and simple. Expressive power is the ratio how strongly/clearly you can encode invariants to how complex and ceremonious the syntax of it needs to be. See how JS, a language usually seen as a middling/mediocre language, can distill the basic good parts of OOP into very direct and clear idioms? I can just create an object literal and embed simple methods on them that receive the "this" pointer and use it. The constructor would be just a regular function. None of the cruft of standard OOP. See how you define an enumerable union in TypeScript? Very simple. And yet I can think of many major languages that do not have this, certainly not with a lot of ceremony and complexity. And I can go on.
- viraptor 8mo ago
  > the expressive type system of Haskell > Expressive type system ARE direct and simple. Those result in a conflict because given expressive types, people will make them not simple. For example, you realise why Haskell continuously gets academic papers like "Functor is to Lens as Applicative is to Biplate; Introducing Multiplate"? There's no reason for something like that in Go for example, because it's less expensive and the signatures are trivial. > JS (...) can distill the basic good parts of OOP into very direct and clear idioms? Clear in that one specific project context that you need to know. Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place.
  - prmph 8mo ago
    > There's no reason for something like that in Go for example, because it's less expensive [sic] [1] and the signatures are trivial. Whoah, Are you saying, for example, that generics are not useful? That's quite the claim. In that case, to make things even simpler, let's remove recursion, functions as data, even type systems altogether, because they lead to "complex" code. See where your reasoning leads? Any language feature can be abused. In the same vein, you also say: > Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place. One can create OOP in any most modern Turing-Complete languages, so this is not a strong argument. [1] I believe you meant "expressive" here
    - viraptor 8mo ago
      > Are you saying, for example, that generics are not useful? That's quite the claim. That's why I didn't make that claim. If you just want to invent straw men, I'm out.
      - prmph 8mo ago
        That is your implied claim. If that is not it I'm not sure what your arguments is. You mentioned that Go does not have certain advanced features and thus does not lend itself to tying oneself up in complexities. I'm asking you where you draw the line.

embedding-shape 8mo ago

All of those things have been built before, you're even referencing existing languages that have those "features". Parent seemingly was asking for people to build something completely novel, that doesn't have any FOSS code available that done that thing before. And yes, LLMs/agents can help you do it for sure, I'm currently building the lisp of my dreams in my freetime, and already have compiler, interpreter, UI framework and some other things already done in a way I'm happy with.

prmph 8mo ago
Yeah, the "novel" bit is about integrating all those aspects into one language. And trust me, such a language that captures enough mindshare is absolutely needed. People thought Rust was going to be it, but it got taken over by the idea of it being the next C++. IF LLMs are what you make them out to be, it shouldn't have been long before we saw serious attempts at such languages, but I suspect LLMs are of barely any help here beyond some basic implementation tasks.
- embedding-shape 8mo ago
  > Yeah, the "novel" bit is about integrating all those aspects into one language. But do you think GP, who I initially wrote that comment to, would agree with that? All those features and integrations have examples in the FOSS world already, wouldn't the LLM just use what it learned from that? > but I suspect LLMs are of barely any help here beyond some basic implementation tasks. Disagree, as mentioned I've already managed to get together my own language that works for my purposes, and they did more than just "basic implementation tasks" although of course I've been reviewing and deciding stuff, no vibe coding here.

artpar 8mo ago

I tried that over a month except '- the directness and simplicity of JavaScript' https://github.com/artpar/guage https://github.com/artpar/guage But somehow the language feels so foreign. it can obviously do hello world, but I don't have a real use case PS: the "Pure symbols only" is no longer true, most symbols have been converted to English names and, the "days" you see there in the markdowns are "claude code sessions", not actual days