[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Home]
Board
Settings Home
/g/ - Technology


Thread archived.
You cannot reply anymore.



File: 1544040876715.png (37 KB, 997x315)
37 KB
37 KB PNG
The absolute state of Go
>>
>>68815163
Non code-monkey here, can you explain this please?
>>
>>68815180
They reinvented the C preprocessor but non-standardized.
>>
>>68815180
No because only us true 4channers will "get" it not /v/ crossboarders such as yourself.
>>
>>68815180
basically just Go fuck yourself™
>>
File: NO.gif (1.33 MB, 245x160)
1.33 MB
1.33 MB GIF
>>68815200
>if you didn't waste the best years of your life learning something that'll be useless in the world of Pajeet labour you must be from /v/
>>
File: images-2.jpg (13 KB, 256x197)
13 KB
13 KB JPG
>>68815234
>hey guys do I fit in on /g/ yet?
>>
File: 1512275715055.gif (1.98 MB, 190x190)
1.98 MB
1.98 MB GIF
>>68815268
Ok anon, that programming degree will pay for itself any day now
>>
>>68815180
In real programming languages if you want something to be able to use multiple data types without writing the same code multiple times, for example if you want a list that can hold not only numbers but also words, you utilize "templates", where compiler will substitute the placeholder type with whatever you put in these <> brackets. This go programmer tried to emulate this by using external tools and using some unicode symbols that look like <>.
>>
File: 1543793406204.gif (3.44 MB, 356x260)
3.44 MB
3.44 MB GIF
>>68815285
>programming degree
Bwahahaha
>>
>>68815200
*4channelers
>>
File: 1541799946838.jpg (14 KB, 247x313)
14 KB
14 KB JPG
>>68815337
/v/ crossboarder detected
>>
>>68815351
>another /pol/fag leaking over and shitposting.
>>
>>68815180
Most programming languages have a feature known as generics, which allows you to write functions or data types that work for a variety of data types rather than only one. Here's an example in Java.
class Pair<T>
{
public T first;
public T second;
}

So now you can have a Pair<Integer> which has two Integers, or a Pair<String> which has two Strings, and so on.

Go doesn't have generics. This user has tried to simulate generics by using the ᐸ and ᐳ characters because they resemble < and >, and just copypastes + finds/replaces to create as many different types as he wants. This is not good programming, because Go is not a good programming language.
>>
>>68815395
Nice explanation.
>>
>>68815163

>custom processor and special unicode characters

