it sounds like you basically want to use Reason with Core (since Core makes a point of avoiding exceptions, and I don't think they use classes anywhere)
Conversation
(typeclasses, well, there's modular implicits, but I don't know when or if they'll be upstream. it's taking a while, but multicore is also taking a while in spite of being actively worked on, and that's just how OCaml is, I guess...)
3
The issue is that I want a language with great libraries, tooling and a lot of backing behind it like Go, Rust and Kotlin. I usually want a high level language with garbage collection. Rust fits most of what I want for a low-level language, other than supporting unwinding at all.
1
1
actually, what problem do you have with OCaml exceptions? they compile down to a longjmp, so have none of the issues with DWARF unwinding
1
It's the invisible control flow that I dislike. Not a fan of call/cc, exceptions, etc. I do like more structured approaches like coroutines, generators, async/await, etc. I like the *idea* behind Go of a simple language easy to read and understand but I don't think it succeeds.
1
2
It seriously lacks important tools to make code composable and reusable. I find it painful to write application code in it, and far more painful to make libraries because I care a lot about making high quality library APIs. It's awful being forced into casting / reflection.
1
Not a fan of how they did interfaces. I don't want the reflection / type assertions / casting at all. It's awful passing something as an interface to an API and not knowing it if only uses it via the interface, or figures out the type internally and maybe casts it. Not a fan.
1
1
It should really have type parameters with interfaces as type bounds and I don't like that they're implicitly defined based on naming. It also means you can't provide an interface in a library and implement it for the primitives and standard library types. So much boilerplate...
1
Not convinced implicit interface implementation much verbosity, and it certainly causes a massive amount of code duplication when you compare it to being able to define a type class in a library and implement it for all the standard types. The stdlib sort is a super sad example.
1
Interfaces as objects are fine but *please* no reflection. If there's going to be reflection, it should be via built-in interface like Any. They kinda have interface inheritance so it really feels almost like type classes but it's just wrong and awful. Also implicit == conflicts.
1
1
I feel like a lot of the design doesn't actually match what they want and are trying to achieve. I seriously doubt that they chose these things as thought out design compromises. Instead, they implemented some stuff that seemed reasonable, iterated on it a bit and then froze it.
I really don't think they seriously considered other options or thought through the design choices in depth. I don't think the Go developers would actually disagree if you presented them with some of these design choices and had them pretend they were going to do it over again.
1
A successful language is going to end up with billions of lines of code written in it. You would hope that it had substantial effort put into designing it and choosing compromises between the available options. The team should have diverse backgrounds / experience. That's not Go.
1
1
Show replies