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

Due to resource constraints, /g/ and /tg/ will no longer be archived or available. Other archivers continue to archive these boards.Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 111 KB, 1634x2224, gopher.png [View same] [iqdb] [saucenao] [google] [report]
71537542 No.71537542 [Reply] [Original] [archived.moe] [rbt]

The complexity of C++ (even more complexity has been added in the new C++), and the resulting impact on productivity, is no longer justified. All the hoops that the C++ programmer had to jump through in order to use a C-compatible language make no sense anymore — they're just a waste of time and effort. Now, Go makes much more sense for the class of problems that C++ was originally intended to solve.

>> No.71537560

>>71537542
stfu retard faggot, nobody gives a fuck about your fag language for dumb fags like yourself

>> No.71537563

lol no generics

>> No.71537569

>>71537542
lol no enums

>> No.71537580

lol no sum types

>> No.71537588

lol no immutables

>> No.71537590

>>71537560
Keep crying and screaming, you can't stop it anymore c++ bootlickers

>> No.71537602

lol real memory or type safety

>> No.71537612

lol no error handling

>> No.71537664
File: 62 KB, 645x773, 1524538602457.jpg [View same] [iqdb] [saucenao] [google] [report]
71537664

>>71537563
>>71537569
>>71537580
>>71537588
>>71537602
>>71537612
lol samefag

>> No.71537679

>>71537542
Brainlet opinion from a brainlet language user.

>> No.71537688

lol empty interfaces

>> No.71537697

>>71537590
SEETHING

>> No.71537703
File: 208 KB, 720x1520, Screenshot_2019-06-22-16-14-28-473_acr.browser.lightning.jpg [View same] [iqdb] [saucenao] [google] [report]
71537703

>>71537664
Good job, retard.

>> No.71537709

>>71537542
Go is C for retards

>> No.71537733

>>71537709
Go is incapable of doing what C is used for. Its role is closer to Python and other one-step-above-scripting languages.

>> No.71537743

>>71537542
lol no namespaces

>> No.71537759

>>71537590
Well, pedo trannies do kill themselves in quite high proportions to other mentally diseased pedos, so I guess its a sit and wait.

>> No.71537804

>>71537542
lol no file scope

>> No.71537816

lol no iterators

>> No.71537825

lol regex is slower than in Python

>> No.71537857
File: 87 KB, 645x773, 1512819759856.png [View same] [iqdb] [saucenao] [google] [report]
71537857

>>71537825
>>71537816
>>71537804
>>71537743
>>71537709
BJARNE WAAAAAAAAAAAH SOMEONE IS SAYING BAD THINGS ABOUT CPP

>> No.71538723

>all the hoops
extern "C" {
//c code
}


????????????????????

>> No.71539943

>>71537542
>The complexity of C++ (even more complexity has been added in the new C++), and the resulting impact on productivity, is no longer justified
[Citation Needed]

There is plenty of C++ development happening right now, and they aren't complaining

>> No.71540781

>>71537542
Go is corrupted by google Wirth's Oberon.

>> No.71541020

>>71537542
Shill harder google kyke. Fuck both languages. Python master race.

>> No.71541266

>>71537542

Go is pretty much made by a bunch of old guys who are stuck in their ways but finally got tired of having to fuck around with memory.

Not the worst but can't replace C cuz GC.

Rust is a better C++ replacement. It still has complexity but you get a bit more value for that complexity.

Rust is still too hard tho. Still waiting for someone to make low level shit easier without performance hits or C++ tier complexity.

>> No.71541426

Also python lol. Its one of the worst languages by far. Only straight retards write it because uni forces them to learn it.

Every python program I interact with feels janky.

>> No.71541599

>>71537542
No generics.

>> No.71541751

For those who like Go but miss generics and better error handling, V will see its first release later today:

https://vlang.io/docs
https://github.com/vlang/v

Similar to Go, but with a couple of important extra features and no GC which means it can be used for high performance tasks.

Has a native compiler but also compiles to C, which allows it to make full use of the advanced optimizations in toolchains like GCC and Clang/LLVM.

>> No.71542261

>>71541751
ziglang does error handling better than V

>> No.71543072

>>71537542
> Impact on productivity
Brainlet detected, if you had any brain in there you'd know golang performes worse than c++
You literally can't use golang for performant tasks, it's twice as slow
C++ is literally the most shittalked language because brainlets can't use their brains to fucking use it
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html

>> No.71543304

>>71537542
Nice shitposting.

>> No.71544215

interface Iterable {
[Symbol.iterator]: () => any
}

function iterate(iterable: Iterable) {
for (let i of iterable) console.log(i)
}

const arr = ['a', 'b', 'c']
iterate(arr)