10/10 for the why I continue to use Go mental gymnastics performance.
>>
>>68815302
Thanks anon, simple enough for me to understand but not too simple
>>
>>68815395
Thanks
>>
>>68815395
How would you do this in Go elegantly, is this reddit cunt actually pretty smart for doing it his way or is he a dumb cunt?
>>
File: 1519507244728.png (502 KB, 1200x1400)
502 KB
502 KB PNG
>>68815854
>How would you do this in Go elegantly
You can't.
>>
>>68815854
>How would you do this in Go elegantly
You don't
>>
>>68815854
You can't really.
You can write out each data type separately, but that is time-consuming, difficult to amend later. OP does this basically.
In Go you have the type interface{}, which all data types can be converted to. You can use that for generic functions, but all pieces of data need to be explicitly converted back from interface{} to their "real" types for you to get any useful information out of them. This is error-prone and verbose.
The conclusion is - languages without generics really suck.
>>
>>68815234
If it takes you more than an hour to learn Go you should be flipping burgers.
>>
>>68816163
Judging by what people are saying in this thread I don't see the point in wasting an hour of my time on some meme-language
>>
>>68815854
You usually don't need to. Generics are mostly useful for Java(Script) tier codemonkeys that rely on libraries implementing generic algorithms and data structures rather than implementing focused optimized DSAs for each use case, because they didn't pay attention to CS 101
>>
>>68816195
You should only optimize where you have to. Remember the 80/20 rule.
Making bespoke data structures for every task is asinine.
>>
>>68815395
what the hell is a function??
>>
>>68816244
a piece of code
>>
>>68816248
woah, like that gets done on computer?
>>
>>68816235
And this is why websites are 20 MB of NPM libraries. It should take you less time to implement a DSA than to read the documentation for a library if you aren't a pajeet, AND it won't have weird bugs and edge case performance degradation as a bonus.
>>
>>68816309
>handrolling all your own datastructures is not going to introduce more bugs than getting reliable, tested implementations from libraries
>>
>>68815371
>muh scary /pol/
>>
>>68816360
Yeah, I specifically excluded pajeets
>>
>>68816397
>I only write babby projects for school
>>
>>68816195
are you merely pretending to be retarded for (You)s or do you genuinely not know how type erasure works?
>>
>>68816393
no, just obnoxious and dumb
>>
>>68816195
>using a garbage-collected language for time-critical code
undergrads should be shot on sight
>>
>>68816449
Nah, I write Go for Google.
>>
>>68817058
yikers
>>
>>68815854
If you need generics you shouldn't be using Go
>>
>>68815302
>real programming languages
>achieving generics through glorified copy-paste
>>
If you "need" generics then you haven't thought about the problem properly. Rob Pike, ken Thompson and Russ Cox are smarter than you.
>>
>>68817779
If you need more than one data type you haven't thought about the problem properly.
>>
>>68816639
>what is a real-time garbage collector
code monkeys should be shot on sight
>>
>>68817814
>doesn't understand garbage collection or its impact on performance
i guess high-schoolers should be shot on sight too, since they missed you
>>
>>68817779
If you "need" to program then you haven't thought about the problem properly. Gauss, Euler, kurt Gödel and Richard Feynman are smarter than you.
>>
>>68816393
Lol ur retarded
>>
Wait...
Go doesn't even have generics ??
Why would anyone use this crap ?
>>
>>68817856
Not everyone programs with crutches.
>>
>>68817833
>timing
>performance
pick one and only one
>>
>>68817593
>yikers
>>>/reddit/
>>
>>68817856
Generics arent that important for certain types of programs
>>
>>68817903
oof
>>
>>68817886
>not understanding the meaning of "time-critical"
shoot yourself on sight
>>
>>68818106
Nice goalpost moving
>>
>>68818349
He said time-critical in his original post you dumb faggot
>>68816639
>>
>>68817912
Like trivial ones.
>>
>>68815163

Go (baduk, igo) is a mind-bendingly complex game.

Go the programming language is bullshit.
>>
>>68817856
Some people mistake productivity with sloc. Go makes them feel productive.
>>
>>68818580
That means it's critical exactly when things happen, not what the total throughput is, you absolute summerfag who should have grown tired of shitposting as the novelty wore off months ago.
>>
>>68818829
And what do you think happens when garbage collection occurs?
>>
>>68819138
That's the point of an RT collector, predictable timing.

Look, I'm not saying all programs should use garbage collection, I'm especially not saying that all time-critical programs should use garbage collection. But the original statement implied that time-critical programs should never use garbage collection under penalty of being shot, which is utter bullshit.
>>
File: OOP_in_loo.jpg (43 KB, 624x351)
43 KB
43 KB JPG
>>68819138
>somewhere in the inner poos of India
>PAJEE PAJEE COMMM POoOO WHHIT US
>*brrrttr*
>*brprprpprprpr*
>*BRPOOOPSH*
>OOoOH PAJEE IZ A BIIG ONE VERY GUD
>**BEEP** **BEEP** **BEEP**
>OH NO EVERYONE PRETEND TO CALL CENTER
>....
>....
>....
>Garbage Collected!
>THAT WAaaAS TIME CCCRITICAL PAJEE
>>
>>68818829
you fucking retard i knew you didn't know what garbage collection did to code
i hope you honestly kill yourself
t. original guy you replied to; all undergrads must hang
>>
>>68819194
>predictable timing
so you still don't understand "time-critical"
just let the garbage collector collect your posts
>>
File: pajeetistan.png (3.66 MB, 1920x1080)
3.66 MB
3.66 MB PNG
>>68819241
BEEP BEEP BEEP BEEP

