Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Maintenance is complete! We got more disk space.
Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 50 KB, 1500x1000, golang.png [View same] [iqdb] [saucenao] [google] [report]
70914003 No.70914003 [Reply] [Original] [archived.moe] [rbt]

why do people shit on it here? don't they want something that can replace C++?

>> No.70914046

>>70914003
what makes you think golang will replace c++?

>> No.70914060

How can a gc language replace a non-gc language? The fundamental difference is too big.

>> No.70914062

>>70914003
>Go
>Replace C++
Are you high? Go might replace java and php. It's nothing like C++.

>> No.70914069

cpp is fine and I do t want to learn more languages

>> No.70914115

>>70914003
I'm starting to think Go shilling is a satire. You can't just make a language that's both less expressive and less powerful than C. You just can't. This has to be intentional.

>> No.70914124
File: 155 KB, 800x800, go language.png [View same] [iqdb] [saucenao] [google] [report]
70914124

>> No.70914137

>>70914003
i don't use C++ at work or for fun so no

also golang is built for the lowest common denominator of programmer.

>> No.70914178

just wait few more years
it will beat every other language

>> No.70914185

Hey man. People shit on it because they're turbo autist neets

>> No.70914186

>>70914178
LOLxD

>> No.70914201

>>70914003
If you want a better language than c++, then learn Nim. It has superior metaprogramming since c++ only has suport from templates and shit macros, while nim uses templates and AST. You can control the gc, or not use it at all. Go has none of those options.

>> No.70914208

>>70914115
> I'm starting to think Go shilling is a satire

It's not. I've met plenty of them irl. These are people that think generics are incredibly difficult to understand. List<T> is basically wizardry to them. It's almost impossible for a normal person to understand the depths of their stupidity.

>> No.70914225

If you want a better C++ alternative, just pick any other language in existence.

>> No.70914240

>>70914225
GOT EM

>> No.70914385

Go has like 10% of C++ features.

>> No.70914411

>>70914385
exactly? why do you C++ is so shit?

>> No.70914479

>>70914208
I'm inclined to believe you're conflating people who say generics are crutch with people who don't understand generics as a concept.
It's moot in any case since Go has had generics from the start by giving you the ability to just generate code automatically like you would in any other language, and Go 2 has it straight up built in 1:1 how C++ people want it.

If you need actual generics, you're likely working with poorly designed APIs or designing a poor API.

>> No.70914495

>>70914479
>If you need actual generics, you're likely working with poorly designed APIs or designing a poor API.
Or you know using data structures.

>> No.70914499
File: 34 KB, 800x800, 800px-Rust_programming_language_black_logo.svg.png [View same] [iqdb] [saucenao] [google] [report]
70914499

>>70914003
only rust can replace c++ because rust aims to replace c

golang will be a java like without the vm
in fact slower than java

>> No.70914513
File: 112 KB, 1600x900, benchmarks.jpg [View same] [iqdb] [saucenao] [google] [report]
70914513

>>70914499

>> No.70914535
File: 292 KB, 512x512, yammy.png [View same] [iqdb] [saucenao] [google] [report]
70914535

>>70914124
Go 2.0 is coming soon

>> No.70914539

>>70914495
Unless you're doing actual serialization of some binary format/protocol you probably made yourself, you have no excuses. What data structure are you working with?

>> No.70914544

>>70914479
>If you need actual generics, you're likely working with poorly designed APIs or designing a poor API.
Because redefining containers and algorithms for type is the hallmark of a good api.

>> No.70914557

>>70914539
An array. I want my functions to work on all kinds of arrays.

>> No.70914565

>>70914539
Are you saying you don't use heaps and queues daily?

>> No.70914587

>>70914479
>Go has had generics from the start by giving you the ability to just generate code

Gotards are actually this fucking retarded.

>> No.70914600

>>70914479
>Go has had generics from the start by giving you the ability to just generate code
>confusing templates with generics
Can't really blame you but come on, man.

>> No.70914619

>>70914513
>posting benchmarks to prove his point
opinion discarded, benchmarks are fucking retarded

>> No.70914632

>>70914600
How are templates a means for implementing generics? It's a cleaner and infinitely more efficient solution than passing around empty interfaces everywhere.

>> No.70914651

>>70914632
Meant to write "not a means"

>> No.70914656
File: 20 KB, 318x326, 1501752130906.jpg [View same] [iqdb] [saucenao] [google] [report]
70914656

>>70914479
>If you need actual generics, you're likely working with poorly designed APIs or designing a poor API.

>> No.70914657

>>70914479
10000% brainlet

>> No.70914671
File: 21 KB, 580x548, 1534169918096.jpg [View same] [iqdb] [saucenao] [google] [report]
70914671

>>70914632
I give up.

>> No.70914703

>>70914060
Pauses are in the order of microseconds

Look up what a microsecond is since I'm sure you'll get it confused with milliseconds.

>> No.70914715 [DELETED] 

>>70914632
It's not cleaner, it's actually far worse and opens up far more opportunities for bugs, and performance wise it's exactly the same as monomorphization.

>> No.70914726

>>70914479
>>70914632
Target audience is here.

>> No.70914729

https://github.com/ksimka/go-is-not-good/blob/master/README.md

Shut the fuck up and learn Rust instead

>> No.70914738

>>70914003
golang more like gulag fuck that shit lol

>> No.70914743

>>70914729
>no OOP
is actually a downside there lol

>> No.70914762

>>70914729
Rust is a faggot language made by trannies. Already almost as bloated as c++ with even slower compile times somehow. They totally lost the plot

>> No.70914770

>>70914544
Are you pretending like you have to define them by hand? Do you even know why they're called templates?

>>70914557
Implementing an array is trivial. I don't know what you're saying.
Why does it need to handle arbitrary types instead of a typed interface? What is it an array of? Whatever that element is, should be expressible as an interface that is not only less ambiguous, but better technically.

