>>109104495
No use case.

>>109104495
the next ruby, do you like rewriting your codebase for no reasons?

>>109104495
Stay safe, Golang heights is in a war-torn region

>>109104495
C and Go is all you need. transgenders and brown people needn't reply.

>>109104567
wow you’re so funny anon, tell us another joke!

>>109104495
GC makes it pointless, and slow compared to other compiled languages. ALSO the foreign function thingy is also slow for some reason, idk why. So using C libraries is a problem. It tries to be a better C, but it is a better C from a 80s mindset. GC is not that big of a problem, because we got 8 to 64 GB of ram and debug functionality.

>>109104650
GC is unnoticeable these days (since Green Tea). you haven't used it for years (or ever) obviously.

>>109104593
TRVKE

it's a great choice if you prefer your ecosystem to prefer piling on quick hacks that are easy for the implementer but terrible for the user

I find it really good for projects that are simple or simple and clever. Usually I use it for things that require a bit more power than Bash, Powershell, or other scripting languages.

>>109104802
Nah, I havent used it ever, I just eyeballed it and wondered if it was worth learning.

>>109104650
There's nothing wrong with GC.

>>109104593
i'm brown and i use go. honkaloids need not apply.

>>109104495
Lack of type safety.
In 2026, it's unacceptable for a language not to have ADTs.

>>109104860
it has types, retard.

>>109104865
It's about as type safe as C. Compared to languages with modern type systems, it's complete crap.

>>109104495
Don’t use it to make command-line utilities… each binary is 5mb.

Also doesn’t make DLLs or .so very well.
…generally makes monolithic big-ass binaries with no dependencies other than syscalls.

>>109104873
you couldn't sound more dunning-kruger. the type safety in go is probably better than whatever language you're thinking of. unless you're some haskell spazzy.

>Hmm what use case does Go have that Elixir doesn't
...

>>109104904
NTA but the fact that you don't know what ADT is makes me think you are the dunning-kruger.

I discovered that the most satisfying thing is to make stuff work and then it rarely matters which language it is, But of course in order to make stuff work, you must pick the right language for it.

So I'm writing a text editor in D. One thing I noticed is that I I very often wouldn't know ahead which abstractions would be then most useful / would make most sense for a give feature. I could've written it in Go, but D simply offers a lot of room for maneuver and that's valuable, because I want to keep code very understandable and maintanble. I'm not saying Go is not maintainable, but its lack of abstractions makes me more limited in coming up with my own abstractions and that in turn could've made my code a lot more convoluted.

>>109104495
Why would I use any other GC lang when D absolutely BTFOs each and every one in terms of features, familiarity, standard library, build system, compilers

>>109105630
/g/ will tell you D is not popular and therefore not a real language. Trannies and indians must use it or else no way it's real.

>>109104900
>monolithic big-ass binaries
bad

>with no dependencies
good

bad + good = mediocre, hehehe

>>109104853
>There's nothing wrong with GC.

in a fully-fledged runtime. but golang is compiled and that feature is not optional, right? c++ way of quasi-runtime is better, because features are opt-in.

>>109104593

freeman language cannot really intertwine with corporate language. you guys should think what youre signing up to, because maybe sometime later you would "revolt" like Snowden and be proclaimed traitors, whom you would be. so think before that happens

File: why-does-g-man-look-so-hu(...).png (171 KB, 582x397)

171 KB PNG

>>109105689
>freeman language

>>109104495
Why torture yourself when java already exist?

>>109105715
I'm trying to imagine a person who says "why torture yourself" and suggests java as an option...

>>109104510
microservices/apis, clis, devops/sre tools

>>109105954
kek

>>109104495
Excessive nil checking and silly error handling. Like even java has some measures that you don't dereference null references constantly

File: Macron-Benalla.jpg (62 KB, 932x582)

62 KB JPG

>>109104542
>do you like rewriting your codebase for no reasons
"Go" is rock solid and does not break backwards compatibility, Bubba.
You need to stop larping now.

File: Prince of Wales - Sir Eve(...).jpg (988 KB, 3600x2579)

988 KB JPG

>>109106835
>Excessive nil checking and silly error handling.
Worth the trouble, unlike Rust's borrow checker.

>>109104873
>It's about as type safe as C.
this has to be bait. that is patently false. Go dramatically improves the typesystem over C.

>>109104495
if you have to ask, you are in the target audience, and you could do much worse.

>>109104495
because you're a retarded nocoder. people who actually do shit, don't make pointless threads like these.

>>109105954
literally the comfiest language and ecosystem

>>109109325
nah
Really depends on what you're doing. If you're doing something inherently monstrous and bloated, go may be a poor fit. Go's explicitness and emphasis on a simple, uncluttered build process is better for targeted straightforward problems where you don't need to pull in a metric assload of dependencies.

For a CLI/client tool there is just no comparison at all. With Java your options are either the JVM and its terrible startup time, or deal with all the BS required to make your code work with GraalVM.

>>109107665
Oh? How do you annotate the kinds of messages you can send over a channel?
Trivial in Rust, just use a generic over an enum of possible messages.

In Go, you fall back to using an interface and you have no idea what kinds of types implement it at runtime. The compiler won't help you.
How is that different from void*?

