171–180 of 207 posts
Earlier quoted context omitted.
OCaml seems to match a majority of the criteria, though AFAIK no "good IDE" (tooling like merlin is available, but if you're looking for e.g. a refactoring IDE you're probably SOL), the ecosystem is small, and it does have some historical baggage.
OCaml is great, but F# is better for almost every one of his bullet points.
As it stands, I would rather bet on OCaml.
I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…
Wait a second... Go doesn't have generics, only has string-based error handling, and has poor dependency management? This is literally the first time I have heard these complaints. I can't believe no one else has ever complained about this in the comments of every article ever submitted about Go.
A hacker news search for "golang generics" yields over 300 results -- of course, not all of them are complaints, but many are.
Earlier quoted context omitted.
Our team was able to develop/deploy about 20 Microservices in Go in the past year or so which is really awesome. I can say this after having worked with several other languages.
how much of this would you attribute to the stdlib and popular libraries, vs the language itself?
Earlier quoted context omitted.
C# actually already has most of that except for "compilation to a (possibly static) native binary", which is really just a convenience for shipping. It's also not really very cross-platform, it's definitely a "Windows First" language.
I'd recommend continuing to look into .NET Core. It's really quite stable these days and has all of the features you've mentioned, as well as C# having a lengthy history as a language. Knowledge is relatively transferrable amongst JS (especially TypeScript) developers, as well as Java developers. This puts you into an area where finding capable people is easy and cost-conscious (vs. niche languages.) Historical bagga…
I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…
Using interface{} instead of generics is a bad idea, you lose type safety. It's messy, but code generation is your other alternative, sort of like your own templating system. I've used go's built in templating code to generate type safe Go code from things like SQL table schemas. I'd highly recommend that route over naked interface{}
Error handling is string or type based, that's up to you. I declare specific error types for my functions, like FooError or BarError, the caller can then switch on err.(type) and respond appropriately. Alternately, you can define concrete error objects and return those, and make comparisons like "if err == FooError".
I'm with you that dependency management is terrible, vendoring is a poor workaround.
Earlier quoted context omitted.
I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references. Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".
There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion
It's implemented with some bytecode hackery and hence limited to inlined functions [0], which makes it significantly less useful.
Funny how a misguided design decision from the Java 1.5 days (running generic 1.6 code with a 1.5 jre) still haunts us today...
[0] https://kotlinlang.org/docs/reference/inline-functions.html#...
Earlier quoted context omitted.
There are quite a few things in Kotlin which are not possible in Java * Top level declarations * Sealed classes * Coroutines (in Java this is currenty only possible with Bytecode manipulation) * Inlined Functions and Reified Generics * Covariant Collections * Tail Recursion
>Tail Recursion Interesting. I thought the lack of proper tail recursion is a JVM limitation. Hence why Clojure uses loop/recur to handle it by translating it to a loop rather then as an actual tail call. Which means things like mutually recursive functions are not possible in Clojure without blowing the stack. How does Kotlin handle that? Is it internally rewriting to a loop or trampoline, or did they find some way…
Yes. You add a `tailrec` modifier to your function. The compiler then checks if the last op in the function is a call to itself. If it is, it gets replaced with a loop. If not, you get a warning that `tailrec` is ignored.
Earlier quoted context omitted.
I don't follow this logic. Why not use C all the time by default then?
Let's say that C produces 100% of the performance available. How much does Go produce? Maybe 90%? How much does Python, say, produce? 25%? So going from Python to a compiled language produces a huge gain, and going from Go to C produces a little bit more. But why not get all the gain? Well, sure, if performance is the only thing you care about . But it usually isn't. You might also care about networking, or multithre…
That's why saying a compiled performant language should be default is not logic I understand. Default should be whatever you need for your requirements. If you don't need anything special, just go with what you already know well.
I can agree with most of the article, but for some it looks like we have not been using the same language ecosystem at all. Go really feels opinionated around the wrong things, in order to claim "simplicity" as a feature: - No generics just mean you're going to be handing interface{} all the way in your stack, it makes things more complex and less readable for no reason (and less safe) - error handling which is essen…
> The fact that they don't even have the package management quality of python (which I find awful already) is baffling. I don't even know how they could think "yeah, github-importing is a good idea, let's do it". Go is eight years old tomorrow and you still have to rely on third-party tooling to do proper imports that don't burn your house. Python packages are installed via a separate tool so I'm not sure what you're…
Where is a useful question to answer, and nice to have consistent across an ecosystem. But What is also a very important question to answer, and tying What to be mutable and dependent on When is... highly unfortunate.
Earlier quoted context omitted.
Let's say that C produces 100% of the performance available. How much does Go produce? Maybe 90%? How much does Python, say, produce? 25%? So going from Python to a compiled language produces a huge gain, and going from Go to C produces a little bit more. But why not get all the gain? Well, sure, if performance is the only thing you care about . But it usually isn't. You might also care about networking, or multithre…
Yes, that's my point. It is premature optimization, because you do not have a use case for such performance. Instead you might want Python's extensive numerical libraries, or you enjoy its quick prototyping capacities. The same way that you do not always go for C, and sometimes prefer Go, because of non performance related requirements. That's why saying a compiled performant language should be default is not logic I…
And, as I said, "Why not use C all the time by default then?" does not actually follow as the logical endpoint of the argument that your trying to answer, so making that your response really doesn't contribute much to the advancement of the conversation.