>>70914565
In Go? I don't think I would have a reason to.
It's literally the same concept but bound together when you use interfaces and objects.
Literally the C equivalent is just writing the same shit but making sure every function takes in some void pointer(s).

>>70914600
Templates have to be assumed because the use for actual generics is basically nobody.
Go has both regardless. Do you want template code generation at compile time? Check. Do you want our runtime to disregard type saftey at runtime? Check. Some combination of both? Of course.
Imagining people besides the Go maintainers actually caring about real heap implementations, etc. seems highly unlikely.

>look dude I need to use generics for my web service

It's no wonder people are so hostile to the idea of understanding the entire pipeline of the thing you're actually working on and defining how it's supposed to work with some sanity checks instead of just saying "lmao it's arbitrary memory, who cares"

>> No.70914789

i entered this thread actually wanting explanations why go is thought of as shit but the entire thread is just >implying tier faggotry

>> No.70914799

>>70914762
Name a language that isn't developed by faggot trannies

>> No.70914804

>>70914770
> actually defending Go

Fucking brainlets lmao.

>> No.70914807

>>70914762
since the compiler babysits you heavily it'll compile slower than c++ metaprogramming template hell

>> No.70914817

>>70914799
Go,C,Erlang,Ocaml

>> No.70914824

>>70914804
My opinion as a user is hardly a defense for the language. It's a programming language, not a land or person you imbecile.

>> No.70914831

>>70914817
> Rob Pike
> not a faggot tranny

Pick one.

>> No.70914834

>>70914003

Because RUST replaces C++ not GO.

>> No.70914844
File: 26 KB, 949x647, 1526103988277.png [View same] [iqdb] [saucenao] [google] [report]
70914844

>>70914738
>golang more like gulag fuck that shit lol
fuck golang but you are peak cringe

>> No.70914855

>>70914799
Zig

>> No.70914861

>>70914834
Except it doesn't. You can choose a subset of c++ that compiles fast and runs fast with decades of compiler optimizations at your disposal. If you use rust your language is going to compile slow and oftentimes be slower than go because the compiler devs are trannies

>> No.70914909
File: 30 KB, 554x554, 1553862210308.jpg [View same] [iqdb] [saucenao] [google] [report]
70914909

>>70914046
>>70914062
>>70914069
>>70914201
>>70914225
>>70914385
>>70914499
>>70914587
>>70914729
>>70914738
>>70914804
>>70914834
stop fighting the future, grandpa

>> No.70914915

>>70914831
Pike should be unemployed since every public C library he's ever created has been full of obvious security vulnerabilities. He has an average of one vulnerability for every two lines of code. Theo de Raadt was right.

>> No.70914928

>>70914915
Prove it rust tranny

>> No.70914930

>>70914060
>the only thing that matters in gc is latency
>what is throughput
enjoy go failing to manage 80G heap LOL

>> No.70914934

>>70914770
>Are you pretending like you have to define them by hand? Do you even know why they're called templates?
Because the compiler does the generation for me. I get fast code without needing to copy paste for each type.

>It's literally the same concept but bound together when you use interfaces and objects. Imagining people besides the Go maintainers actually caring about real heap implementations, etc. seems highly unlikely.
You should if you value performance. The empty interface is an awful hack because it relies upon working out all of the types at runtime which is terrible for performance. https://youtu.be/DJ4d_PZ6Gns goes into more details.

>> No.70914949

>>70914834
Rust tried to replace C++, but ends up being a worse Ada.

>> No.70914954

>>70914225
Except if, ya know, you program things where speed is important.

>> No.70914967

>>70914930
meant for
>>70914703

>>70914861
kys gotard rust backs on years of research that went into optimizing c and c++ programs while go can only reach its speed in 1 out of 17 synthetic benchmarks

>> No.70915006

>>70914967
>Muh research

Guess we should all be using Haskell since it had the most "research" of any language.

>> No.70915024
File: 421 KB, 1200x1200, gopher_fabulous.png [View same] [iqdb] [saucenao] [google] [report]
70915024

https://www.youtube.com/watch?v=ZACOc-NwV0c
anybody in this thread who uses go should off themselves immediately

>> No.70915048

C# and fucking JS are faster than that piece of shit and if i want the simplest web api i can just use Python

>> No.70915061

because its unironically the most useless language there is.

no syntax sugar or generics or overloading for fast development. even Java is miles better than Go.

has gc so slower than powerhouse C or C++ or Rust

>> No.70915073

>>70915024
God damn, Go users are the absolute worst.

>> No.70915083

>>70914513
The median value of rust on that benchmark is lower than the c and c++ ones?

>> No.70915102

>>70914513
>C# fucking beating almost everything

B A S E D

>> No.70915114

>>70915024
>programming language has fag users
Fucking shocker, have you seen the state of the tech industry? Try finding a useful language without them, no Fortran and Cobol are not coming back.

>> No.70915118

>>70914934
>Because the compiler does the generation for me...
This is tool dependent and imo a stupid point to make.
Unless you count macros and the preprocessor, C doesn't ship with code generation tools. You typically write them yourself and ship them with projects. Most people make this a dependency with makefiles which is obviously not the compiler.
Go ships with a standard and you can use your own. It's 1 additional command, 1 time `go generate` before `go build` will work. Oh no, what a nightmare?
And then obviously you have whatever bullshit environment your project imposed on you if you're working in C++ which could be a specially crafted hell, most of which problably is outside of the standard.

>You should if you value performance...
You're contradicting yourself.
You're asking me why I don't use empty interfaces over typed interfaces, then showing why empty interfaces are bad. Which is what I already said when I said "not only less ambiguous, but better technically" in the same post.

Go's standard heap implementation uses an empty interface. It's trivial to implement your own with type saftey that makes more sense to your specific project instead of being truly generic. You're be better off separating the purposes of the heap into interfaces and implementing that on structures. Which you have to do anyway.