How come TypeScript can guarantee the received parameter is an array without resorting to generics, but Go can't do the check during compile time?

>> No.71544241

>>71544215
gradual typing
you could have an iterable interface in go but what would it iterate over?

>> No.71544302

>>71537542
shove your garbage collector up your ass

>> No.71544454

>>71544241
A slice you need to sort.

>> No.71545932

>>71544215
One of the goals of Go's development was to keep compile times down, hence the lack of compile time generics. (I think)
Concerning performance Go was meant to replace C/C++ for webservers, where the prime limiting factor is I/O and thread locking, not raw real time performance.

>> No.71547655

>>71545932
compile time generics can be implemented with minimal effect on compilation time. Faster than compiling multiple functions that take different types but do the same task.

>> No.71549018

>>71537542
Finally cracked open Donovan & Kernighan today. Feels comfy man

>> No.71549082
File: 4 KB, 180x146, unknown-11.png [View same] [iqdb] [saucenao] [google] [report]
71549082

>>71541751
>>71542261

>> No.71549466

>>71537542

No. C++ has been originally designed by a demagogue and idiot, without studying anything about programming.

This is why the type system is such an unsound abomination.

Now they are claiming that backward compatibility with C was the main concern but in reality he was just an incompetent bullshitter and narcissistic snowflake.

No amount of changes could fix what is deeply flawed in principle.

Go broke the compatibility and fixed all the major flaws. Go is decent, well-researched, small set of complimentary features. It just works and smart people just got their shit done.

C++ is the constant struggle with inherited idiocy of the past.

/thread

>> No.71549480

>>71541266
You can still write simple Rust and do wonders with it.

>> No.71549725

>when i'm alone, i cry at night because c++ and rust (languages i consider trannylangs) have generics and golang does not...
the hard life of a go programmer

>> No.71549760

just don't use the latest standard lmao

>> No.71549771

>>71549466
Unsound? Can you elaborate?

>> No.71549779

>>71537542
Golang is dead.

t. Sundar Pichai

>> No.71550116

>>71537542
>The complexity of C++ (even more complexity has been added in the new C++)
t. literal retard

C++11 and onward is actually simpler than before.

>> No.71550125

>>71549725
>implying you need them
just design your interfaces properly poojeet

>> No.71550233

>>71549771

implicit coersions

also ints are not objects, etc.

>> No.71550235

>>71550125
wtf i love golang now
thank you, anon

>> No.71550881

>>71547655
>compile time generics can be implemented with minimal effect on compilation time. Faster than compiling multiple functions that take different types but do the same task.
?

>> No.71550914

>>71550125
Java had interfaces but it still needed generics dumbfuck

>> No.71550931

>>71550233
Neither of those have anything to do with soundness retard.

>> No.71550940

>>71550881
What part of this do you not understand?

>> No.71550941

>>71537542
Parallelism.
Simple.
Good when C not necessary.
Rob Pike - plan9.

imagine needing generics lul.

>> No.71550974

>>71550941
>can't even tell parallelism from concurrency

the absolute state of Go devs

>> No.71551969

>>71537542
Google shill

>> No.71552657

>>71550931

just fuck off

implicit coersions have everything to do with unsoundness. it does not even amount to strong typing, leave alone soundness, which means proof-like guarantees.

fuck you Ivan. don't try to look smart, fucking nigger

>> No.71552683

>>71552657
no u

>> No.71553285

>>71550940
The way generics are implemented at compile time is literally by compiling multiple functions for each type. It's impossible to be faster than compiling multiple functions by definition.

>> No.71553476

>>71541751
The solution to this kind of problem is not yet another programming language than misses most of the commonly used libraries.
The solution most likely lies between OS and userspace.

>> No.71553899

>>71550116
Simpler would mean having less features, which C++11 does not. I mean, C++ grammar is so convoluted it's undecidable. Yet it still has no idiomatic interface definition, thus making OOP more of a shore than anything.

>> No.71554933

Too many butthurt faggots in this thread. Go just works.

> muh generics

Stop relying on then or write your own. Plenty of libraries are available.


> muh immutable

const doesn't allow for variable change

> garbage collection

It's nice not needing to worry about memory when on deadline. Faggots and NEETs won't understand.

> error handling

Literally three lines are needed to write an error handling function and can be automated with snippets if you actually know how to use your text editor.

Go is the future.

>> No.71555069
File: 15 KB, 200x226, DIqsaH1V4AASXcV.jpg [View same] [iqdb] [saucenao] [google] [report]
71555069

>>71544302
found a guy without a job :)

>> No.71555758

>>71549480

I can and I do. C++ is an abomination so no real choices but C or Rust.