BISHHUUUUUUUUUUoOOOOWW

BAMBMMBMBMRRMBMHGGHUHUCRHRHRRR
>>
>>68819225
>you fucking retard i knew you didn't know what garbage collection did to code
It does nothing to code. For data it primarily reclaims unreachable memory and secondarily compacts memory, improving locality, so depending on memory usage patterns you can even get better performance out of it. Not to mention memory safety and programmer productivity, which really do matter when you're employed and not a NEET LARPer.
>>
>>68819370
thx i'll go tell my research advisor to scrap our project on embedded systems and restart in Go since you told me wow thx anon sir... !
>>
>>68819241
What do you think "time critical" means, then?

>>68819416
Where did I say you have to use GC, Go or any other language? I never said manual memory management doesn't have a place, all I'm saying that GC sometimes does have a place. For example if you find yourself doing manual dynamic memory allocation in an embedded application. Then you're better off using either static allocation or a RT GC.
>>
>>68819370
>It does nothing to code.
>except all these things that interrupt the code from running
>>
>>68819469
>>except all these things that interrupt the code from running
So do your interrupt lines and your RTOS, if you're using one, what's your point? These are things that you will likely be using in a real embedded job, nobody cares about your Arduino LED flasher.

So as long as you meet the timing requirements, what's the problem? If GC makes you fail them, by all means, use all static allocation, I'm not the one calling for people who choose one of two perfectly valid approaches to be shot.
>>
>>68819466
>Where did I say you have to use GC, Go or any other language?
let me quote you
>so depending on memory usage patterns you can even get better performance out of it. Not to mention memory safety and programmer productivity, which really do matter when you're employed and not a NEET LARPer.
if that isn't you then stop replying to posts as if they were speaking to you
>>
>>68819562
>let me quote you
There's nothing there about Go, and nothing about GC being the only valid approach to time-critical programming.
>>
https://research.swtch.com/generic