Not defining your interfaces is nothing short of lazy, and only displays to me that you didn't think your program through well enough to even understand what you're doing.
>well I can't really explain how we implemented caching, we just use a heap of memory and throw things at it, you'll have to read the entire thing yourself to understand it instead of just reading the interfaces that are well separated and display intent/purpose

I swear the harder people fight against this the more convinced I am they're just trying to cover their own lazy ass.
>no I'm not a bad programmer, it's the language that's bad

>> No.70915140

>>70915083
The benchmarks game isn't meaningful beyond memes. It's just a bunch of people volunteering code for toy problems in the language of their choice. People also cheat, I know some of Java submissions import external libraries which are explicitly disallowed by the rules, but the results are included anyway.

>> No.70915151

>>70915114
kys tranny, by your logic i might as well use rust, which is the superior successor to c and sepples

>> No.70915186

ITT: Go sucks because <describes some thing that's actually a good>

>> No.70915195

>>70915114
Show me a Java, C#, Kotlin, Swift or F# conference where people are passing around 3D printed dildos and talking about shoving things up their asses. This kind of shit is predominately found in brainlet languages with dynamic typing (Ruby, Python and Javascript) and now Go because Go's type system is so shitty it might as well be dynamically typed.

>> No.70915201
File: 25 KB, 395x443, gopher_delusion.png [View same] [iqdb] [saucenao] [google] [report]
70915201

>>70915186
>interface{} good
>no generics good
>mutex in channels (lol)
>trannies good

>> No.70915226
File: 3.22 MB, 253x275, 1557595465673.gif [View same] [iqdb] [saucenao] [google] [report]
70915226

>>70915186
Because its only usuable for Web Apis but for that i can already use .Net-Core, Spring, Node.JS, Flask/Django, Rocket and more. So Go sucks because its literally FUCKING USELESS

>> No.70915238

>>70915118
>This is tool dependent and imo a stupid point to make.
What the fuck are you on, Templates are the core of C++ you moron.
The go build system is designed for pajeets who don't understand how to build their code. It requires a bunch of hacks to get it do what you want in a large code base, where as CMake gives you full control to build whatever you need.

>Go's standard heap implementation uses an empty interface. It's trivial to implement your own with type saftey that makes more sense to your specific project instead of being truly generic. You're be better off separating the purposes of the heap into interfaces and implementing that on structures. Which you have to do anyway.
Exactly, I shouldn't have to re-implement the standard library to get efficient code. That is fucking retard. Good we can agree on this.

>Not defining your interfaces is nothing short of lazy, and only displays to me that you didn't think your program through well enough to even understand what you're doing.
I don't know what you are projecting here.

>> No.70915242

>>70914003
Zig will replace both C and C++

>> No.70915296

>>70915238
>Templates are the core of C++ you moron.
What's your point? C++ is not every programming language, hence "tool dependent".
Templates are also not specific to C++.
If your argument boils down to "X is bad because it does something different to how it's done in C++" that's a bad argument. The person I'm replying to is implying Go isn't worth using because to generate code you have to type `go generate` before building. This is a dumb argument. Just because Go doesn't generate code every build does not mean it doesn't support it as part of the standard.

>> No.70915309

>>70915226
"If you think programming in java is a good idea, then please stop programming." - Rob Pike

>> No.70915324

>>70915238
>it's core to the language, but I also need CMake to make something worthwhile
top lel

>> No.70915348

>>70914115
it was intentional, the main design goal was just to create a language that google's shitty engineers could use without creating major disasters

>> No.70915355

>>70915309
I don't like Java but it's far better than Go.

>> No.70915358

>>70914479
are you serious?

>> No.70915359

>>70915309
Thats why we can use C# !

>> No.70915363

>>70915324
Work on your reading comprehension child.

>> No.70915370

>>70914003
>language with garbage collection will replace C++ or C
It can only replace languages such as Java or C#.
If you want something that can replace C++, then use Rust.

>> No.70915378

>>70914003
>Gopher as logo
Software products using creatures as their logo are autism products by people, who seek recognition for the capability of implementing an idea, but are incapable of building anything of significance.

>> No.70915383

>>70915378
based

>> No.70915395
File: 1.75 MB, 500x284, holy fuck.gif [View same] [iqdb] [saucenao] [google] [report]
70915395

>>70915238
>Exactly, I shouldn't have to re-implement the standard library to get efficient code. That is fucking retard. Good we can agree on this.
It's funny, because it's precisely what every major C++ project ends up doing

>> No.70915398

>>70915238
>I shouldn't have to re-implement the standard library to get efficient code
You shouldn't be using a GENERIC heap in the first place. That's the entire point.
You're literally demonstrating your lack of ability to comprehend abstraction.
Whatever you're implementing uses a heap in concept, but in itself as a system, as an interface, is not just a generic heap.
In any language, you'd still have to abstract this. The difference is that with an interface it's compartmentalized and specific inherently, instead of just a section of the project that you hope is documented and actually separated.
One is a standard on a language level and the other is a standard on a project level which is obviously terrible because you wrote it.

>>70915358
Yes. Why waste posts like that.

>> No.70915399

>>70915309
>If you do A, I feel better than you, because I do B
>Behold my wizard powers!

>> No.70915405

>>70915118
>Not defining your interfaces

I almost forgot how shitty Go interfaces are. This language really has absolutely nothing going for it other than the Google name being attached to it.

>> No.70915413

>>70915296
Ok I see what your misunderstanding is. When I said generate, I was refering to how the compiler generates type specific code for each of your template instatiations. The compiler automatically does what you need to do in to manually when redefining something for each type needed.
This is entirely separate from the build process.

>> No.70915422

>>70915398
you just sound like such a fucking ignorant retard i couldn't believe it and i had to ask

>> No.70915430

