Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. Go's niche includes being native. If you discard that, then virtually anything that is "easy" could fit it.
> Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. They would at least know how to make a language that's not a pain in the ass to analyse, which is probably in its favour.
Yea - but that's offered by all modern languages, and they're not tied to one particular IDE since LSP took off.
Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. Go's niche includes being native. If you discard that, then virtually anything that is "easy" could fit it.
Then use an AOT compiler, plenty of those for JVM since 2000. While one can excuse themselves that they were commercial, GraalVM native image, and OpenJ9 offer free beer alternatives.
You're totally missing the point of the niche in question.
> Kotlin might fit the Java niche, if you trust someone that sells IDEs to make a language. They would at least know how to make a language that's not a pain in the ass to analyse, which is probably in its favour.
Yea - but that's offered by all modern languages, and they're not tied to one particular IDE since LSP took off.
> that's offered by all modern languages
I see you've yet to meet Scala.
> they're not tied to one particular IDE since LSP took off.
There's at least one language server for Kotlin.
I'm not even a interested in (let alone a user of) Kotlin, but you seem to have a very not-objective view of it for some reason.
Then use an AOT compiler, plenty of those for JVM since 2000. While one can excuse themselves that they were commercial, GraalVM native image, and OpenJ9 offer free beer alternatives.
You're totally missing the point of the niche in question.
So they're missing the niche of "being native", by suggesting... using an AOT (= native) JVM compiler? Meaning making essentially every JVM language native?
C# is far from simple. It used to be be but lately (in that last ~5 year) they have been adding a lot to a point it has become hard to follow the changes, and hard to read modern C#. When I was C# developer I welcome the addition of FP like feature, but now imho the lang have become very cluttered. GO lang is in another level of simplicity and it is not comparable with C#.
Just wait when Go gets 20 years of existence and enterprise use beyond devops.
> Just wait when Go gets 20 years of existence and enterprise use beyond devops.
C# is really reliable language, great tooling and documentation but it does not change the fact that is cluttered and no longer simple (which was the point of my comment).
Also I can't see golang going to the same direction, by design go is a lot simpler.
I hate Go, but there is no solid alternative for what I do. Documentation quality. Compiler performance. Library support. Easy packaging. Easy language. Consistent cross platform tooling. Easy concurrency. Good for web apps and CLI tools. Reasonably refactorable. Note I say easy and not good, or simple. Rust, Haskell, JavaScript, all get caught up on some aspect or another for me.
C# may fit your needs, depending on what you consider a simple language and easy concurrency. The language doesn’t feature any hard to understand concepts. Concurrency is very good, but only async has built in syntax sugar (I believe go has syntax sugar for channels or something?). The executables may be a bit larger (I’m guessing).
I had my share of reviewing and working with C#. There are certainly ways where developers can be "clever" with it and it becomes confusing and unworkable mess. Haven't seen that with Go.
I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…
I mean it's a good exercise I guess if you want to flex your language knowledge, but it goes against the mindset of Go to actually use it in production. Said mindset being don't overcomplicate things. One doesn't need Go to not overcomplicate things either. I wanted to advocate in favor of Go for a long time, and still do recommend it, but it's the mindset that is more important.
What I fear most is starting to absorb the "reserved for language designers, not for me" mindset. Stubbornly bending the language to serve you is a much healthier attitude for anyone who wants to maintain his expertise.
What I do not understand is why on every article about Go someone needs to extol their dislike of Go. If you don't understand its appeal, then either you should give it a (serious) try and see if you like it, or if you are unable to bring yourself to do that, just use those better (according to your opinion) languages.
Unfortunely that isn't always a choice that we can influence, project => language, and in some cases that implies using a language that we dislike, regardless of how we feel about it. One can go job hoping as alternative, but then good luck jumping jobs everytime one has to deal with stuff we dislike.
I hopped jobs to go from using Go to Rust, I was sad and bored, now I'm happy and energized. Always going to be things you dislike for sure, but life's to short to be using a language that's making you miserable.
What I do not understand is why on every article about Go someone needs to extol their dislike of Go. If you don't understand its appeal, then either you should give it a (serious) try and see if you like it, or if you are unable to bring yourself to do that, just use those better (according to your opinion) languages.
Unfortunely that isn't always a choice that we can influence, project => language, and in some cases that implies using a language that we dislike, regardless of how we feel about it. One can go job hoping as alternative, but then good luck jumping jobs everytime one has to deal with stuff we dislike.
True, but can you really work day by day in a language and still not understand its appeal? I mean, not like it, but at least understand why others might choose to use it? And, if you really can't bring yourself to see the positive sides of a language you have to use (and any mainstream language has to have positive sides, otherwise it wouldn't be mainstream), maybe it's really time to consider switching jobs...