8 ms·

This truly means we still lack a programming language with: 1. reasonable support of object oriented programming. 2. reasonable support of functional p

This truly means we still lack a programming language with: 1. reasonable support of object oriented programming. 2. reasonable support of functional programming. 3. solid concurrency features. 4. runs comparable to native code. 5. simple to learn. Even though it is not difficult to create such a language but we see a new language poping out every now and then and none of them try to solve these issues.

adamnemecek 9y ago
Rust, swift and kotlin once they have the llvm backend will fit the bill.
- jonathanyc 9y ago
  Rust is very neat, but it lacks OO features.
  - adamnemecek 9y ago
    That depends on your definition of oo.
  - mintplant 9y ago
    Many would call that a feature in itself.
- AJRF 9y ago
  Swift is awesome but lacks atomicity guarantees and it allows some race conditions even when using gcd. https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...
- davedx 9y ago
  I wouldn't say Rust is simple to learn. The borrow checker alone is quite a steep hill (though the compiler errors are very good). In my limited experience Rust and Swift both suffer from boilerplate/ceremony you have in many other OOP languages (C# too). Static languages for you I guess - there are benefits too...
jonathanyc 9y ago
It seems to me like OCaml has all of those features except for #3 (which admittedly is pretty frustrating to me too). What do you think?
- willtim 9y ago
  Depends on what you mean by concurrency support. OCaml has nice green threads via Lwt.
- jon_smark 9y ago
  OCaml has great support for concurrency (check out Lwt or Async libraries). Do you mean parallelism, perhaps?
bmc7505 9y ago
Kotlin? 1. OOP: https://www.packtpub.com/mapt/book/application_development/9781787126367/3 https://www.packtpub.com/mapt/book/application_development/9... 2. FP: https://blog.plan99.net/kotlin-fp-3bf63a17d64a https://blog.plan99.net/kotlin-fp-3bf63a17d64a 3. Concurrency: https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html 4. Native: https://github.com/JetBrains/kotlin-native https://github.com/JetBrains/kotlin-native 5. Simple: https://try.kotlinlang.org/ https://try.kotlinlang.org/
- davedx 9y ago
  Kotlin looks very nice. But I think there are languages with better concurrency support - Elixir (cheap green threads in the VM) and Scala (actors and futures) come to mind. I think it really depends on your use case too. Kotlin is great for mobile apps and games, where coroutines are fantastic (see also C#/Unity there). For writing scalable web services, you need more control and resilience. There Elixir and Scala are the heavyweights.
- clhodapp 9y ago
  The thing that Scala has and Kotlin completely lacks is the tooling to allow you to avoid runtime reflection. Typeclasses and macros (and especially both together) are way too powerful-yet-principled to give up once you're used to them.
  - hota_mazi 9y ago
    This has existed on the JVM for years: annotation processing. Much less heavyweight than macros and easier to reason about.
    - lmm 9y ago
      Annotation processing is impossible to reason about; it's equivalent to macros but much less visible. Most Scala doesn't need macros (other than those inside shapeless) because Scala has a) higher-kinded-types, for/yield and an existing library for working with context-like types, and b) generic traversal of object graphs via shapeless. Between them those cover virtually all the use cases for annotation processing, macros or anything like that.
