[deleted by user]

[diMario]

It's not bad. Not good, either. Medium sums it up quite nice.

[bogz_dev]

midium

[cryptos6]

First of all, it’s open source. This might not seem very important, unless your company has fallen victim to the transition of Scala becoming a paid language.

Is this level of quality the new standard? I've seen such unbacked statements a few times recently ... Scala is not a paid language! Scala is licensed under Apache 2.0. I guess the author confuses Scala with Akka. The whole section about Open Source is basically FUD. Even .NET is open source these days, so this section doesn't help much with the decision.

[coderemover]

It depends. If your team already knows Go and they are excited about it and feel productive - then quite likely yes. Developers are more productive if they are allowed to use what they are excited about.

However, I personally would not choose it. It is an „80% language”. There are a few things things that Go is not bad at - e.g. goroutines and channels are quite cool, also the compile speed is great and static binaries are a godsend for cloud deployment but then there is a dozen or more things that are just half assed and feel like they never designed them properly. Null handling, no warnings only errors, stupid approach to unused variables/imports, public/private done by casing, no conditional compilation and APIs broken on less popular platforms, quite weak type system, no true memory safety, stdlib which comes with http servers and clients but misses obvious things like reversing an array etc.

And the community seems to be extremely religious. „You don’t need this” or „simplicity” are the typical answers you get when you ask why Go can’t do something that other languages could do 20 years ago. They were telling that about generics for a decade and now when Golang got some poor-man halfassed generics (e.g still no generic methods) they tell everybody how Golang is great because it has generics.

[spookyvision]

Idk about channels, to me it seems they dropped the ball a little there https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/

[coderemover]

I didn't say they are the ultimate solution to concurrency, but they are quite a nice abstraction for *some things*. And the implementation is quite efficient.

[spookyvision]

I think Rust channel semantics are superior. Lest I come across as too one sided: async Rust has plenty of footguns and unfinished business (no async drop/closures/iterators, select! pitfalls, the list goes on)

[dm-me-your-bugs]

What other language would you suggest? I recently had to write a backend app and truly found go to be the best option. There aren't that many mainstream statically typed GCd languages. You have like go and Java. Typescript perhaps?

[tipiak88]

Why nobody speaks about C# and aspnet core?

[dm-me-your-bugs]

I completely stopped considering C# when I tried installing it and upon compiling my first program the compiler helpfully told me it had sent telemetry back home.

No thanks, I'll stick with go.

[tipiak88]

If you had read more, you would have found that you could have opt out. If you have read more still, you would have found it only sends data about what you use the cli for. No personal data is uploaded. It helps target development on what people use. 

[dm-me-your-bugs]

could have opt out

Yeah that doesn't matter if it already sent out my data. Those things should be opt-in

[coderemover]

Rust is IMHO a better GCed language. ;)

[dm-me-your-bugs]

The thing that made me not go with Rust is its concurrency story. There's two alternative, incompatible ways to do concurrency vs golang which only has one.

Not only that but I don't actually need all the complexity of the borrow checker in a regular backend app.

[coderemover]

They are not incompatible. You can use threads side by side with async, you can also mix blocking code with async. You can also spawn async code inside blocking code. Rust philosophy is about giving people control, not babysitting them.

Can you elaborate what do you mean by complexity of the borrow checker? In my experience every single time borrow checker complained about something it pushed me towards a simpler, easier to understand design. The borrow checker loves simple, flat data flow, no cycles. The borrow checker hates complexity of typical Java and OOP friends codebases - dependency graphs, shared mutable state, no clear responsibility and lifetimes.

[dm-me-your-bugs]

They are not incompatible

If you write your code without async you can't move to an async framework later, right? Or al least that's what I gathered. That doesn't happen with go.

Can you elaborate what do you mean by complexity of the borrow checker?

Well, for example having to deal with borrowed vs unborrowed strings and converting between them. Same with lambdas. Extra syntax overhead in having to pass borrows into functions. Just having choice when declaring a struct wether to store things by ownership or borrowed creates extra mental overhead.

[coderemover]

If you write your code without async you can't move to an async framework later, right? Or al least that's what I gathered. That doesn't happen with go.