>>70914208
Generics are retarded, its an euphemism of OOP and leads to the same problems, if you want to reuse code for a "similar" thing just copy past it and put a comment on top of your code.

>writes 5K lines 3 months latter coworker changes a line from a secondary function
enjoy

>> No.70915439

>>70915395
nah

>> No.70915464

>>70915398
>You shouldn't be using a GENERIC heap in the first place. That's the entire point.
Why not? The problem with Go is that “generics” require runtime introspection instead of being statically compiled for each type signature. The STL is perfectly fine for all but the most demanding tasks.

>> No.70915488

>>70915430
This is even worse if your function has a dozen definitions, which is what you are forced to do in Go.

>> No.70915501

>>70915430
>Generics are retarded, its an euphemism of OOP and leads to the same problems

Most statically typed functional languages use generics extensively. Generics have absolutely nothing to do with OOP and were found in statically typed functional languages before any of the popular OOP languages today were even created.

>> No.70915522

>>70915405
My whole argument is in favor of the opposite. More type saftey, not less. I don't know how you got the other impression.
I'm also not sure what your problem is with Go's interfaces since you straight up didn't say.
It sure is better than the competiton imo.
>implements
><t>
>void

>>70915413
I still fail to see what you're hung up on. What you just described is what `go generate` is.
It's literally only semantically different. Go seperates code generation from compilation. So does C++ but only in implementation. Just because you run 1 binary doesn't mean the "code generation" phase of building isn't technically a different concept.
Agan, the only difference is that one is done automatically, and the other isn't. Which makes more sense for Go since it's not likely you'd even need to do that in the first place, let alone check if something needs to be generated on each build. It does nothing but waste time. And if people want to pretend like that time doesn't add it I defer again to all the 3rd party tools developed (even by Google themselves) to improve build time for C++ projects. Most of which seems to be related to the preprocessor. Probably just a coincidence though.

>>70915422
You're projecting a little hard to be honest. You don't even know me and are likely misinterpreting something, but are jumping to conclusions. I can do the same and assume not many people like you as a result of that trait.

>> No.70915525

>>70915024
someone should mass 3d print go mascot dildos and sell them

>> No.70915536

>>70915024
my dick is hard
she is beautiful

>> No.70915542
File: 2.42 MB, 1619x2024, faces.KenThompson20515.web_.jpg [View same] [iqdb] [saucenao] [google] [report]
70915542

Honestly never gave Go much consideration because of all of the /g/ hate, but recently I found out Ken Thompson was one of the creators, so I think I want to give it a try.
I mean, none of you dumb fucks created Unix.

>> No.70915545
File: 215 KB, 960x958, 1543331741266.jpg [View same] [iqdb] [saucenao] [google] [report]
70915545

>Generics this generics that

Exactly what type of function can take both arguments as for example strings and ints and work exactly the same? What such method would even do if it has to work the same for all types?

>> No.70915568

>>70915522
>I still fail to see what you're hung up on. What you just described is what `go generate` is.
I’m talking about how templates support generic programming and the role of the C++ compiler in it.

>> No.70915584

>>70915522
lmfao, i am 'projecting' ? just say 'i know you are but what am i' instead, you sounded like a total cringe worthy pseud saying that just now

>> No.70915608

>>70915545
What if you want to implement and ADT which can store and operate on both?
Generics are also extremely helpful for numerics. There are plenty of functions I would want to work on ints, doubles, complex numbers, etc.

>> No.70915611

>>70915464
>Why not
You answered your own question. You have the ability to have statically compiled functions for each type if you use a typed interface. Doing anything else is a choice by the programmer, but you're acting like it's somehow innate to the language. If you choose to implement programs in a way that's not performant, ON PURPOSE, I can't see how that's anyone fault but your own.
As has been mentioned already, nothing prevents you from accomplishing what you're demanding, and this is taking into account you're being vague and weasel like in your wording.

In every scenario you've crafted, the answer is it's possible and not very different from other languages. In some cases, it's better.

No clue what you're on about, but it's really dumb that you can't even present a contrived example of this hypothetical problem that's frustrating you.

>> No.70915621

>>70915545
map? filter?

>> No.70915623

>>70915584
Not sure where you think we are. But this whole like, identity thing you're doing, doesn't work when we're all anonymous.

>> No.70915666

>>70915545
How can you not know? It's so obvious and simple even baby programmers could figure it out. Let me just dig into my bag of examples...
So anyway, I hope you see why we can't stop using C++.

>> No.70915687

>>70914003
Every replacement for C++ is motivated by the idea that programming languages should cater to diversity hires.

>> No.70915695

>>70915623
no idea what the fuck you are talking about retard, we are just engaged in the free exchange of ideas like normal on 4chan

>> No.70915696

>>70915545
Most functional abstractions can't be made in a generic typesafe manner in Go. You can't implement generic typesafe versions of map, reduce, filter etc.

It's far worse when it comes to data structures though. Most libraries end up just using reflection which is really expensive and terribly unsafe. Even the standard library uses the empty interface quite regularly.

>> No.70915708

>>70915545
containers

>> No.70915723
File: 284 KB, 633x709, 5089BF74-551F-4EF0-BCB4-FF4EB400DFA3.png [View same] [iqdb] [saucenao] [google] [report]
70915723

>>70915611
The only way to accomplish this in go is to copy paste the code for each type combination needed or to pass an empty interface. What want is a way to generically create the code for the types I use at compile time and Go provides no mechanism for this besides copy pasting.

>> No.70915727

>>70915687
unfortunately this is true. new languages seem exclusively focused on giving the programmer fisher price tools instead of powerful tools. as many problems as c++ has, it is still the best balance between power and efficiency among native languages

>> No.70915737
File: 43 KB, 400x269, people.jpg [View same] [iqdb] [saucenao] [google] [report]
70915737