pjmlp 9y ago
The language doesn't matter if the eco-system and the actual business reason to adopt it isn't there.
iLemming 9y ago
> even though that's not difficult Turns out to be quite arduous: - You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment - FP means different things for different people - some would argue it has to have well thought type system, but what exactly that means? Is strongly but dynamically typed like in Clojure is okay (with added sugar like Clojure.spec)? Or it has to have static types? Does it have to have then type inference like in Elm? Or definitely it has to have algebraic data types like in Haskell? Or maybe dependent types like in Idris? - Concurrency models vary too, for example: STM in Clojure and Haskell aren't exactly the same. Actor model in Erlang is a beast and sounds awesome on paper, but in real life process coordination may become a headache. Primitives based on CSP model are also known to have their own quirks. Concurrency in any language is never simple and straightforward. - You're asking for an fast FP language - with immutable data structures and lazy/non-strict evaluation it's probably unrealistic to get it to run as fast as native code - And "simple to learn" is also very subjective quality - for some Python is easy, but Clojure is hard. For some Haskell is not that difficult as people describe it. For some it feels like insurmountable mountain. As you can see - it's not that simple. And we probably not gonna get a "perfect" language that suits everyone anytime soon.
- majidazimi 9y ago
  I would argue Scala already has all of them but the last one. However there are shit load of absolutely unnecessary features in the language. As the parent link states, twitter just removed shitty features and there you go: An easy to use Object/Functional language which runs fast and has awesome concurrency features.
  - simon_o 9y ago
    Which ones would you remove?
- catnaroek 9y ago
  > FP means different things for different people It's difficult to agree with a definition of FP that doesn't require expressing as much computation as possible as function evaluation. Functions being mappings from values to values, having a rich set of values (not the same thing as objects!) is a prerequisite.
didibus 9y ago
These all exist, you just don't agree with them being reasonable: Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Those could all count or not depending on your subjective opinion. The truth is, it is difficult to create the perfect language, and any sufficiently complete language will always start to have part of it that suffer in exchange.
- catnaroek 9y ago
  > Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Out of those, only OCaml really provides “reasonable” support for functional programming. The ability to manipulate compound values (say, lists or trees) directly, without using objects having a queryable physical identity, is of course a prerequisite. > it is difficult to create the perfect language, and any sufficiently complete language (...) Maybe the excessive amount of features is the problem in the first place.
  - tome 9y ago
    F# allows you to distinguish values by identity?
    - catnaroek 9y ago
      You can always query the identity of the .NET object that underlies a putative compound value.
  - stewbrew 9y ago
    While OCaml might be the most reasonable in theory, AFAIK opam on Windows still doesn't work. Also its standard library is too minimal for my liking.
    - loup-vaillant 9y ago
      User catnaroek was only talking about support for Functional programming. And they're right: it's hard to reasonably support typed functional programming without sum types. And we're talking about a language dammit, not libraries or package managers. Let's have a good language first, then build the tools around it.
moomin 9y ago
I'd have said the fact that no-one's done it is pretty good evidence it's not as easy as you think. As plenty of people have pointed out, FP means different things to different people. But so does OO. In fact, I'd argue that Scala is about as close as you're going to get to your spec. Not helped by the fact that, as any Scalazzi could tell you, the requirements of 1 and 2 contain contradictory elements and make complexity shoot through the roof. (You can get fewer FP features and less complexity by going for F# instead.) Personally, I like Haskell. It's great for 1 and 3, 4 is pretty acceptable and 2 gets thrown in the bin. 5 could do with some work, though.
m12k 9y ago
What I'm looking for in a language: 1. Solid mix of functional programming and Object oriented programming (though FP is more important - I'd gladly give up inheritance if I get good support for interfaces and traits instead) 2. Static type checking 3. Good support for efficient immutable data structures. 4. Solid concurrency features 5. Easy cross-compilation to and interaction with JS 5a. Cross-compilation to iOS and Android would be nice but it's not a dealbreaker 6. Good tooling (i.e. IDE-support, package manager) 7. A solid standard library 8. An active open source community around it 9. Said open source community should contain a good web MVC framework (or sensibly pluggable modules to the same effect) 10. A REPL 11. Sensible compilation times So far it looks to me like only Scala and Haskell are candidates - and it sounds like Scala really struggles with the compilation times. If Reason/ocaml gained more traction it might become a contender. And if I gave up on static type checking then Clojure would be an option. And if I settled for a sprinkling of functional programming instead of having that be the basis, then Kotlin or maybe C#. Any other suggestions?
- lmm 9y ago
  I think you've covered the main options. At a guess: Maybe F# if you're willing to go with a smaller open-source community. Maybe Rust or Idris if you're willing to deal with something a bit less mature with less tooling. Maybe Swift, Crystal or Nim, though I know less about them and their communities seem smaller.