That said, if I sit down and try to write stuff in the most performant way possible or am dealing with an inherently complex problem domain. I'm going to end up with 4 lifetimes and 6 trait bounds on a function. Throw some concurrency, weird memory allocation, or macros into the mix and the level of complexity is getting up there. I can put it all behind a type alias but that is really just hiding the problem.

Also tokio is one of the worst async frameworks by far and unfortunately a lot of the rust ecosystem is reliant on it. Guy who made it came over from java and pretty much grabbed some of the worst ideas from java frp frameworks and threw lifetimes on top of it. I'll write out a future in the most compact way possible and the shit still looks nuts. That said if you are using higher level frameworks built on top of if, you won't feel most of that pain.

Still I can't help but feel there's gotta be a better way to do a lot of this shit.

>> No.71555791

>>71554933
<empty line>
hello
<empty line>
reddo

>> No.71556604

>>71554933
> Stop relying on then or write your own

If the only option to create generic data structures is code generation or rewriting it for every new data type, in a language made in the 21st century, it's a sign of a bad language.

> const doesn't allow for variable change

Struct types can't be const, only primitives.

>Literally three lines are needed to write an error handling function and can be automated with snippets if you actually know how to use your text editor.

Once again, the fact that you basically rely on code generation for basic language features that other languages solved decades ago is the sign of a bad language

Go is retarded

>> No.71556794

>>71553285
That's only one possible implementation. It's not even a popular one, the only languages I can think of which have this baked into the semantics are Rust and C++.

>> No.71558304

>>71556604
>Go is retarded

Go is comfy. What would you use instead?

"Anything else" is not a good answer.

>> No.71558785

>>71558304
C++/Rust

>> No.71559402

>>71558785

C is far superior to both.

>> No.71559766

>>71559402
for brainlets perhaps

>> No.71560284

>>71537563
void* and memcpy

>> No.71560344

>>71560284
>I don't understand what generics are

>> No.71560421

>>71560344
>I understand perfectly what generics are and implement them without the aid of a typechecker using functions already available to me.
ftfy

>> No.71560434

>>71560421
generics are a feature of the type system you retard, if the type checker isn't involved then it isn't generics.

>> No.71560493

>>71560434
>storing arbitrary data irrespective of type
>not generic
hmmmm.

>> No.71560501

>>71541266
>Rust is a better C++ replacement
no it's not

>> No.71560508

>>71560421
The only way to implement generics in C is by heavy macro usage. Every other approach requires some sort of discriminated union, which is polymorphic but not generic because you need to write out the specific code for operations on each type explicitly.

>> No.71560527

>>71560493
Generics has a specific meaning in PLT. To be specific it's a layman's term for parameteric polymorphism. Something isn't generic in the programming sense just because it's generic in the casual sense.

>> No.71560570

>>71560493
Generics are about generic operations on data, not there storage. Generics mean you can use the same operator or function to add two integers, or floats, or intervals, or complex numbers, or whatever user defined type you need.

>> No.71560577

>>71560527
>parameteric polymorphism
the parameters are void* and size_t

>> No.71560607

>>71560577
How do you know what the type of the object pointed to by void* is?

>> No.71560663

>>71560577
the parameters are type parameters you absolute dumbass. if the parameters aren't types it's not parametric polymorphism
is this what C does to people?

>> No.71560732

>>71560607
you don't need to. You only need to know how big it is for moving it in and out of memory locations.
If you want to use functions on stuff, wrap the function in another that takes pointers instead.
void apply(void* a, void* b, void (*fn)(void*, void*)){
fn(a, b);
}

void set (int* x, int* y){
*y = *x;
}

int main (void){
int a = 9, b;


apply(&a, &b, set);
assert(a == b);
}

>> No.71560764

>>71560607
in my example, apply only has a rough idea of the data it is applying a function to. The rest of the type information is filled in by set. You could extend this to work over larger widths of void* to implement "generic" dynamic arrays in C.

>> No.71560772

>>71560732
Ok so, for setting ints I need one function, but I would also need a function for setting floats, or cstrings, or different types of structs.
If I need to provide the operation definition for each type then how can you call it generic?

>> No.71560783

>>71560663
but it's polymorphism and it has parameters. What's so hard to understand?

>> No.71560785

>>71560732
>>71560764
Following all of these void pointers is horrific for performance btw. You are essentially creating a bunch of vtables which the compiler cannot optimize away.

>> No.71560795
File: 87 KB, 853x621, uriel1.png [View same] [iqdb] [saucenao] [google] [report]
71560795

>>71537542
>muh gomblexity

>> No.71560826

>>71560772
>how can you call it generic
Because a data structure taking this approach (void* with number of bytes allocated) can store any as just different width areas of bytes. The code for wrapping your actual function in another function can be taken care of with macros and only needs to be done temporarily where you use them on that data structure.