>>70915695
I'd argue that "opinions" and "ideas" should be separated.
It's one thing to call me out for being technically wrong. It's another to actually get upset over my writing style. Again, since it's anonymous discussion, I really have no perspective on who is judging me so it basically just goes nowhere. I'm more inclined to believe that it's good enough to be read and understood, so I feel no need to appeal to someone I don't know, and meta posts such as these do nothing but clutter the thread. It seems very pointless to me. Basically the bottom rung here vs the top.

If we were talking about the top, something useful may come out of it. Discussing the bottom is not only worthless, it's the most common. I can get that anywhere, I can only get actual discussion here though, so that's what I'm looking for.

>> No.70915761

>>70915723
Are you seriously lying on purpose for something so easily disproved?
Why man?
https://blog.golang.org/generate

>> No.70915790

>>70915761
Why isn’t this just built into the language?

>> No.70915829

>>70914949
Name one thing Ada does better than Rust.

>> No.70915835
File: 393 KB, 2512x1018, 1539545167312.png [View same] [iqdb] [saucenao] [google] [report]
70915835

>>70914909
>language design rejects almost all innovations from the last 30 years
>the future
please, just die

>> No.70915848
File: 294 KB, 1280x1796, 1280px-Jordan_Peterson_June_2018.jpg [View same] [iqdb] [saucenao] [google] [report]
70915848

>>70914003
If Jordan Peterson was a programmer he would hate go

>> No.70915860

>>70914003
>No proper QT bindings
Into the thrash it goes

>> No.70915862

>>70915761
That does automaye the copy pasting but it isn’t good enough. It still requires me to specify the types I need and pregenerate the generic code for it to interface with my linting. It also requires me to predict the types which a user might need, which might be impossible for very generic functions and data structures.

>> No.70915876

>>70915737
you need to get a grip. please recall how our exchange unfolded:
- you said some shit i thought was really stupid
- i asked you if you were serious
- you told me you were and asked why i posted that question
- i told you
- you decided that i was 'projecting'

how low minded of me to answer the question you explicitly asked me! i can remedy our predicament here on the bottom rung, though. how about this: if you are so ass mad about the way i am treating you, maybe you shouldn't go around saying arm chair psychologist , pseudo-intellectual, basic bitch tier internet banter type shit like saying someone is 'projecting'. how do you expect people to react? did you think i would dazzled by your intellect lmao?

>> No.70915877

>>70915835
>Ignores "innovations"
OOP was an "innovation" and we're still suffering from it. You call it innovation but you've never justified empirically or otherwise if these language features actually lead to better or more maintainable code.

>> No.70915884

>>70915829
Formal methods, professional support
https://www.adacore.com/sparkpro

>> No.70915893

>>70915761
how the fuck does code generation address any of the issues presented

>> No.70915917

>>70915790
What difference does it make? If you want to generate code, call the code generator before build. The only difference is that some languages do this automatically and others don't. And as I said already, one of the major complaints people have with C++ is that the build system is horribly inefficient, and requires a lot of defacto third party tools.
I can't see how this is somehow better than having 1 standard that ships with the language and works when you need it to.

It's exactly the same concept, just not run automatically each build. That's it.
Go 2's implimentation of generics is just going to force the build system to check for this bullshit automatically.

>>70915862
You're saying that like it's a bad thing. Having these things seperated allows you to build that specific thing you just described in an intelligent way.
Think about this from an IDE perspective. It knows if you need to regenerate or not and could trigger it automatically when needed instead of all the fucking time. It can do each step you want, when you want it, instead of all the steps, all the time.
There's really no downside I can see from making this standard instead of hoping other people do it for you.

>>70915876
>expecting me to read all that shit

>>70915893
>how does code generation generate code?
Read it I guess.

>> No.70915920 [DELETED] 

>>70915860
https://github.com/KDE/rust-qt-binding-generator
https://wiki.qt.io/Language_Bindings

uh-huh

>> No.70915928

>>70915877
thats probably because the benefits and drawbacks of the language features mentioned are well defined and well known, and your vague, idiotic notion of 'better' isn't worth talking or thinking about, much less empirically proving

>> No.70915936

>>70915877
Yes but that doesn't mean all of them are bad, and for the record there is no OOP in Rust, it takes a lot from FP instead.

>> No.70915938

>>70915862
>which might be impossible for very generic functions and data structures
Such as?

>> No.70915947

>>70915928
>Are well defined
Where?

>> No.70915962
File: 2.97 MB, 1464x1488, 7FB70BF8-0BA0-4207-8331-077237B9CCF1.gif [View same] [iqdb] [saucenao] [google] [report]
70915962

>>70915917
>this is your “brain” on go

>> No.70915965

>>70915936
Yes, but my major issue with rust is the compile times and how lifetimes and the borrow checker eliminate entire classes of valid programs. You can pretend this leads to "better code" but anything stated without evidence can be dismissed without evidence.

>> No.70915976
File: 152 KB, 720x522, not an argument.png [View same] [iqdb] [saucenao] [google] [report]
70915976

>>70915962

>> No.70915993

>>70915938
Defining a higher order function like map, fold, or filter; or any generic ADT.

>> No.70916042

>>70915965
The borrow checker only disallows code that is inherently unsafe (data races, possible segfaults, etc). You are allowed to use unsafe, and there is nothing wrong with this, it just marks unsafe code as such to isolate points where bugs might occur. As for the compile times yeah they are undisputably pretty awful (well, mostly on the first compile). Their 2019 roadmap does mention they want to polish the language a lot and improve many things, compile times included, so I hope that'll improve in the near future. https://blog.rust-lang.org/2019/04/23/roadmap.html

>> No.70916065

>>70915917
> projecting
> tldr
next you are going to post troll face or call me mad or some shit lmao

>>how does code generation generate code?
>Read it I guess.
ah yes, you've definitely silenced all the critics who were shouting about how go doesn't have a code generator tool (?)

>> No.70916099

