Why are you not coding your entire backend in Go yet, Jow Forums?

.Net-Core is actually faster.

In bench marks its more half and half but go smashes it by using far less memory.

I still have a couple of IQ points left.

I'm doing this for a project currently
All Golang, all the time
Mixed feelings about it
It has a fantastic standard library and reasonably good build system
However the core language is too restrictive and bashing everything into interface{} is an weak fix for shortcomings

I regularly think back to Hickey's talk "The Language Of The System"

this
go uses 1MB of memory where .NET or Java need 1GB

Because rewriting it would take a billion years.
We are moving subservices to a golang infrastructure though because it's so much easier to deal with async concurrency.

>bashing everything into interface{}
If you're doing this you're literally using the language wrong. That should be an absolute last-resort for an unsolvable compile-time algorithm, you should only use blind interfaces where you would use reflection, which is basically never.

>If you're doing this you're literally using the language wrong.
>but standard library is riddled with it
oh sure ok

The standard library is riddled with reflection-time issues because rob pike is a nigger and didn't want to implement true genericism off the bat, but needed compile-time map genericism.
It's like how the GNU Coreutils are chock full of nonsensical gibberish you'd never want to write, it doesn't reflect how you should actually use the language.

Learn to use the interface system properly and you should never have to use raw interfaces.

>The standard library is riddled with reflection-time issues because rob pike is a nigger and didn't want to implement true genericism off the bat, but needed compile-time map genericism.
okay how does this change anything
the rest of go doesn't have "true genericism" whatever the fuck that means either

It means you're a fucking idiot with no critical thinking skills, apparently.

Attached: 1233873708492.jpg (334x376, 13K)

no seriously how is the rest of the language any more generic than the standard library

what do we have that they don't

I've un-interface{}'d parts of my codebase but as the other poster has noted, a significant part of the stdlib is interface{} nonsense too.

It's impressive what they've achieved with the runtime.

You also have a severe reading comprehension problem.

see
There's a fuckload of stdlib features that need runtime reflection. The intent is not to base the language use around that, but if you absolutely positively need it, you can do it.
In general it shouldn't occur, and 99.999% of the stdlib reflects that.

You seem like a strong Goletarian
What's your take on Go 2 and that "try" inbuilt function they're considering?

I don’t understand, what problem does putting everything into an interface solve?

i already found my language

Attached: 2019-06-28_12-06-27.png (558x528, 51K)

>you should only use blind interfaces where you would use reflection
or if you need sum types, or need to read json/yaml, or need to write a stack or heap or tree, or need to implement a database API...
go is a toy language

ahah good old vbscript
pretty crazy how much of it is used for server-side scripting tasks in the windows world still, powershell wasn't really feature stable until server 2012+

It's a shitload better than the trash they suggested on the first Go 2 draft, but I genuinely don't understand the fuss.
Errors should be handled immediately and directly, and specifically for each case. I could understand introducing some kind of Exception block wrapper, where if the err value is ever set it bounces out, but this is just...why?
What does it solve? I mean this lets you bounce errors back up but ultimately you still have to be manually catching that err somewhere, so it doesn't seem like it does much of anything useful.

Interfaces are Go's main form of polymorphism. You can define a struct and "associate" functions to it, either by copy value or direct pointer, and if you want that struct to be a valid "interface" of a certain type then all you have to do is implement the interfaces declared functions.

interface{} however is the "generic interface", anything that is an interface is encapsulated by this type so you can pass it pretty much anywhere you want. It's the Go equivalent a void pointer and if you're using it, you shouldn't be.

Be honest, how fucking often do you need sum types? Go also has built in type support for json structs and a billion non-blind libraries for parsing it. You don't need it for generic data structures either unless you're fucking retarded, and you DEFINITELY don't need it for a database API.

I swear to fucking god every single time somebody brings this up it's like they've never worked in production, it's always theoretical concept situation X they learned in CS 330.

>built in type support for json structs and a billion non-blind libraries for parsing it
which all use interface{}
>You don't need it for generic data structures either
oh right i forgot, you can use an external tool to do code generation which is very idiomatic to golang and not bad practice at all
>you DEFINITELY don't need it for a database API
unless, you know, that database actually has types

t. fag who though of using golang in production but dropped it after a week because the community has no answers to these

Go competes with python. Go is faster than python.

>UR LYING SEE I SAID UR WRONG SO UR LYING SEE
A) They don't all use interface{} except in maybe very select reflection scenarios, __which is how you're supposed to fucking use it__.
B) It's absolutely no different from an emacs or vim snippet that auto-populates all the requires interface functions in Java or C++ or whatever the fuck, don't be a pedantic shithead.
C) Oh, oh what's that? You can define types in Golang? You can, you know, not have to write a T template and then re-specify fucking everything anyways because the database language will want it concrete?

Seriously are you retarded? What are these complaints? In what universe are you sending completely generic requests to a SQL server with absolutely no compile time knowledge of what they might be? Wherever you work needs to rethink their hiring practices because what you're describing is utter nonsense.

because if I wanted verbosity I would code in Java

they do all use interface{} because json types are all sum types, there is no other way to implement this because it's what the data format is
i don't use "snippets" because careless copy+paste is bad engineering
yes the API user can define a type, the API implementer still needs to access the type which means guess what, reflection and interfaces{}
the problem actually extends to any typed network serialization which is a shame because goroutines are cool but the niceties of them become useless until you go out of process and have to deal with interface{} hell

i don't care if you like or golang or have to use it at work, just stop making excuses for its shitty problems, you are worse than the rustlets