>> No.71560842

>>71560785
>vtables
isn't this what muh generics use for dispatching method calls anyways?

>> No.71560875

>>71549082
That's stupid.

>> No.71560876

>>71560783
What's so hard for you to understand that certain terminology has well defined meaning in its respective context beyond just combining unspecific component terms?

>>71560842
Depends on the particular implementation.

>> No.71560980

>>71560876
>well defined term
>but no, not this way of defining generic implementations of datatypes and functions, that's wrong because the compiler needs to do it for you.

>> No.71561071

>>71560842
Generics as in C++ templates use compile-time monomorphism, generics as in C++ inheritance use dynamic dispatch through vtables.

>> No.71561084

>>71560980
You still don't get it do you? It's not about being "generic" in any vague or imprecisely defined sense of the word. It's about one specific feature which everyone who discusses programming language design understands the terms generics and parametric polymorphism denote.

>> No.71561102

>>71560826
Seems like a huge amount of effort for no reason. It would be much faster just to copy paste the code and change the types than jump through all of those hoops for no reason.

>> No.71561116

>>71561084
>muh terminology
lel

>> No.71561141

>>71561116
Believe it or not, you have to understand what the words you use mean in order to add to a discussion. Otherwise you talk shit and contribute nothing.

>> No.71561149
File: 61 KB, 812x1024, 897A419B-584B-4E8C-9748-739FA6D74FA4.jpg [View same] [iqdb] [saucenao] [google] [report]
71561149

>>71561116

>> No.71561178

>>71561141
>/g/ is serious business
You're right anon. I'm sorry.

>> No.71561181

>>71561102
That would appear faster and simpler at first.
However when you actually make a program that has to be maintained, improved etc. you will find that it's actually less than ideal and becomes a spaghetti nightmare.

>> No.71561271

>>71561181
I doubt it. Pointer chasing is way worse for maintainability than redundancy in my experience.
The example still requires defining a set function for each type, which hardly qualifies as generic. In a generic function I should be able to write a single set functions which is capable of overloading a plus-equals operator or method to do what I want for that type, without me needing to know anything about the type beyond it supporting a few operations.

>> No.71561452

>>71561271
#define addEquals(x, y)\
_Generic(x,\
int: x+y,\
myType: somefunction,\
...

>> No.71561486

>>71561452
closed type switches aren't generics either chump

>> No.71561579

>>71561486
>_Generic
>not generic

>> No.71561592

>>71561579
We've been discussing this all thread.

>> No.71561609

>>71561592
Generics are bad anyway. Operator overloading obfuscates the meaning of code.

>> No.71561662

>>71561609
Operator 'overloading' should only be allowed in certain contexts, like with haskell typeclasses

>> No.71561696

>>71561609
ah yes, because intvec3add(x, intvec3mul(y, 9)) is so much clearer than x + y * 9

Your C compiler already overloads int addition, float addition and pointer arithmetic. You don't dislike operator overloading, you just dislike it when it stops being compiler magic.

>> No.71561763

>>71561696
>names with types in are less clear than operators with no additional information.
k

>> No.71561784

>>71537542
>even more complexity has been added in the new C++
Nobody is forcing you to use it, you know?

>> No.71561785

>>71561763
>I don't understand abstraction

>> No.71561802

>>71561785
>>I don't understand needless obfuscation

>> No.71561824

>>71561802
guess C is obfuscated because I can't tell whether x + y is adding ints or floats :/

>> No.71561834

>>71561824
that's why you use casts brainlet

>> No.71561850

>>71561834
on every single arithmetic operation?

>> No.71561882

>>71560508
>heavy macro usage
No different than templated types.

>> No.71561893

>>71561850
yes

>> No.71561948

>>71561882
Wrong for a host of reasons.
>automatic name mangling
>inference
>inline (automatically applied to implicitly instantiated templates) has a different and more useful meaning in C++
>hygienic
Templates are much better suited to the purpose of code generation than macros.

>> No.71561967

>>71561948
just use macros to mangle the names bruh

>> No.71562287

>>71559766

You must be retarded.

>> No.71562330

Everyone shitting on Go.

OK, geniuses. What is a better general-purpose alternative that isn't Rust or C++, both of which are garbage, and you all know it.

>> No.71562417

>>71562330
haskell

>> No.71562431

>>71562330
Jai

>> No.71562538

>>71562417

only debt-ridden researchers and NEETs use haskell.

C is all you need.

>> No.71562548

>>71562431

Pajeet languages don't count.

>> No.71562708

>>71537542
>The complexity of C++ (even more complexity has been added in the new C++)

If you don't want to use new C++ features, do not use them you fucking retard idiot.

>> No.71562761

>>71537542
0 out of 10 larp, pedo tranny.

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