>>70915947
you called my bluff, no one has written about or analyzed algebraic type systems / modern static analysis techniques / etc before. or if they have, i certainly don't know how to find such information.

>> No.70916125

>>70915993
But why are you using and/or defining them truly generically? Why can't you abstract your program in a way you can define and convey to the specifications of the language?
Realistically, in what scenario do you need to be this dynamic?
Why can't you have a map of defined interfaces instead? It's not like you're bound to data structures, and the patterns in which you retrieve these objects and unmarshal them back into runtime safe objects IS the interface implementation. Be it in Go or another language. Why not derive an interface from your own purpose of these supposed "arbitrary" objects?

This all seems like theoretical masturbation to avoid writing the equivalent of a struct def, once.
>no, it can't be a map of MapObjects, it has to be a map of truly generic objects

>>70916065
>didn't read it the first time
>maybe this time
kekats

>> No.70916148

>>70914003
Sure I do, but this isn't it.

>> No.70916157

>>70916125
>But why
I want to make sure that when people read the godoc they have no idea what type to send to my functions. It makes people coming from Javascript happy.

>> No.70916161

>>70916125
> why write reusable code?

>> No.70916201

>>70915545
is this really what gotards think generics are? you constrain the type arguments to a member of a family of types.

>> No.70916238

>>70916161
I'm sorry but lacking a technical definition for your function is the opposite of re-usable, and as I said before, a sign of a system that isn't well thought out. I trust a type safe function enforced by the compiler more than I trust programmers to implement a generic function. And it's less ambiguous.

>> No.70916247
File: 478 KB, 367x790, A4796087-FB73-4BC5-94F7-BF11368C33DA.png [View same] [iqdb] [saucenao] [google] [report]
70916247

>>70916125
>Realistically, in what scenario do you need to be this dynamic?
This isn’t dynamic it can be done statically. The current workarounds in Go for these problems are dynamic however.
>Why not derive an interface from your own purpose of these supposed "arbitrary" objects?
I shouldn’t have to derive something the compiler can figure out. I shouldn’t have to clutter my code with redundant type details. If the function/structure is intended to be generally reusable, then it should only need to be declared once.
If you haven’t encoutered use cases for these in your work, then I don’t know what to say.

>> No.70916260

>>70916201
>you constrain the type arguments to a member of a family of types
>generic
>constrain
what you're describing is either C++ templates or Go interfaces

>> No.70916275

>>70916238
are you retarded? why do you think generic / template functions don't have definitions? you literally have no idea what the fuck you are even talking about. i have no idea why you think using generics / templates sacrifices type safety. is this what go does to a human mind?

>> No.70916298

>>70916260
No, I'm describing generics. In Java you use the extends keyword. In C# it's the colon token. In Haskell it's the => token. Nearly every language that has "generics" constrains the type parameters that can be passed to generic functions.

>> No.70916378

>>70916247
>The current workarounds in Go for these problems are dynamic however.
This is flat out not true. When you choose a dynamic solution over a static solution, that's your own choice.
This has always been discouraged in Go. Always.
Every language suffers from the same problem of bad programmers writing bad programs. That's hardly something you should tie to the language itself.

>I shouldn’t have to
All of what you said is solved by Go's standard code generator in the same way they are in other languages.
This thread is going in circles. I quit. The majority of people shitting on Go in this thread have seemingly very little knowledge of it.

>> No.70916420

>>70916378
good riddance. im sure no one is surprised that the sole go proponent on the board has very little knowledge about anything

>> No.70916452

>>70916420
>good riddance
>direct reply
Make up your mind.

>> No.70916491
File: 24 KB, 425x425, A241AD11-DE09-4866-9F66-CEFFDF60088D.jpg [View same] [iqdb] [saucenao] [google] [report]
70916491

>>70916378
>language presents two shitty solutions to an obvious problem
>it’s the programmers fault for picking either
This is some serious gaslighting, how many rupees does google pay you to post here?

>> No.70916498

>>70916452
there is nothing contradictory about that, retard. on the other hand, you said you were quitting the thread and yet here you are. could this be a case of projecting?

>> No.70916559

Go... more like No.

>> No.70916565

>>70916491
>I wish go had code generation built in
>>it does
>yeah but I wish it had code generation

>>70916498
You seemingly don't like me, but you choose to summon me. It's pretty contradictory.
>you said you were quitting the thread
I said "I quit", I don't know why you jumped to the conclusion that I'm closing the thread. I already gave the argument to that person before and they made the same mistake multiple times and I can't tell if it's on purpose or not. All things considered it's not worth discussing seriously with them. At best they understand what's being said and I gain nothing in return.

>> No.70916571

>>70914729
>no OOP
The author is a retard

>> No.70916576

>>70914729
>>70916565
>and I can't tell if it's on purpose or not
Oh I get it now.

>> No.70916579

>>70914930
Use a free list retard.

>> No.70916594

>>70914934
>Because the compiler does the generation for me.
Yes, and while waiting for the compiler to do that, you can go get a coffee and invent a new language like Go, which is what Rob Pike et al did while waiting for C++ shit to compile

>> No.70916598

>>70916420
It's best to ignore people that say they like Go or Javascript. There's really no difference between them and people that like eating their own shit.

>> No.70916614
File: 25 KB, 300x441, gopher2.png [View same] [iqdb] [saucenao] [google] [report]
70916614

>>70916579
>write your own allocator to solve a problem language's runtime was supposed to solve for you
so this is the power of gotardism

>> No.70916616

>>70916598
I mean that's just generally true for programmers.

>> No.70916622

>>70915835
>language design rejects almost all innovations from the last 30 years
So basically all languages created since Lisp? C++ templates are just a shitty implementation of 20% of syntactic macros.

>> No.70916643

>>70916622
Almost all of the recent innovations in language design revolve around static type systems since basically everyone with a clue now agrees that dynamic typing is retarded.

>> No.70916648

