I want to write a compiler. OCaml for the speed and native or F# for the async and the Unicode?
>>52436240
>implying CLR is good at Unicode and OCaml is not
>implying CLR is slow and OCaml has solved the GIL yet and that both is an issue
>>52436314
Thanks
>>52436240
I'm faced with a similar choice for a project that incorporates a parser. So far I am leaning towards "neither". I don't want to depend on the CLR or to be trapped in OCaml land with no libraries and weird named argument syntax.
I've been thinking of what languages to use for this (static typing, ADTs, pattern matching plus decent libraries being the main requirements) and have come up with the following list:
* Scala
* Rust
* Swift
* Typed Racket
* PureScript
More suggestions are welcome.
There are also Erlang and Elixir, which while untyped are cool in their own way.
You could try Haskell. You get both of both worlds:
- Use Data.Text for perfect unicode support
- Compiles to native code, top-tier optimizing compiler
- Use the new -XStrictData pragma if you need the extra perf
- Lens libraries
- Great parsing libraries (take a look at megaparsec or trifecta)
- Good LLVM bindings
- Stephen Diehl is even writing a "compiler tutorial" in it: http://dev.stephendiehl.com/fun/
- Great multithreading support
>>52437039
Yeah, as far as functional languages go, Haskell is probably the best there is.
It's just that I can't really imagine applications where a functional language makes sense. How could any GUI not have state? You can't just throw away everything and re-create everything every time the user moves the cursor 1 pixel.
>>52437039
I don't want to do it in Haskell because I have way more experience in ML, and I don't want a parser/lexer generator. Also, F# has bindings for LLVM, and Microsoft is working on bringing LLVM to .net in the future.
>>52437298
Also, I wanted to do it in C++ initially, but my greatest fear is that I’ll write the word ”template“ somewhere and my project will sink. (I’m the OP btw)
>>52437039
Haskell has a lot going for it. Unfortunately, with all of its benefits you also get
- Laziness
- Easily breaking dependencies ("Cabal hell")
- No ML-style functors, which would solve the above problem
The last two points are deal-breakers for me. I've heard that the Cabal hell problem is being addressed but I don't how you could completely solve it without replacing typeclasses with a saner abstraction like modules/functors.
>>52437170
>How could any GUI not have state? You can't just throw away everything and re-create everything every time the user moves the cursor 1 pixel.
On modern hardware, you can. But better yet, you could make your GUI behave *as though you do*. That is the selling point of the currently fashionable JavaScript libraries like Vue.js, React.js, etc. You work with them more or less as though you have a purely functional document model and they manage the state of the actual DOM for you.
>>52437437
>On modern hardware, you can. But better yet, you could make your GUI behave *as though you do*. That is the selling point of the currently fashionable JavaScript libraries like Vue.js, React.js, etc. You work with them more or less as though you have a purely functional document model and they manage the state of the actual DOM for you.
Hmm. Actually, I didn't even think about that at all.
If even some single-threaded interpreted non-typed piece of shit language can do it...
And you don't even have to deal with the slowness of the DOM.
But until GUI frameworks in Haskell mature, I will still not consider it.
>>52437475
>until GUI frameworks in Haskell mature
I'd bet on PureScript compiled to WebAssembly to get there first.
>>52436904
> Rust
I use Rust and can say you will spend much of time to understand how it works. Things like borrowing and lifetime will have made you frustrated before you can use them without an effort.
>>52436240
use clojure for the java ecosystem
>>52439521
Do you really need to understand borrowing deeply to write the kind of functional code in it you'd write in OCaml?
>>52439562
Tbh, I can't answer this question. You can use clone/copy on each struct that supports it.
Rust is not a functional language. It has some functional features, but if you want to use a language just because it is "functional", maybe there are any better candidates.
http://science.raphael.poss.name/rust-for-functional-programmers.html
>>52437170
>You can't just throw away everything and re-create everything every time the user moves the cursor 1 pixel.
That's actually exactly how graphics work.
The GPU draws each frame more or less independently from the others. If the GUI is automatically mirrored (i.e. unchanged pixels aren't redrawn) then that's part of either the OS or the GPU itself, not the application.