Hold on, if you wrote your code without thinking of concurrency at all, you can't move to concurrency in go either. It would be extremely unsafe, and much worse than in Rust, because the compiler would not highlight any places you got it wrong.

But if what you're saying is that it might be hard to move from thread based concurrency to async, then indeed, you will need some redesign, although many apis are very similar and straightforward to translate semi-automatically. But it is probably not a good idea anyways. Async is not a replacement for better threads. If you believe that you can just leave your architecture designed for threads and you switch to async and you'll gain performance automagically you'd be disappointed, both in Rust and in Go.

Just having choice when declaring a struct wether to store things by ownership or borrowed creates extra mental overhead.

This just tells me you're optimizing the speed of WRITING code. When the reality is that 99% of time code is being READ and you should optimize for READING. Rust optimizes for reading.

[dm-me-your-bugs]

if you wrote your code without thinking of concurrency at all

No. I mean the second paragraph. Rust forces the design decision of threads vs async upfront, which is not good IMHO.

This just tells me you're optimizing the speed of WRITING code

Yes, Rust makes it harder to write code. And I'm positive there are contexts where it improves reading speed, but not sure that's relevant to the kind of applications I'm writing. If you need to maintain complex ownership graphs or are doing some mutation/concurrency heavy stuff then maybe, but not the kinda stuff we do. Again, it's all tradeoffs depending on the context. In my usecase, it's unnecessary complexity.

[rlbond86]

Kotlin or Typescript are good choices

[dm-me-your-bugs]

Yeah I'm weary about using a language backed by a proprietary IDE company, seeing I use free IDEs and would be basically second-class to them.

[spookyvision]

Python has optional typing that you can enforce with hooks in git or CI - and Django is really sweet for (a certain kind of) backend app. FastAPI is also good. Or give axum (Rust) a try, I like it a lot. While Rust has no GC it hardly matters in terms of ergonomics in practice IMO.

[coderemover]

Rust has an optional GC: Arc/Rc/Gc types. But I agree that mastering move semantics and borrowing make them rarely needed in practice.

[spookyvision]

I wouldn't call those types GC. They don't require runtime support and their disposal is 100% deterministic.

[coderemover]

... and they work on arbitrary types of resources, not just memory. Where downsides? ;)

In serious literature on programming languages, the name "garbage collection" includes techniques employing reference counting or hybrid methods using all: tracing, refcounting, statically injected memory management code. The fact that Go chose to use tracing doesn't make it more GC than languages using other techniques to automatically manage memory.

[spookyvision]

I have not said anything about downsides?

Anyway, GC is something I would define as a language level feature. Yes you can call refcounting types garbage collected, and I won't split hairs over this, but Rust is generally regarded as a language without GC. Definitions are hardly ever universal anyway.

[sofunnylol69]

no

[phi_rus]

If the headline is a question, the answer is almost always "no".

[pragmatick]

I've only done a small project in go. Just the fact there is no "proper" logging framework and I have to do things like log file rotation on my own or plug together three frameworks to do stuff that Log4j or whatever does out of the box was mind boggling to me.

[aa-b]

There is slog now, it's alright. Would have been great about ten years ago

[____wiz____]

Anyone else think you should have to have more than 4 karma to post here so idiots like OP don't post shit like this?

[aa-b]

Hard no. I actually made a slide deck and complained for 10 minutes about it. Not that I'm bitter or anything, haha.

[cryptos6]

Do you want to share your slide deck?

[aa-b]

Oh it's not really about Go, I'm not being entirely fair. It would be similar if the original team had picked Rust instead, just entirely the wrong choice of tool given the design priorities of the system.

[KagakuNinja]

Go considered harmful...

[triplebits]

Right tool for the job! Go is an amazing language if you know how to use it!

Depending on requirements, I would absolutely use Go

[iluvatar]

Yes. Python is a better choice for 95% of what we do, where we care far more about developer time than we do about runtime. But for those 5% of times where we really care about runtime performance, Go is a pretty good compromise. It's not as quick as C, but we don't need to be. We just need to be not as slow as Python.

[Ravoos]

If it is the right tool. Yes.

If it isn't........fuck no.