Comment by aikah | Hacker News Reader

Comment by aikah | Hacker News Reader

Parent Full thread

> Perfect use case for Go

Go shouldn't have "use cases". One should be able to do almost everything with ease with a language built in 2008/9.

And unfortunatly that is not the case. Go has excellent concurrency features, but is limited by dumb language design decisions which make it painfull to test and to write good reusable and composable libraries for.

I'd love to replace my entire stack with Go but I can't. Something I would write in Ruby in 10 days takes 2 months in Go. And worse, I cant write the code the exact way I want which does piss me off. Give me some choice, not random constraints. Aside from concurrency , I shouldn't have to ask myself how I write something in a specific language. This is the goal of refactoring, and it comes later.

I will personnally invest in Crystal and dump Go as soon as it runs on Windows. It has channels, and that's all I need.

> Something I would write in Ruby in 10 days takes 2 months in Go.

Have you looked into Elixir? It has Ruby like syntax, but uses an actor model for concurrency(it runs off of the Erlang VM). For handling concurrent tasks it tends to benchmark around Go's speed, but is much nicer to do things in. While it is admittedly immature, the ecosystem still has a decent amount of packages and the tooling isn't bad.

Being a Ruby to Go to Elixir convert myself, I can only second this. Elixir is a really great language.

> Go shouldn't have "use cases". One should be able to do almost everything with ease with a language built in 2008/9.

Assuming that Go is a general-purpose high-level language, yes, but is it? It was created to replace C++ in critical infrastructure, not Python/Ruby as the end-all be-all of default platforms for every situation. Its syntax simplicity and speed absolutely makes it attractive to a wider audience, sure, but if it does the job it was designed to do very well, should we be angry that it doesn't do all jobs well?

Developer time and execution time are both important metrics when considering a language, and Go is very well situated when the major developer time gains offset the minor execution time losses vs C/C++. That it's less well situated when the developer time losses vs Python/Ruby are incurred on a project when the execution time gains are irrelevant isn't a failing of the language, it's a trade-off.

Reply on news.ycombinator.com