>>109104858
>honkaloids
My favorite 80s action figure line

>>109104542
>the next ruby
Ruby is far more flexible than piece-of-shit-google-language

>>109104650
>GC makes it pointless, and slow compared to other compiled languages
Bullshit. GC doesn't make anything slow. Go runs fast. The problem is that the language itself sucks big time.

>>109104495
>making a simple daemon that talks on nats or rest
Go
>anything else
Maybe not.

>>109105689
>corporate language

Node.js vs. io.js (2014)The Cause: Massive frustration within the JavaScript community regarding the stewardship of Joyent, the corporate sponsor of Node.js at the time. Joyent was slow to merge community contributions, dragged its feet on governance reform, and delayed updates to the underlying Google V8 engine. The Schism: Core contributors broke away, duplicated the repository, and launched io.js as an open-governance alternative. Development on io.js moved incredibly fast, implementing modern ECMAScript features long before Node.js did. The Resolution: Realizing the split was destroying the ecosystem, Joyent and the io.js steering committee negotiated a truce. They created a neutral, independent foundation (the Node.js Foundation) and merged the codebases back together into Node.js v4.0 in 2015.

--
ask about other examples of "hard forks" - golang doesnt have any, i interpret it as a lack of developer interest and complete control. Joyent was probably right back then, what it calls a "community", probably a bunch of opposing corporate force midwits who brought JS into the current state.

>>109111023
>For a CLI/client tool there is just no comparison at all. With Java your options are either the JVM and its terrible startup time, or deal with all the BS required to make your code work with GraalVM.
yeah, i really hope the aot work with project leyden will lead to some easy static cross compilation. but nobody wants 40mb+ cli apps, wel'll see

>>109104567
kek
>>109104594
I chuckled, though

>>109104495
I don't get the point of it when Rust exists but it's good to have options I suppose

go wont land me or you a chinese wife, nor a better gooning experience

>>109104825
sounds perfect

>>109104495
The people who dislike go are just python shitters, who see it as a massive threat.
>>109113308
>"hard forks" - golang doesnt have any
Microsoft has one for FIPS 140 compliance.

>>109113084
the argument was not whether or not the type system was better than rust, the argument was that the type system was better than C's.

>>109116156
(nta + didn't read thread)
both C and go don't really have a designed type system.
in the case of C, it's because it was just "portable" language glued together by engineers who wouldn't know anything about a "type systems".
in the case of go, the whole language wasn't designed. the go team itself (including Rob Pike and the semi-retired C boomer) sat down in what was probably the first conference and flat out said that they deliberately fast-cooked most of the language in a couple of weeks.
why? because they were creating the language for retards to use. and they fell into the very basic fallacy:
simple design = simple language for end users
so it was yet another case of "being good technically doesn't necessarily reflect you being good at abstract coherent logical thinking".

>>109114416
>Microsoft has one

not hard enough. wat is HUIPS 104? some obscure knowledge, hehehe

>>109109325
jvm based ecosystem is only comfy when you're not using java itself. wish i had more reasons to use clojure.

>>109118870
>the whole language wasn't designed

there is no Go team, it was one time job, now it belongs to a company and you may Go kek yerself.

>they were creating the language for retards to use

we would never know "what for" and why google wanted it, probably it was pitched as a project, same as a holy cow of language features, internal retarts want to eat its meat and drink its milk, so they have to cosplay business.

i listened Ken interview very carefully, he said that the main thing was compilation speed, but immediately a question popped up in my mind - what about rewrite speed? do they have a magic machine (LLM?) that is able to deterministically rewrite all that C/C++ code into Go? unlikely.

File: 1777457841282014.png (58 KB, 800x789)

58 KB PNG

>>109106144
>microservices/apis, clis, devops/sre tools

>>109119265
ugh stfu, cringelord.

Frankly, in this LLM era there is little excuse to NOT use more efficient languages than python/ruby/JS.

> Want to manage your own memory?
Rust (yes, despite Russian trannies), zig/odin.
> Don't want to manage your own memory.
Golang, Swift, Ocaml
> Need some specialty goodies for distributed computing?
Elixir or any other BEAM lang.

I don't see use case for Python, Ruby, JS going forward. Intricate language knowledge is LESS important now, and given that compute prices are going UP you'd want to optimize for that.

>>109104593
Lisp is

>>109119754
> I don't see usecase for Python
For scripts, I think it's still the best.

>>109104495
it just feels really half-assed. Like, if you don't give a single fuck about quality and just want something that "works" ya, use it. otherwise stop and think what you're delivering.

File: movie-parts-the-matrix-re(...).jpg (116 KB, 735x735)

116 KB JPG

>>109119754
that is what awaits most of those quasi-runtimes, zig is opt-in afaik, as c++

>>109114416
python people tend to like go
it's java devs who feel threatened by go.

>>109119754
> Intricate language knowledge
this is so true. On multiple occasions I would just ask Chatgpt "hey, I want to do this thing I'm used to doing in, say Ruby, how do I do it in Go or D or how do I at least approximate" and it would just give me some idiom and examples or explain why it's not possible.

To be fair, I very much doubt that intricate language knowledge was very really important. It doesn't really help anybody if your code is too clever and the real value is how your code is organized.