>>70916622
lisp macros are fire but thats not a valid comparison. templates are entirely just about fucking with the type system, lisp macros let you operate on actual lisp code. c++ is not homoiconic

>> No.70916654

>>70916614
>importing a library and calling a method is the same as writing your own allocator.
Okay buddy, I guess that's the mindset that C++ devs have since the stdlib is dogshit.

>> No.70916680

>>70916654
It probably has more to do with the fact that dependency management isn't part of the spec.
>BUILD.MD I hope you're on the same distro as me and nobody has renamed libx since 2005 when I originally published this

>> No.70916681

>>70916643
But Lisp can be statically typed, and there are implementations that do that (SBCL, Racket, etc.)

>> No.70916683 [DELETED] 

>>70914003
> don't they want something that can replace C++?
I theoretically want a future version of Scala 3 or something like that to replace C++, yes.

I don't see it happening, and certainly the much weaker Go doesn't have a shot any time soon.

Look, there's something odd about those "Go replaces everything" fanboy claims when the main thing Go has pretty successfully been used for making a CLI [kubernetes, gopass, docker] - essentially as a shell script alternative.

>> No.70916686

>>70916654
>c++ devs ever think about having to wrestle with their shitty garbage collector
lmao

>> No.70916711

>>70914003
> don't they want something that can replace C++?
I theoretically want a future version of Scala 3 or something like that to replace C++, yes. I don't see it happening, and certainly the much weaker Go doesn't have a shot any time soon.

Look, there's something odd about those "Go replaces everything and especially C/C++" fanboy claims when almost the only thing Go been successfully used for was making a CLI [kubernetes, gopass, docker]. It is essentially only "proven" okay as a shell script alternative.

>> No.70916779

>>70915835
>no overloaded operators
in what world is this a con? what the fuck

>> No.70916810

>>70916779
I fucking wish TypeScript had operator overloading...

>> No.70916814

>>70916779
lmfao, you seriously can't imagine any worldly possibilities for why it might be beneficial to overload an operator?

>> No.70916828

>>70916814
literally no. just write the extra line, and save your future self and whoever else is reading your code your smart ass attempt to scream "i'm so smart"

>> No.70916848

>>70916711
A managed language will never be capable of replacing C++ in its niche of performance constrained applications. The only reason C++ is still used is because every language since has concerned itself with abstractions without sufficient performance control.

>>70916779
Operator overloading is essential for implementing ADTs naturally, especially when they represent numeric and geometric objects.

>> No.70916868

>>70916848
nah dude you are being a smart ass. anyone who wants to add two vectors together with the addition operator is just being a smart ass for the sake of it.

>> No.70916870

>>70916848
>Operator overloading is essential for implementing ADTs naturally
no it isn't, you are able to do that, just in a few lines more of code. How long does it take to write a few extra lines? what is the percentage of a projects total time invested to time spent writing code? clarity is way beyond that in terms of benefit

>> No.70916880

>>70916868
you are being unclear, you are being unsafe, all because you are lazy and can't write a few more lines of code

>> No.70916886

>>70916870
proper usage of operator overloading is more clear than not.

>> No.70916888

>>70916828
would you really use verbose method names for vectors like addVector instead of overloading + operator.

so why then basic types can have operator support and user-defined ones can't?

>> No.70916907

>>70916880
okay, you are fucking with me

>> No.70916931

>>70916880
>differance is only in syntax
>unsafe

>> No.70916936

>>70916848
>A managed language will never be capable of replacing C++ in its niche of performance constrained application.
http://www.scala-native.org and such

But unlike some Go users, I'm not saying it is ready to replace C++ (nor is the Dotty-based Scala3 even out yet). I only wish it was.

>> No.70916983

>>70916886
>proper usage of operator overloading is more clear than not.
This is how bad your sentence is
>if someone implements something the way I expect, it's more clear to me
The obvious problem being that what you think is clear and what the implementer think is clear is not always going to be the same. With alternatives, it's equally as clear, you just read the definition that all of them conform to in plain English.
>I don't want concatinate(a,b), I NEED a+b

>> No.70917002

>>70916936
but it never will

>> No.70917071

>>70916983
why would you need "" concatinate(a,b)"" when you could use + lmao
if you use operators for arcane stuff and don't document it it's your fault.
do you also write int b = parentheses(int(5).add(4).substract(7)).multiply(8) ? are you a pajeet Java developer?

>> No.70917091

>>70917071
You're being absurd on purpose.

>> No.70917095

>>70916983
you are just repeating dogmatic bullshit about operator overloading. if someone defines a vector type and overloads the addition operator for other vectors, guess what? thats more clear than having a function 'vector_add' or whatever because the conventional notation is to write 'v1 + v2' everywhere in the world. if you dont overload the operator, users of the library will have to start digging for the name and signature of the function which implements vector addition. thats because the conventional notation is to just write 'v1 + v2', and not pretend you are using some cumbersome and inferior programming language.

>> No.70917111

>>70917071
>are you a pajeet Java developer
i've noticed this is the usual attack of programmers who haven't written enough code and can't see the advantage of concatanate(a,b)

>> No.70917140

>>70917095
> users of the library will have to start digging for the name and signature of the function which implements vector addition
come on, you are just being obtuse at this point. What makes you think that doing v1 + v2 isn't different? they'd have to go dig in the source or documentation all the same, because user made libraries might have different ideas about the implementation of said operator. Sure, v1 + v2 is the example you always give but we both know this ain't the only thing the feature is used for and some real abominations can be created

>> No.70917147

I came to this thread looking for valid reasons for not using Go, but only saw responses that are literally just
>
meme responses

>> No.70917198
File: 11 KB, 224x224, 0BD71DB0-E3CD-49B0-8A47-39F302370DDD.jpg [View same] [iqdb] [saucenao] [google] [report]
70917198

>>70917111
I’ve noticed this the usual reply of programmers who haven’t moved beyond Java and can’t see the advantage of a ++ b

