7 ms·

Wish there was something similar to Elm, but designed with backend/networking/generality in mind, like Go. Take the Haskell core language without all the lang e

by bauerd 7y ago

Wish there was something similar to Elm, but designed with backend/networking/generality in mind, like Go. Take the Haskell core language without all the lang extensions, and accompany it with a solid stdlib. I want an FP ecosystem that's not rooted in research. Can have a more simplistic type system, etc. Basically a functional Go. Maybe an effect system, idk.

thrower123 7y ago
I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world. The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.
- Multicomp 7y ago
  Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile! 2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure. Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why? Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth. Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash. On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs). For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.
- thelazydogsback 7y ago
  F# is my most productive language - it's hard to be beat strong typing w/type-inference, modeling with DU's, pattern matching, indent syntax (by default, unless you don't want it), and the .Net(core) lib/runtime. It's especially nice now that VSCode/VStud have plug-in's that show the inferred type signatures. The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.
- reikonomusha 7y ago
  I would say it’s more “familiar”, not that it’s more “pragmatic”. Haskell is an entirely pragmatic language and is useful for solving very wide ranges of tasks. It’s just not very familiar to most people, in part because it doesn’t plug into a familiar ecosystem, like CLR/Java languages do.
- tylorr 7y ago
  The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.
thraxil 7y ago
Elixir is pretty great if you're not super hung up on type systems.
- bauerd 7y ago
  I should have added that I'd also prefer mandatory typing and natively compiled code. Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like
  - hinkley 7y ago
    There's at least one other way to read that comment. Is there an 'Elixir' of Haskell? Maybe someone should write it. What would it look like if you stole the good bits from a framework/library/standard lib in another language and wrote them in Haskell?
    - ramchip 7y ago
      There is an attempt at it, yes: https://wiki.haskell.org/Cloud_Haskell https://wiki.haskell.org/Cloud_Haskell Many languages have some variation of Erlang’s processes and/or distribution available as a library, but the key features like live inspection, code reload, or strong isolation between lightweight processes can’t really be done without language runtime support.
    - verttii 7y ago
      There's also some work pushing Haskell to perform better (more like Elixir) in networking/concurrency applications: http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/
unique_username 7y ago
You are basically describing ocaml
rashkov 7y ago
Have a look at OCaml, and also at its new spinoff, ReasonML. I think it may be what you’re looking for - compile-to-native systems language, great type system with 20 years of development behind it, and functional without being dogmatic and pure about it by easily allowing imperative mutable code as well.
- zozbot234 7y ago
  ReasonML is more like 'Ocaml with a different syntax' than an actual spinoff.
nicoburns 7y ago
Rust gets pretty close to this.
- zozbot234 7y ago
  Rust is for GC-free code, and it shows in how it deals with closures, higher-order functions, etc. Very different from Haskell or even something like F#/Ocaml/Kotlin and the like.
verttii 7y ago
I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do. Btw you may want to keep an eye on this: https://wende.github.io/elchemy/ https://wende.github.io/elchemy/ Honestly, I wish this would get more traction, it seems like an awesome intersection between type safety and practicality.
- bauerd 7y ago
  You cannot pitch Haskell to the average industry team. It's not so much about technical merit for me
tobyhinloopen 7y ago
Elixir?
np_tedious 7y ago
It sounds a lot like you're asking for the "junior haskell" (no higher kinded types, few language extensions, etc) that this article proposes and stack's toolchain. Am I missing something?

by bauerd 7y ago

thrower123 7y ago

I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world. The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.

Multicomp 7y ago
Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile! 2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure. Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why? Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth. Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash. On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs). For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.
thelazydogsback 7y ago
F# is my most productive language - it's hard to be beat strong typing w/type-inference, modeling with DU's, pattern matching, indent syntax (by default, unless you don't want it), and the .Net(core) lib/runtime. It's especially nice now that VSCode/VStud have plug-in's that show the inferred type signatures. The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.
reikonomusha 7y ago
I would say it’s more “familiar”, not that it’s more “pragmatic”. Haskell is an entirely pragmatic language and is useful for solving very wide ranges of tasks. It’s just not very familiar to most people, in part because it doesn’t plug into a familiar ecosystem, like CLR/Java languages do.
tylorr 7y ago
The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.

thraxil 7y ago

Elixir is pretty great if you're not super hung up on type systems.

bauerd 7y ago
I should have added that I'd also prefer mandatory typing and natively compiled code. Elixir/Erlang/BEAM has a lot going for it but it's not as general purpose as I'd like
- hinkley 7y ago
  There's at least one other way to read that comment. Is there an 'Elixir' of Haskell? Maybe someone should write it. What would it look like if you stole the good bits from a framework/library/standard lib in another language and wrote them in Haskell?
  - ramchip 7y ago
    There is an attempt at it, yes: https://wiki.haskell.org/Cloud_Haskell https://wiki.haskell.org/Cloud_Haskell Many languages have some variation of Erlang’s processes and/or distribution available as a library, but the key features like live inspection, code reload, or strong isolation between lightweight processes can’t really be done without language runtime support.
  - verttii 7y ago
    There's also some work pushing Haskell to perform better (more like Elixir) in networking/concurrency applications: http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ http://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/

unique_username 7y ago

You are basically describing ocaml

rashkov 7y ago

Have a look at OCaml, and also at its new spinoff, ReasonML. I think it may be what you’re looking for - compile-to-native systems language, great type system with 20 years of development behind it, and functional without being dogmatic and pure about it by easily allowing imperative mutable code as well.

zozbot234 7y ago
ReasonML is more like 'Ocaml with a different syntax' than an actual spinoff.

nicoburns 7y ago

Rust gets pretty close to this.

zozbot234 7y ago
Rust is for GC-free code, and it shows in how it deals with closures, higher-order functions, etc. Very different from Haskell or even something like F#/Ocaml/Kotlin and the like.

verttii 7y ago

I used to have the same wish as you but then I just decided to pick up Haskell. Haskell's hard part really is the type system. It's also what ultimately enables you to write very high abstraction level type safe code that does exactly what it's expected to do. Btw you may want to keep an eye on this: https://wende.github.io/elchemy/ https://wende.github.io/elchemy/ Honestly, I wish this would get more traction, it seems like an awesome intersection between type safety and practicality.

bauerd 7y ago
You cannot pitch Haskell to the average industry team. It's not so much about technical merit for me

tobyhinloopen 7y ago

Elixir?

np_tedious 7y ago

It sounds a lot like you're asking for the "junior haskell" (no higher kinded types, few language extensions, etc) that this article proposes and stack's toolchain. Am I missing something?