- Matthias247 9y ago
  Besides the options you mentioned I really think Typescript is a high contender on that list. Even though it's just Javascript with typing it ticks most boxes you mention. Depending on how you value some features (e.g. nr. 5) it might even be the best option.
  - lmm 9y ago
    Its FP support is even more limited than C#'s, no?
    - Matthias247 9y ago
adamkruszewski 9y ago
Common Lisp comes to mind (ducks) ;)
smitherfield 9y ago
Not a trendy language by any means, but C# meets all your criteria. 1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java. 2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period. 3. Invented async/await, by far the most ergonomic concurrency primitive yet created. 4. Fast and easy to tune for performance (stack-allocated value types which can also be passed by reference). 5. If you know Java or C++ you’ll be productive within minutes.
- harveywi 9y ago
  I had used Scala for many years before trying C#, and I have to agree. The only thing that I really missed in C# were higher-kinded types.
  - devdoomari 9y ago
    There's F# and then there's "F* " language that seem to have higher-kinded types (I really mean F* as in 'F-star' language)
  - 16bytes 9y ago
    I think I'd miss pattern matching the most. The first time I saw how pattern matching with regular expressions automatically extracted the matching bits I was sold. I'd also miss block expressions. I keep wanting to write if-expressions (as opposed to if-statements) in every non-scala language I touch. But I agree, c#/.net is a good alternative if you're used to the expressiveness of scala.
    - pjmlp 9y ago
      It is not at the same level as Scala, but C# 7 has pattern matching.
- colefichter 9y ago
  > 3. Invented async/await, by far the most ergonomic concurrency primitive yet created. This feels like a bit of hyperbole. The actor model seems much more intuitive than async/await. Indeed, message passing between actors is how concurrency works in the real world (think about how people interact with each other).
mhh__ 9y ago
dlang.org? :) You can write (compiler enforced) pure functional code, and the standard library is somewhat monadic.

adamnemecek 9y ago

Rust, swift and kotlin once they have the llvm backend will fit the bill.

jonathanyc 9y ago
Rust is very neat, but it lacks OO features.
- adamnemecek 9y ago
  That depends on your definition of oo.
- mintplant 9y ago
  Many would call that a feature in itself.
AJRF 9y ago
Swift is awesome but lacks atomicity guarantees and it allows some race conditions even when using gcd. https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...
davedx 9y ago
I wouldn't say Rust is simple to learn. The borrow checker alone is quite a steep hill (though the compiler errors are very good). In my limited experience Rust and Swift both suffer from boilerplate/ceremony you have in many other OOP languages (C# too). Static languages for you I guess - there are benefits too...

jonathanyc 9y ago

It seems to me like OCaml has all of those features except for #3 (which admittedly is pretty frustrating to me too). What do you think?

willtim 9y ago
Depends on what you mean by concurrency support. OCaml has nice green threads via Lwt.
jon_smark 9y ago
OCaml has great support for concurrency (check out Lwt or Async libraries). Do you mean parallelism, perhaps?

bmc7505 9y ago

Kotlin? 1. OOP: https://www.packtpub.com/mapt/book/application_development/9781787126367/3 https://www.packtpub.com/mapt/book/application_development/9... 2. FP: https://blog.plan99.net/kotlin-fp-3bf63a17d64a https://blog.plan99.net/kotlin-fp-3bf63a17d64a 3. Concurrency: https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html 4. Native: https://github.com/JetBrains/kotlin-native https://github.com/JetBrains/kotlin-native 5. Simple: https://try.kotlinlang.org/ https://try.kotlinlang.org/