>> No.70917206

>>70917140
Everyone with a brain and a modern programming language will expect vector addition to be defined for the + operator being applied to two vectors.

your comment about how operator overloading can be abused is absolutely retarded. people can misname functions and create obfuscated functions, too, so ban those while you are at it lmao. your idea of the perfect programming language is one that has zero abstractions, and you can't write anything with it. sure its useless, but you can't make any mistakes with it! lmfao.

>> No.70917230

>>70917198
a ++ b has shit readability. it might clear in the cae of concatenate but for other operations opeator overloading is retarded and detrimental to understandability of a large codebase. Which you'd know if you had worked on one, which you haven't, clearly.

>> No.70917263

>>70917206
this is exactly the problem with C++. the people who are working on it are like kids in a candy store, adding shitloads of features which have marginal utility and large potential of implosion that don't advance software as a whole, creating the clusterfuck abomination lang we have today.
think of how better software would be today if people just shutted the fuck up and wrote in C for the past 30 years instead of creating new languages every 2 seconds

>> No.70917267

>>70917230
lmfao imagine your colleagues are all incompetent retards who abuse operator overloading and write shit code because you are a retard and you work on a retard farm, and then you go on the internet and talk down to people about it

>> No.70917290

>>70917147
maybe you'll learn to disregard all the /g/ memes propagated by NEET retards and try shit out for yourself. if you like it - great, if not, then not

>> No.70917333

>>70917267
I work at Palantir, suck my dick

>> No.70917351

>>70917263
This but replace C with Lisp.

>> No.70917353

>>70917002
Probably not. It only mostly killed C++ as the chosen approach for distributed parallel computing, saving us another decade with MPI and worse.

OTOH various LLVM hosted projects might start to create the same situation as happened on the JVM. More interoperable language choices.

>> No.70917355

>>70917333
lol

>> No.70917361

>>70917333
sorry, this means nothing to me. no hate though.

>> No.70917369

>>70917230
>opeator overloading is retarded and detrimental to understandability of a large codebase
It should never exist. + or ++ always should be a method. Maybe with bracketless syntax (which implies a single parameter), but it should just ALWAYS be a method.

Making operators special sucks balls.

>> No.70917371

>>70917290
this. people here seem to have lots of trouble forming their own opinions

>> No.70917381

>>70917371
really? 90% of the time it is people mouthing off about their opinions. only rarely does some air head wander in asking to be told what to do

>> No.70917398

>>70917111
there is no advantage of that over using operator overloads.
even pajeets realized that and wrote a hack for Strings to use + for their StringBuilder(tm)

>> No.70917422
File: 316 KB, 560x560, 5551FB0E-0FB8-431C-93B0-21AA4F1FC788.jpg [View same] [iqdb] [saucenao] [google] [report]
70917422

>>70917369
>standard mathematical notation is bad
This is your brain on Java

>> No.70917431

>>70914124
go needs type? for null and type! for errors (like rust's result<T> type).

>> No.70917441

>>70917369
Operators are just infix functions though.

>> No.70917444

>>70917422
Learn Ruby, my dude
In ruby a + b is equivalent to a.+(b) - i.e., it's a call to a method named "+" on the "a" object, with "b" as the argument

>> No.70917450
File: 57 KB, 730x398, 8B99F17C-684F-46C5-BEA1-D6A3C42EFD67.jpg [View same] [iqdb] [saucenao] [google] [report]
70917450

>>70917431
Kek

>> No.70917469

>>70917444
ruby also has positive and negative strings

>> No.70917477

>>70917444
I prefer Haskell where adding `backticks` to any prefix function makes it infix, and adding (parens) around an infix function makes it a prefix function.

>> No.70917478

>>70917450
It could be build into the language if they don't want to go the template route. Kotlin has a type? as well.

>> No.70917487

Go is basically just c/c++ that follows Google's internal style rules. Unfortunately, those rules suck. If there's one thing that sucks more than exceptions it's status type returns.

>> No.70917513

>>70917487
> Go is basically just c/c++
hmmmMMMMMmmmm

>> No.70917537

>>70917444
How is this clearer than just explicitly overloading +?

>> No.70917544

>>70917513
I use a slash because they clearly intended it to be an alternative to c++ but it is more similar to c.

>> No.70917572

>>70917544
>clearly intended it to be an alternative to c++
I don’t see it. Everything about it is so obviously based on C and not C++. They even formalized the C of passing struct references with their implementation of “methods”.

>> No.70917615

>>70917572
Right, I think I'm not explaining myself clearly. I get that it's based on C and it goes in a different direction than C++. But Google always wanted something more powerful than C and was previously (and most likely still is currently in many places) using C++ in a C-like way to achieve that goal. Go exists so that they have a language that they wish C++ was instead.

>> No.70917624

>ITT: pleb filtered

>> No.70917637

>>70917441
They should be infix methods same as all other infix methods, but in many languages they are not.

>> No.70917642

>>70916828
That's a nice hypothetical, but the first thing everyone learns when learning about operator overloading is that you shouldn't try to be a smartass and only do things that make sense semantically.

Ironically the only place I can think off where it is abused is the C++ standard library.

We shouldn't take away powerful tools just because retards exists.

>> No.70917662

>>70917537
You ARE explicitly overloading + if you redefine a.+(b) to mean something else.

What isn't clear is why the fuck this needs a special set of rules involving "operators".

It should just be normal methods with normal method declarations and normal method overloading rules.

>> No.70917691

>>70916828
> pos.mul(TILE_SIZE).add(velocity.mul(time))
>more clear than pos * TILE_SIZE + velocity * time
I will never get tired of seeing gotards try to argue that cluttering up your code for the sake of "explicitness" / "simplicity" is somehow a good thing

>> No.70918655

No generics and forced GC. Go can NEVER replace C++.

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
reCAPTCHA
Action