From what I can see, Go developers have direct experience with the hairy problems that particular implmentations of generics bring to C++ & Java and do not want to replicate them in Go. If a patch/proposal came in that gave developers generics without huge penalties to either compile-time or run-time, then it would get added to the language. None have surfaced.
>>
>>68819289
>>68819214
based pajeet poster
>>
>>68819596
>without huge penalties to either compile-time
Why is this a problem? (If it's within reason compared to other compilers, of course)

If you don't want the increased compile time and binary size, all you have to do is simply not use generics.
>>
>>68819592
>let me have an entire argument about how garbage collection is just fine in time-critical code
>and then tell you that i'm not saying it's the "only valid approach to time-critical programming"
really, i'm not joking: kill yourself.
>>
>>68819596
>let's not give developers more options (in this general-purpose OOPajeet language) because if they use those options then they incur consequences
Ah, yes. THIS is who I want designing my programming language.
>>
>>68819596
>that particular implmentations of generics bring to C++ & Java
Well those are about the worst examples they could possibly find, maybe if they checked out D and C# instead we wouldn't have this mess of a language.
>>
>>68819724
Saying it's fine to use GC in time critical code is obviously not the same as saying it's not fine to use manual memory management for time critical code, where the hell do you get that from?

GC means you gain programmer productivity and memory safety, but if you can't use it because of resource or timing constraints, what have I written that you construe as saying you use it anyway?

That's a pretty good sign that your entire embedded carreer consists of making a LED flash on an Arduino. In the real world all that matters is costs and constraints. If BOM costs dominate over dev costs, you probably want to use lower power hardware and manual memory management, but if dev costs dominate over BOM costs, you probably want to go with higher powered hardware for more programmer conveniences like a RTOS and RT GC. Nobody in the industry cares about your ideological purity e-peen.
>>
>>68819899
>Nobody in the industry cares about your ideological purity e-peen.
Please, keep posting. I love it.
>>
>>68819941
Keep making that LED flash
>>
>>68819899
GC doesn't give you memory safety though, it only plugs memory leaks.
>>
>>68819948
>I need to resort to ad-hominem because I can't cope with being wrong and trying to salvage nonsense arguments by hoping no one notices when I go back on what I previously said
Don't stop posting.
>>
>>68819962
Just let him keep posting. Anyone with an internet connection and the ability to use a search engine knows what he's saying is absolute garbage.
>>
First of all actual time-critical systems aren't doing runtime allocations at all so that kinda eliminates the need for GC. /g/ is fucking retarded sometimes.
>>
>>68820016
they think golang is competing with C when it's really just competing with python/JS
>>
>>68820032
Well that's the most asinine thing I've heard today, being as barebones as C doesn't make something a replacement of C.
>>
>>68820056
Undefined behaviour and no error checking does
>>
>>68815163
The absolute state of /g/
this illustrates why I love seeing seeing white programmers get replaced by 'pajeets', they are a bunch of hacks who learned one way to program and now are completely ignorant of any other way of doing something. if some programming language doesnt follow their meme methodologies they rage like Stockholm syndrome stricken little girls protecting their captors

this thread is completely pozzed, I'll enjoy seeing all of you get *real* jobs
>>
>>68819963
Please, show me a single statement that I've gone back on. But of course you won't because you can't, because I haven't gone back on anything.

>>68819962
Leaks, double frees, dangling pointers, etc. are all memory safety issues addressed by GC.

If you're thinking about things like buffer overflows, that's orthogonal to GC, you can have bounds checking and manual management as well as you can have no bounds checking and GC.

>>68820016
That's complete nonsense. Yes, obviously you don't need GC if you don't do runtime allocation whether it's time critical or not, but no, not all time critical systems are easy or desirable to implement using only static allocation. It would be nice if they were, but that's not how it works in the real world. Any embedded dev should want to use static allocation, but not at any cost, certainly not at the cost of time-to-market or total unit cost. That just doesn't make business sense.
>>
>>68820138
desu the "idiomatic" Go way (interface{}) decimates the performance so at least he is carrying over something decent.
>>
>>68820056
they are both incomprehensible to 90% of /g/ so they might as well both be rocket science.
>>
>>68820153
>that's orthogonal to GC
No fucking shit, that's what I said. GC doesn't give you memory safety.
>That just doesn't make business sense.
Making a program that's guaranteed to fail some time in the future doesn't make business sense either.
>>
>>68819241
I never got an answer to
>>68819466
>What do you think "time critical" means, then?
but I have a sneaking suspicion you thought it was something completely different, which is why having such an autistic meltdown to distract from the embarrasment.
>>
>>68820248
depends on how far in the future and how much a failure hurts, figuring those things out is exactly business sense
>>
>>68820260
oh woah you sure got him dude chalk another one up on the 4chan argument victory board for you even though you have multiple people disagreeing with you and correcting your posts man nice good job
>>
>>68820248
>No fucking shit, that's what I said. GC doesn't give you memory safety.

Leaks, double frees, dangling pointers, etc. are memory safety issues. This is what a GC is concerned with, this is the memory safety that GC brings to the party. You can't blame the GC for not meddling in other memory safety issues that the GC has no business with.

>Making a program that's guaranteed to fail some time in the future doesn't make business sense either.

see
>>68820285
and also a garbage collected system is no more or less likely to fail in the near or far future than a statically allocated and manually managed system. There are other sources of bugs, no matter what you still have the halting problem.

>>68820298
>you have multiple people disagreeing with you and correcting your posts man nice good job
It's fine to disagree, but nothing has been corrected. I've repeatedly asked to have passages that are supposedly wrong or contradictory pointed out, but so far there's nothing except >>68819562 which quotes a completely unrelated passage.
>>
>>68820382
>but nothing has been corrected
OK, so you're delusional. Got it.
>>
>>68820486
So you can't show me a single thing I've said that was wrong. Doesn't look particularly good on your part.
>>
>>68820515
been doing it all thread you're just delusional
>>
>>68820557
>this much damage control
It was clear from the start that you were in over your head. Hopefully other people in this thread learned something, because you must be incapable of it.

Quoting something and mechanically just stating the opposite does not constitute "correcting" anything. You have succeed in demonstrating the baseless opinion that there is only one valid approach to memory management (which is fine for you to hold, not that it will get you far in professional life), but you have demonstrated or corrected exactly zero facts.
>>
>>68815163
>monomorphized
What does that even mean?
>>
>>68819721
It's a problem because every programmer in the company will use a generic here or there to save a few seconds typing time one time for a few seconds compile time every single build in the future, until the compile time is so long that Rob Pike can design an entire programming language while waiting for the code to compile.
>>
>>68815199
Go and the .net platform are based of Wirths language Oberon.

.net comes from blackbox oberon
>>
>>68817058
May you post the source of your claims?
>>
>>68820697
Lol you got BTFO so hard you're still crying over it
>>
>>68824126
>Post confidential code
Yeah nah. If you're just looking for Go, there's a lot in the public Chromium code
https://chromium.googlesource.com/infra/luci/luci-go/
>>
>>68820727
Not mathematical monomorphism as in generalization of the injective property, he means the CS brainlet version where its dual notion is polymorphism.
>>
>>68819848
D and C# are barely better than C++ and Java respectively.

The only kind of "generics" that isn't trash is FP parametric polymorphism with HKTs.
>>
>>68820727
A form of generics where generic functions are essentially macros for the compiler to generate unique functions for each type combinations. Each of the generated functions is monomorphisation. The alternative is polymorphic generics where there really is only one function compiled.
>>
>>68824800
*Is monomorphised.
>>
The C++ shills are butthurt because Go is literally the anti-C++ language. They can shill/meme/beg every day and Go is never going to get morphed into having C++ class based type system because that is a static way of programming. If someone really wanted Go to have generics they could make it on their own because its not something that has to be built into the core language. C++ programmers are brainwashed into one way of doing something and they want every other language to be a cheap imitation of C++ like Java and C#. But Go is different, its going to stay different no matter how hard C++ shills rage, wail and moan.
>>
>>68824875
>class based type system because that is a static way of programming
the fuck is OOP and the fuck is static programming. just stop posting already
>>
>>68824875
Lmao wat
>>
>>68817779

Well let me give you a challenge. How would you implement a geometry library that handles n-dimension geometry and can interoperate with a library user's existing geometric types?
>>
>>68825184
>existing geometric types
<not who youre quoting>
when you say types, you mean type classes, right? maybe youre not aware that Go doesnt have classes and therefore does not need to write a dozen different functions that accept a dozen different class types and then hide all those functions into a single generic function so you can pretent you actually didnt write a dozen different functions do the exact same thing but only slightly altered to accept a dozen different class types
>>
>>68819596
obviously /g/ is smarter than those people
https://youtu.be/sX8r6zATHGU?t=3029
>>
https://github.com/trending/go
https://awesome-go.com/
>>
>>68825289

I mean types as any inbuilt user defined type. I'm not necessarily talking about classes, POD structs and type classes(traits in rust?) are fine too, just any agglomeration of basic types that form a geometry primitive e.g. a coordinate. And it's disingenuous to say that each function for geometry in n-dimensions has a completely different implementation that can't share many common features or significant parts of the implementation.
>>
>>68825381
*Inbuilt or user defined type.
>>
>>68825381
>And it's disingenuous to say that each function for geometry in n-dimensions has a completely different implementation that can't share many common features or significant parts of the implementation.
I didnt say didnt the different implementations cant share common features, thats exactly what generics is is a bunch of functions that are grouped together that share common features so that they do the same thing but with only minor differences to handle each type class, so generics isnt really doing anything for you accept hide code
>>
>>68825381
>>68825418
well rust has shit like vec! macros to generate your types for you. There's no reason golang couldn't have a stronker macro system to do code generation instead of the garbage fire it officially has now.
>>
>>68825463
your shitty macro/generics is a garbage fire, Go programmers dont program that way, so give up begging programmers Go to make a bunch of type classes and your boilerplate macros to service them
>>
>>68825495
Rust macros are glorious but i can take or leave generics. They're really nice for things that Rust's aiming for but go isn't like that. What golang does have is
//go:generate
and it's fucking terrible. Anything would be an improvement, except the obvious alternative idiomatically writing things a lot of times by hand.
>>
Can someone point me to some go code on github that has huge amounts of boilerplate due to a lack of generics? I just want to see it with my own eyes.
>>
>>68823844
Didn't Go derive from Aleph from Plan9?
>>
>>68825715
https://github.com/scylladb/go-set?files=1
>>
>state of Go
>based one man's gimmick from year ago
>>
>>68815854
easy, not using Go in the first place
>>
>>68825495
Implying go programmers don't just use interface everywhere which is pretty much a glorified void*.

>>68825454
I really don't get what you actually mean by hiding code? Are you arguing against grouping common patterns or against abstraction in general? Sure generics hide code and allow code to be generated at compile time, but I mean that's the point and they allow a library to vastly increase the generality of a library without giving up any performance (unlike interface) and enhancing maintainability compared to writing separate functions for every type. Also generics already exist in the go language, except they're only in the standard library and can't be utilized by library writers. Also note that I'm not specifically talking about C++ duck-typed templates, Rust's traits and Haskell's type-classes are also examples of good implementations of generics.
>>
>>68827192
I like that you put the type after tje variable in Go. Looks cleaner. Thats about all I like about it.
>>
>>68827239
>but I mean that's the point and they allow a library to vastly increase the generality of a library without giving up any performance (unlike interface)
generics dont increase anything, youre just writing a lot of functions like you could in any language. generics means you use a single function prototype instead of looking up the actual prototype you wrote earlier in code so its looks like you only have one function, so big deal, I hardly call that an abstraction, you still wrote all those functions, generics is not saving you from having to write them. In Go you dont have to write a bunch of functions because you have interfaces so you only write a function that fits the interface, that is abstraction. Its really boring even talking about this with you, youve been brainwashed into thinking something is an abstraction when its not, its just saving you from looking up functions prototypes when you call them
>>
>>68827239
>Implying go programmers don't just use interface everywhere which is pretty much a glorified void*.
thats exactly what generics is in C++, its a glorified void

>oooh loooky here! I have a type <T>, that could be any type, wow, its like a void that can take any type, oh wow, this is so sophisticated, I got to go on /g/ and tell everyone about it
>>
>>68827680
Interfaces aren't comparable to generics because they are run-time polymorphism, other languages handle this using inheritance and virtual functions (interfaces are mostly equivalent to abstract base classes in C++). Generics generally refer to compile time polymorphism which is a requirement for writing generic libraries with zero-overhead. Dude even go uses this is its standard library. Image the performance hit if the std-lib containers used interface to handle user types.

>>68827718
Same goes to you, casting a void* to wrong type or performing the incorrect operation on a piece of void data is a run-time error whereas with generics it is a compile-time error (also using void* prevents many compiler optimizations). I specifically said I'm not exclusively referring to duck-typed generics like C++ templates. The types that T can be can be easily constrained with rust traits or Haskell type-classes and they can also (more clunkily) be constrained using SFINAE and soon concepts (C++20) in C++.
>>
>>68819848
Java is only bad in this regard because it was a late add-on, so it is an astoundingly dumb example.
>>
>>68824260
You keep repeating it, but that won't make it true.



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.