22 ms·

> static strong typing Alright, here is it: https://github.com/coalton-lang/coalton/ https://github.com/coalton-lang/coalton/ > small efficient native binarie

> static strong typing Alright, here is it: https://github.com/coalton-lang/coalton/ https://github.com/coalton-lang/coalton/ > small efficient native binaries The numbers are: with SBCL's core-compression, a web app with dozens on dependencies will weight ±30 to 40MB. This includes the compiler, the debugger, etc. Without core compression, we reach ±150MB. > The actor runtime? the actor library: https://github.com/mdbergmann/cl-gserver https://github.com/mdbergmann/cl-gserver > couldn't find a way to make money with it. I suspect many other programmers are in my boat. Alright. Some do, that's life. Yes, some companies go with CL even in 2023 (https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ https://lisp-journey.gitlab.io/blog/lisp-interview-kina/, they released https://github.com/KinaKnowledge/juno-lang https://github.com/KinaKnowledge/juno-lang lately; Feetr (finance): https://twitter.com/feetr_io/status/1587182923911991303 https://twitter.com/feetr_io/status/1587182923911991303) https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ > Give us an HTTP (1.x & 2.0) and WebSockets libraries How so? We have those libraries. HTTP/2: https://github.com/zellerin/http2/ https://github.com/zellerin/http2/ https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl

pdimitar 3y ago
Thanks.
dataangel 3y ago
Coalton doesn't actually work: https://github.com/coalton-lang/coalton/issues/84?s=09 https://github.com/coalton-lang/coalton/issues/84?s=09 This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations
- vindarel 3y ago
  Interesting. Fortunately, they are making clear Coalton didn't reach "v1.0".
- medo-bear 3y ago
  > This is why it's important to always look at the issues on a repo instead of just believing what's in the README this makes it sound like the developers are lying whereas the issue was raised by one of the core developers > fails to detect type errors in some of the most basic situations i dont think this is a basic situation. i wouldnt do mutation at coalton level, instead at lisp level
- reikonomusha 3y ago
  "Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2] Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton developers have to decide what they want to do about it. Haskell chose pervasive functional purity and monads (but still gives you many type-unsafe escape hatches). OCaml chose weak polymorphism. [3] Being a sensitive design choice, Coalton has not committed to a strategy for dealing with this, so as it stands, it is possible to use a combination of impure features to produce a type error. However, this does not block productive development. One can: - Avoid mutation altogether and rely on an otherwise sound type system. Use purely functional data structures built in to the language, or write your own. - Use mutation in monomorphic scenarios where there will not be any issue. - Mutate outside of Coalton (i.e., in Common Lisp). - Be very careful, know that "Here Be Dragons", and carefully use mutation in a polymorphic context, understanding that one runs the risk of a type error. Until Coalton reaches "1.0" and a language design choice is made around mutation and the type system, one of these strategies must be used. And they have been used, successfully, because idiomatic Coalton code isn't typically mutating polymorphic vectors left-and-right anyway. With all that said, I do agree with examining a language or tool for caveats, known bugs, and limitations. I don't know how you'd make engineering trade-offs otherwise. [1] "Using Coalton to Implement a Quantum Compiler" https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/ [2] "A Language-Oriented Approach to Exchange-Only Silicon Dot Qubit Software" https://youtu.be/F8TezGqCvE8 https://youtu.be/F8TezGqCvE8 [3] https://v2.ocaml.org/manual/polymorphism.html https://v2.ocaml.org/manual/polymorphism.html
  - Capricorn2481 3y ago
    Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types. This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.

pdimitar 3y ago

Thanks.

dataangel 3y ago

Coalton doesn't actually work: https://github.com/coalton-lang/coalton/issues/84?s=09 https://github.com/coalton-lang/coalton/issues/84?s=09 This is why it's important to always look at the issues on a repo instead of just believing what's in the README. It fails to detect type errors in some of the most basic situations

vindarel 3y ago
Interesting. Fortunately, they are making clear Coalton didn't reach "v1.0".
medo-bear 3y ago
> This is why it's important to always look at the issues on a repo instead of just believing what's in the README this makes it sound like the developers are lying whereas the issue was raised by one of the core developers > fails to detect type errors in some of the most basic situations i dont think this is a basic situation. i wouldnt do mutation at coalton level, instead at lisp level
reikonomusha 3y ago
"Coalton doesn't actually work" is extremely disingenuous and easily misinterpreted to mean something that is not true. Coalton does work, and has been deployed for use in production on non-trivial, commercial problems. [1,2] Mutation is an issue with any Hindley-Milner system, because mutation is inherently impure and non-functional, violating principles that the Hindley-Milner algorithm relies on. The Coalton developers have to decide what they want to do about it. Haskell chose pervasive functional purity and monads (but still gives you many type-unsafe escape hatches). OCaml chose weak polymorphism. [3] Being a sensitive design choice, Coalton has not committed to a strategy for dealing with this, so as it stands, it is possible to use a combination of impure features to produce a type error. However, this does not block productive development. One can: - Avoid mutation altogether and rely on an otherwise sound type system. Use purely functional data structures built in to the language, or write your own. - Use mutation in monomorphic scenarios where there will not be any issue. - Mutate outside of Coalton (i.e., in Common Lisp). - Be very careful, know that "Here Be Dragons", and carefully use mutation in a polymorphic context, understanding that one runs the risk of a type error. Until Coalton reaches "1.0" and a language design choice is made around mutation and the type system, one of these strategies must be used. And they have been used, successfully, because idiomatic Coalton code isn't typically mutating polymorphic vectors left-and-right anyway. With all that said, I do agree with examining a language or tool for caveats, known bugs, and limitations. I don't know how you'd make engineering trade-offs otherwise. [1] "Using Coalton to Implement a Quantum Compiler" https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/ [2] "A Language-Oriented Approach to Exchange-Only Silicon Dot Qubit Software" https://youtu.be/F8TezGqCvE8 https://youtu.be/F8TezGqCvE8 [3] https://v2.ocaml.org/manual/polymorphism.html https://v2.ocaml.org/manual/polymorphism.html
- Capricorn2481 3y ago
  Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types. This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.