I followed development of Go from the announcement, and I'm very familiar. I made the mistake of choosing it for some projects and have written a fair bit in it. The language design cripples library design so much too, so despite a lot of great library design, they're not good.
Conversation
Drop multiple return values and have proper tuples. Replace UTF-8 by convention with real UTF-8. Make pointers non-nullable and replace null with sum types (compiler can still use null). Remove switches, and provide pattern matching instead. Remove lots of more hard-wired stuff.
1
1
4
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)
1
1
(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.
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.
1
Show replies