davedx 9y ago
Kotlin looks very nice. But I think there are languages with better concurrency support - Elixir (cheap green threads in the VM) and Scala (actors and futures) come to mind. I think it really depends on your use case too. Kotlin is great for mobile apps and games, where coroutines are fantastic (see also C#/Unity there). For writing scalable web services, you need more control and resilience. There Elixir and Scala are the heavyweights.
clhodapp 9y ago
The thing that Scala has and Kotlin completely lacks is the tooling to allow you to avoid runtime reflection. Typeclasses and macros (and especially both together) are way too powerful-yet-principled to give up once you're used to them.
- hota_mazi 9y ago
  This has existed on the JVM for years: annotation processing. Much less heavyweight than macros and easier to reason about.
  - lmm 9y ago
    Annotation processing is impossible to reason about; it's equivalent to macros but much less visible. Most Scala doesn't need macros (other than those inside shapeless) because Scala has a) higher-kinded-types, for/yield and an existing library for working with context-like types, and b) generic traversal of object graphs via shapeless. Between them those cover virtually all the use cases for annotation processing, macros or anything like that.

pjmlp 9y ago

The language doesn't matter if the eco-system and the actual business reason to adopt it isn't there.

iLemming 9y ago

> even though that's not difficult Turns out to be quite arduous: - You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment - FP means different things for different people - some would argue it has to have well thought type system, but what exactly that means? Is strongly but dynamically typed like in Clojure is okay (with added sugar like Clojure.spec)? Or it has to have static types? Does it have to have then type inference like in Elm? Or definitely it has to have algebraic data types like in Haskell? Or maybe dependent types like in Idris? - Concurrency models vary too, for example: STM in Clojure and Haskell aren't exactly the same. Actor model in Erlang is a beast and sounds awesome on paper, but in real life process coordination may become a headache. Primitives based on CSP model are also known to have their own quirks. Concurrency in any language is never simple and straightforward. - You're asking for an fast FP language - with immutable data structures and lazy/non-strict evaluation it's probably unrealistic to get it to run as fast as native code - And "simple to learn" is also very subjective quality - for some Python is easy, but Clojure is hard. For some Haskell is not that difficult as people describe it. For some it feels like insurmountable mountain. As you can see - it's not that simple. And we probably not gonna get a "perfect" language that suits everyone anytime soon.

majidazimi 9y ago
I would argue Scala already has all of them but the last one. However there are shit load of absolutely unnecessary features in the language. As the parent link states, twitter just removed shitty features and there you go: An easy to use Object/Functional language which runs fast and has awesome concurrency features.
- simon_o 9y ago
  Which ones would you remove?
catnaroek 9y ago
> FP means different things for different people It's difficult to agree with a definition of FP that doesn't require expressing as much computation as possible as function evaluation. Functions being mappings from values to values, having a rich set of values (not the same thing as objects!) is a prerequisite.

didibus 9y ago

These all exist, you just don't agree with them being reasonable: Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Those could all count or not depending on your subjective opinion. The truth is, it is difficult to create the perfect language, and any sufficiently complete language will always start to have part of it that suffer in exchange.

catnaroek 9y ago
> Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Out of those, only OCaml really provides “reasonable” support for functional programming. The ability to manipulate compound values (say, lists or trees) directly, without using objects having a queryable physical identity, is of course a prerequisite. > it is difficult to create the perfect language, and any sufficiently complete language (...) Maybe the excessive amount of features is the problem in the first place.
- tome 9y ago
  F# allows you to distinguish values by identity?
  - catnaroek 9y ago
    You can always query the identity of the .NET object that underlies a putative compound value.
- stewbrew 9y ago
  While OCaml might be the most reasonable in theory, AFAIK opam on Windows still doesn't work. Also its standard library is too minimal for my liking.
  - loup-vaillant 9y ago
    User catnaroek was only talking about support for Functional programming. And they're right: it's hard to reasonably support typed functional programming without sum types. And we're talking about a language dammit, not libraries or package managers. Let's have a good language first, then build the tools around it.

