31–40 of 139 posts
Wait... We must having different definition of perfect. I would say Go is a very good language, and probably be one of the best in terms of simple and practical design, fast execution, fast compilation etc. The perfection, however, is not something Go never meant to be. The perfect language possibly support fully dependent type like Idris while maintains zero abstraction cost like Rust, having precise syntax rule lik…
Go never intended to be perfect, it made no claim to be perfect. When people still write long articles explaining why Go is not perfect, for me, it is pretty strong indication that Go is actually pretty close to be perfect.
I think Go could be fundamentally improved if it somehow offered a REPL.
This already exists, but it isn't trendy. It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust. It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap. Try all…
Earlier quoted context omitted.
I really like F#, but it has a few major pain points that hinder adoption: The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is si…
You are not wrong. In fact I would argue it would be very hard to learn F# without knowing C# even if resources did not assume you did, since one of F#'s major strengths is the ability to use the entire .NET ecosystem just like Clojure as you said, and the .NET ecosystem is written for C# semantics (usable from F# but generally with some slight syntax switching). On the tooling front, Microsoft include it as a prime…
CLR is multiple language runtime and actually the only language that has full control over all possible bytecodes is C++/CLI, not C#.
CoreRT is on its way out, going to be replaced by Crossgen.
They did a talk on AOT compilation at Java Language Summit last week.
For example: Kotlin is a better Java in almost every way.
The problem with almost all such languages is that they aren’t different enough from their “parent” languages, meaning they struggle to gain traction. Both D and Kotlin are here.
Every language has flaws. Some of the best languages are those that take existing languages and just throw out some of the bad legacy mistakes, making what’s often a slightly different but pretty much objectively “better” language. For example: Kotlin is a better Java in almost every way. The problem with almost all such languages is that they aren’t different enough from their “parent” languages, meaning they strugg…
The Android success story might just be what the language needs to establish itself enough that it’ll become a backend staple too
After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the ease of Go (e.g. w/ similar import system).
One such direction seems to be Carp (https://github.com/carp-lang/Carp), but I haven't tried it yet.
Earlier quoted context omitted.
So you're at step 3?
From the article? Not at all. It doesn't matter if it's easy or difficult, because it only needs to be coded once. And it's not a request to change the language at all, just the tooling.
What would a REPL bring to the party?