>still no arguments
dumb gotard doesn't want to engage, just proselytise

>they do all use interface{} because json types are all sum types, there is no other way to implement this because it's what the data format is
Literally false. I've written multiple applications with significant json parsing and I've never once had to feed a raw interface anywhere, because _go has inbuilt type parsing for json_. You just define it as part of the goddamn type. You've clearly never used the language.

>i don't use "snippets" because careless copy+paste is bad engineering
Nobody said anything about copy and pasting, you absolute mongloid.
>the API implementer still needs to access the type which means guess what, reflection and interfaces{}
It absolutely does not, what the fuck are you on about?

Everything you're saying doesn't require any of the genericism or reflection you're insisting it does. Go has generics problems for certain but absolutely none of these things require it in even the slightest, you're just a fucking retard.

I've presented plenty of arguments and refutations, suck my asshole.

Is C# the better alternative?

>they do all use interface{} because json types are all sum types, there is no other way to implement this because it's what the data format is
have you ever parsed JSON in Go?

C# is fine I guess. Not perfect, getting kinda hacky, but overall manageable.

C# seems pretty comfy if you're writing for windows. It's never going to get anywhere near backend shit like go though.

>C#
>Getting kinda hacky
Astounding how people just share their complete ignorance with such authority.

Attached: 1269233072760.jpg (928x834, 201K)

look at all the shit they added in C#8 and tell me it's not getting bloated

I mean...fair
tuple switching is pretty nice though, basically let's us have pattern matching

yes and if your type doesn't fit neatly into go's type system then you need to fall back to reflection and interface{}
>Nobody said anything about copy and pasting
that's literally what a snippet is
>It absolutely does not, what the fuck are you on about?
ok so then you shouldn't pass it the type then and just pass the interface{} on to the user?
>none of these things require it in even the slightest
then they should remove it everywhere it's used in the stdlib (hint: they will never do this)

yep, it requires interface{}

>yes and if your type doesn't fit neatly into go's type system
...like what?
>that's literally what a snippet is
Oh okay so everybody using IntelliJ that automatically populates all the necessary function signatures and bodies for you when you implement an interface is just copy pasting. Bad engineering is saving boilerplate, gotcha, you big fucking idiot.
>then they should remove it everywhere it's used in the stdlib
Except it IS needed in the stdlib where they use it.
99.9999% of the stdlib doesn't use blind interfaces, it's all done properly through well defined typed interfaces and systems. It's like a void pointer, you should only ever use it when ABSOLUTELY necessary.

>yep, it requires interface{}
No, it doesn't, you've never dealt with JSON in golang.

>yep, it requires interface{}
I think you’re mixing up structs and interfaces

good luck

>...like what?
i already said, sum types
>Oh okay so everybody using IntelliJ that automatically populates all the necessary function signatures and bodies for you when you implement an interface is just copy pasting.
yes, your argument is literally that because java (designed in 1995) is a terrible language it's also okay for golang (designed in 2009) to be terrible
>you've never dealt with JSON in golang
golang.org/pkg/encoding/json/
ctrl-f interface{} on that page for me and think about how or why anyone would ever use those functions
i'm not going to bother posting other examples in the stdlib because there are plenty but you'll just respond with the same thing either way

>i already said, sum types
And the only example you've given (json) has been refuted multiple times.
>yes, your argument is literally that because java (designed in 1995) is a terrible language it's also okay for golang (designed in 2009) to be terrible
And your argument seems to be that because exists that shouldn't?
You're strawmanning by bringing up YEAH BUT LANGUAGE X HAS FEATURE Y every 2 seconds. C++ has this, Java has that, why doesn't Go have everything?

>ctrl-f it
Try reading the codebase. It's passing shit around as a blank interface because it can reflect and re-encode it later.

i have never said anything about C or java, i actually shill for haskell, ocaml
and elixir
>the only example you've given (json) has been refuted multiple times
he says and then he contradicts himself by saying
>it's passing shit around as a blank interface because blah blah
stopped reading there, remember how i said you need to stop making excuses?

>I don't wanna read anything! Wah!

loving Golang is a blatant sign of mediocrity as a dev

i'm not reading your shit, the point is that any use of them is an excuse, i don't write C because even though void pointers are useful they're still a fucking mess and a joke compared to having a real type system, golang continues this trend of broken language design by requiring the use of interface{}

>I'm not reading your shit
>I don't want to think, spoon feed me every single answer and if I whine and bitch about something that you already answered then spoon feed it some more
>wah wah wah I'm a big baby
You'll stop being mocked when you respond to evidence and arguments like an adult and not some crying pissbaby.

>evidence and arguments
you have posted none of these and i don't want to hear them anyway because you're arguing from an entirely false premise
>calling me names and implying i want to be "spoon fed"
real mature there bud

You obviously dont understand. The only way you can use the JSON library and not muck around with a thin layer over interface{} is if you give the parser a structure. If your data is structureless, get fucked. I had to deal with that shit for one project and it was horrible. It was a good 1000x faster than the shitty PHP script it replaced, but goddamn was it a nightmare to deal with.

the thing you anons are arguing about is it to get around the problem of passing an object/variable of a certain class in a function that other languages have?

Because I'd rather learn how to do awesome stuff in C++, a language with so many use cases, you'd be called a swiss army knife.

my shitty 100 line go scraper uses 20+ mb

sounds like you did it wrong then, i got a tiny scraper that's not bloaty

imagine being this retarded

I'd unironically rather use Node than Go

because i have a large and meaty penis