Rust or Go? And why Go?
Rust or Go? And why Go?
- Go has a simple and easy learning curve with the right balance of "languages" features
- Go is a statically compiled language with good performace
- Go has a great standard library
- Go has great tooling
- Go's packaging (whilst some argue against) is actually pretty good
- Go has first-class concurrency
- Go's concurrency model (CSP) lets you model concurrent programs linearly making concurrent programs easier to read
- Go has a focus on readability
- Go compiles insanely fast (if you avoid using CGO)
- Go doesn't support silly things like classes which is fucking great!
- Go supports actual good reuse with interfaces and interface types
- Go supports functional programming (yes it does!)
- Go is awesome!
- Go has a simple and easy learning curve with the right balance of "languages" features
- Go is a statically compiled language with good performace
- Go has a great standard library
- Go has great tooling
- Go's packaging (whilst some argue against) is actually pretty good
- Go has first-class concurrency
- Go's concurrency model (CSP) lets you model concurrent programs linearly making concurrent programs easier to read
- Go has a focus on readability
- Go compiles insanely fast (if you avoid using CGO)
- Go doesn't support silly things like classes which is fucking great!
- Go supports actual good reuse with interfaces and interface types
- Go supports functional programming (yes it does!)
- Go is awesome!
- Go has a simple and easy learning curve with the right balance of "languages" features
- Go is a statically compiled language with good performace
- Go has a great standard library
- Go has great tooling
- Go's packaging (whilst some argue against) is actually pretty good
- Go has first-class concurrency
- Go's concurrency model (CSP) lets you model concurrent programs linearly making concurrent programs easier to read
- Go has a focus on readability
- Go compiles insanely fast (if you avoid using CGO)
- Go doesn't support silly things like classes which is fucking great!
- Go supports actual good reuse with interfaces and interface types
- Go supports functional programming (yes it does!)
- Go is awesome!
Rust was too much for me at this stage, but it's the _hot language_ right now, so I always have the doubt if it's something sensible to learn next year.
- Python is good for AI and small Linux management things
- Java is good for big data pipelines
- Go is good for API, programs, tooling and others things
- Nodejs is good for Web UI.
- Python is good for AI and small Linux management things
- Java is good for big data pipelines
- Go is good for API, programs, tooling and others things
- Nodejs is good for Web UI.
It is like a database you should choose wisely depending of your use case.
- Python is goid for AI and small Linux management things
- Java is good for big data pipelines
- Go is good for API, programs, tooling and others things
- Nodejs is good for Web UI.
C# has a very beautiful reflection library I still prefer go but I may think in C# if I have to deal with a lot of reflection.
1. Microdependencies
2. Feature creep because you can do *x* in 3 lines of code by adding this giant dependency. (Why does gron need HTTP download support?)
Re
gron, to be fair, net/http (including client and server) are part of the Go standard library. I wouldn't complain about that as an unnecessary dependency because it isn't, maybe an unnecessary feature perhaps? 😅
Re
gron, to be fair, net/http (including client and server) are part of the Go standard library. I wouldn't complain about that as an unnecessary dependency because it isn't, maybe an unnecessary feature perhaps? 😅
Gron has no such option. Apparently there is no reason why you *wouldn't* want a text processing program to make network requests.
returns *everywhere*. Period. Random strong opinion of the day. :-)
Whatever documentation issues there were in the early days have long since been addressed, in my opinion. Martin Odersky, the original creator of the language, is in academia and regularly publishes academic articles on scala and its theoretical underpinnings along with his students. So, if you're into that sort of thing, there's lots of theory to read. Since it's typically a top-20 or top-30 language in various language surveys, there's a lot of StackOverflow activity about it, meaning more nuts-and-bolts practical stuff. The major libraries and frameworks nowadays tend to be very well documented (I've never used play and cannot speak to that one).
Scala doesn't look anything like java. You could write scala that looks like java if you want, in the same way that you could write C that looks like java if you want. But idiomatic scala is not like java, and generally the OO facilities in scala are not used (in my experience anyway). You can compile scala to Javascript and run it in a browser, or to native machine code--it's a distinct language with the JVM as only one of its compilation targets.
Where I stand is that I refuse to use a language that doesn't have a sound, well-described theoretical foundation anymore. I've been burned too many times learning languages that lack a clear foundation (*cough* python *cough*); I think this inevitably leads to a lot of wasteful hacking and confusion. I also very much want functional programming constructs to have first-class language support, without being forced to always use them forever like you would in a language like Haskell. It's also nice to have a big ecosystem of existing code to use if you need it. Scala satisfices on all those criteria, and has a bunch of other nice features besides, so I stick with it. It's definitely not for everyone, but 🤷