moomin 9y ago

I'd have said the fact that no-one's done it is pretty good evidence it's not as easy as you think. As plenty of people have pointed out, FP means different things to different people. But so does OO. In fact, I'd argue that Scala is about as close as you're going to get to your spec. Not helped by the fact that, as any Scalazzi could tell you, the requirements of 1 and 2 contain contradictory elements and make complexity shoot through the roof. (You can get fewer FP features and less complexity by going for F# instead.) Personally, I like Haskell. It's great for 1 and 3, 4 is pretty acceptable and 2 gets thrown in the bin. 5 could do with some work, though.

m12k 9y ago

What I'm looking for in a language: 1. Solid mix of functional programming and Object oriented programming (though FP is more important - I'd gladly give up inheritance if I get good support for interfaces and traits instead) 2. Static type checking 3. Good support for efficient immutable data structures. 4. Solid concurrency features 5. Easy cross-compilation to and interaction with JS 5a. Cross-compilation to iOS and Android would be nice but it's not a dealbreaker 6. Good tooling (i.e. IDE-support, package manager) 7. A solid standard library 8. An active open source community around it 9. Said open source community should contain a good web MVC framework (or sensibly pluggable modules to the same effect) 10. A REPL 11. Sensible compilation times So far it looks to me like only Scala and Haskell are candidates - and it sounds like Scala really struggles with the compilation times. If Reason/ocaml gained more traction it might become a contender. And if I gave up on static type checking then Clojure would be an option. And if I settled for a sprinkling of functional programming instead of having that be the basis, then Kotlin or maybe C#. Any other suggestions?

lmm 9y ago
I think you've covered the main options. At a guess: Maybe F# if you're willing to go with a smaller open-source community. Maybe Rust or Idris if you're willing to deal with something a bit less mature with less tooling. Maybe Swift, Crystal or Nim, though I know less about them and their communities seem smaller.
Matthias247 9y ago
Besides the options you mentioned I really think Typescript is a high contender on that list. Even though it's just Javascript with typing it ticks most boxes you mention. Depending on how you value some features (e.g. nr. 5) it might even be the best option.
- lmm 9y ago
  Its FP support is even more limited than C#'s, no?
  - Matthias247 9y ago

adamkruszewski 9y ago

Common Lisp comes to mind (ducks) ;)

smitherfield 9y ago

Not a trendy language by any means, but C# meets all your criteria. 1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java. 2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period. 3. Invented async/await, by far the most ergonomic concurrency primitive yet created. 4. Fast and easy to tune for performance (stack-allocated value types which can also be passed by reference). 5. If you know Java or C++ you’ll be productive within minutes.

harveywi 9y ago
I had used Scala for many years before trying C#, and I have to agree. The only thing that I really missed in C# were higher-kinded types.
- devdoomari 9y ago
  There's F# and then there's "F* " language that seem to have higher-kinded types (I really mean F* as in 'F-star' language)
- 16bytes 9y ago
  I think I'd miss pattern matching the most. The first time I saw how pattern matching with regular expressions automatically extracted the matching bits I was sold. I'd also miss block expressions. I keep wanting to write if-expressions (as opposed to if-statements) in every non-scala language I touch. But I agree, c#/.net is a good alternative if you're used to the expressiveness of scala.
  - pjmlp 9y ago
    It is not at the same level as Scala, but C# 7 has pattern matching.
colefichter 9y ago
> 3. Invented async/await, by far the most ergonomic concurrency primitive yet created. This feels like a bit of hyperbole. The actor model seems much more intuitive than async/await. Indeed, message passing between actors is how concurrency works in the real world (think about how people interact with each other).

mhh__ 9y ago

dlang.org? :) You can write (compiler enforced) pure functional code, and the standard library is somewhat monadic.