>>108612743
if T exends numbers why no just do

Number array[100]

?

>>108612743
Go java deez nuts

>>108612776
ha, got 'im!!

>>108612743

local array = {}
array[1] = 'nigger'
print(array[0.5+0.5])

this is not an issue in common lisp.

>>108612743
in haskell it's just []

File: 1773901945868897.jpg (583.2 KB)

583.2 KB JPG

none. arrays in runtimes are sets of pointers to arbitrary var types, there is no point to apply this tinkertroonerism.

the better way for the runtime is to.. is to ask /opensourceclub/ at telegram, if you want to know.

>>108612743

array(Positive range <>) of Number

go generics are complete shit on purpose because the developers didn't want to add them but people wouldn't stop begging for them

>>108612767
Because number is an interface and to store and use it, you need to store the vtable and runtime information about what type it is.

>>108613557
doesn't make sense.

File: Picture_2_c.jpg (4.9 KB)

4.9 KB JPG

>>108612932
truly epic bait

File: golang_genesis.jpg (38.6 KB)

38.6 KB JPG

>>108613619

>>108612932
did you know that gotard devs spent years selling lack of generics as a "muh simplicity feature", which made them the butt of jokes over that period. then they said: okay, let's consult some real experts on this, javatards. lol. needless to say, that made them the butt of even bigger jokes since they somehow managed to tard-maxx further.
still, go is the less retarded of the two, which is still not an achievement. it could have been possible to argue that it's even good, in a world where this false dichotomy... wasn't false.
oh, and btw, YWNAA (you were never an aryan).
hope that helps

D's way: f(T)(T x)

>>108612948
>>108613511
>>108612805
absolute retards

File: hn_go.png (6.5 KB)

6.5 KB PNG

>>108613692
>gotard devs spent years selling lack of generics as a "muh simplicity feature"

>>108613692
your favourite language doesn't even have channels

>>108612743
Java til the day I die cuh
Oracle for lyfe cuh

>>108613781
>thinks it knows my favourite language
>thinks "channels" must be a language level feature
YWNAA

>>108613830
>>thinks "channels" must be a language level feature

how do you structure multiple locks in the same block without a loop then?

>>108613849
>it thinks whatever shitty abstraction the only language it knows offers is some incarnation of maximum human possibility
lol YWNAA

>>108612743
[] denotes array indexing
<> denotes type level argument
Array<T> is an array of T elements
Array[N] is an array of length N

>>108613917
how would you implement it as an api?

>>108613977
You can also pass constant variables into generics though, i.e. Array<N>

>>108614132
provide a concrete example use-case. describe functionality requirements without any assumed implementation details.

>>108613532
its extremely disappointing they're adding this shit to the language in a decade go will be as unreadable as java

>>108614245
why are you arguing about golang channel system if you don't know anything?

>>108612743
go is a bizarre way to illustrate []

>>108612948
they need some cocks

>>108614274
>why are you trashing the half-baked half-broken abstraction in the only language i know
>no, i will not provide specifics

>>108613830
channel ops, selection and goroutines are best as a language-level feature

someFunc :: Num a => [a] -> b

Alternatively, if this is a common pattern, you can just give it a name using GADTs

data AnyNum where
    AnyNum :: Num a => a -> AnyNum

Now you can use [AnyNum]. No muss no fuss.

>>108616568
noisy

>>108613692
but finally, it got troonified, hehehe

committee designs all end like that, it pushes absolute language slop into a compiler or runtime which becomes extremely bloated. why? because some trooner group of activists make an illusion of "public wants", "public needs", in fact, all those public likes are automated psyop, no different to those likes on github. slop in slop out

>>108616594
How do you mean?

>>108612743
It doesn't fucking matter.

>>108612743
It doesn't really matter if you use square brackets or diamond but CLU invented parameterized types and it was with brackets. Java used diamond to avoid syntax problems with arrays.

>>108613849
He's a dick, but he's also kind of right even if he's unhelpful about it. Can you tell me what you mean by "structure multiple locks in the same block without a loop"? Like, show me a small piece of Go code demonstrating what you mean.
I'm vaguely aware of how Go's channels work because I've used Limbo.

>>108616730
> CLU and Ada were major inspirations for C++ templates.[5]
> Two distinct characters, each from Tron[citation needed] and Tron: Legacy[citation needed] respectively, are named after CLU.

tronified, hehehe

>>108616678
an n-ary function signature requires n "->"s plus one "=>". i understand it comes from conceptualizing function application as chained partial applications of unary functions, but not providing a more compact way to write that is mental masturbation. i also hate double-colons.

>>108616786
underage b&

>>108612743
Definitely the gopher for me, but a java is okay too

>>108616773
The select statement allow to block on multiple channels in one structured block. The first channel to be ready will do the unblock. It would be tricky and tedious to implement that in api

>>108616831
plan 9 has a C function for it, called "alt" instead of "select"
https://man.cat-v.org/plan_9/2/thread

certainly more cumbersome than just having language support for it

>>108616475
provide an illustrating example

>>108616730
>CLU invented parameterized types
System F did. CLU invented a heavily restricted idea of constrained parameterized types, though.

>>108616773
>>108616814
>>108616831

here an example found on Google (I am no go programmer).

select {
        case msg1 := <-c1:
            fmt.Println("received", msg1)
        case msg2 := <-c2:
            fmt.Println("received", msg2)
        }

This structured block[1] will lock and wait on two channels: c1 and c2. The first channel to be ready will unlock the structured block which will then continue at the right place.

[1] https://en.wikipedia.org/wiki/Block_(programming)

>>108613760
> it’s impossible for me to write code without generics
> i build new generic versions of number types on every project I contribute code to
> never been employed, never will

>>108612743

template <typename T, typename Enable = void>
class Array;

template <typename T>
class Array<T, typename std::enable_if<std::is_arithmetic<T>::value>::type> {
    T data[100];
};

Behold the power of the C++ committee. (This kind of shit actually gets shipped, btw)

>>108616831
>muh select is impossible to implement outside the language
>what is "man 2 poll" :D
>>108616853
also "man 2 poll"

>>108616945
Most types are abstract types like array, list, hash table, ... Only a fool and certainly not a programmer would accept to waste his time by defining types manually like array_float32, list_entity, ... when the compiler can handle that for us.

in V:

// goroutine 1: generate ticks at precise intervals
    for {
        select {
        _ := <-cancel    {break}
        ms * time.millisecond {tickch <- 1}
        }
    }
}

// goroutine 2: send icmp echo requests
    mut pk := [u8(8),0,0,0,0,0,0,1,0,0,0,0,0,0,0,0]
    for {
        select {
        _ := <-cancel {break}
        _ := <-tickch {
            pk[2] = 0; pk[3] = 0;    // clear checksum
            t := time.sys_mono_now()
            bin.big_endian_put_u64_at(mut pk, t, 8)
            bin.big_endian_put_u16_at(mut pk, cksum(pk), 2)
            s.write_to(a, pk)!
        }
        }
    }

// goroutine 3: receive icmp echo replies
    for {
        select {
        _ := <-cancel {break}
        else {}
        }
        s.wait_for_read() or {eprintln("timed out"); continue}
        t := time.sys_mono_now()        
        n, _ := s.read(mut &buf)!
        hdrlen := 4*(buf[0]&0x0f)
        printch <- Reply{bin.big_endian_u64_at(buf, hdrlen+8), t}
    }

// main: print replies as they come in
        for {
            select {
            _ := <-cancel {break}
            s := <-printch {
                // etc
            }
            }
        }

>>108616993
it doesn't seem like you know what channels and goroutines are

>>108616902
>>108616975
>>108617010
What the fuck am I reading?

>>108616945
a good generics system just gives you shit for free

>>108617010
Meant as a response to
>>108616861

>>108617027
As for the middle post, that's SFINAE. Basically, C++ templates are so fucked up, you can actually use them to do metaprogramming and type constraints.
The bad part is that the compiler has no idea what you're trying to do so if you do anything wrong, the error messages are beyond incomprehensible, it slows compilation to a crawl and the syntax is so ass-backwards that it makes you want to kill yourself.

Which means, you can't tell it apart from the parts of C++ that were actually intentionally designed.

>>108617024
provide a concrete example use-case. describe functionality requirements without any assumed implementation details.

>>108617048
>>108617010

>>108616814
>an n-ary function signature requires n "->"s plus one "=>"
>but not providing a more compact way to write that is mental masturbation.
Not at all. An n-ary function takes an n-tuple.

someFunc :: (a, b, c) -> d

In most cases n-ary functions overlap in behavior with curried functions with n constructions, but a curried function isn't really n-arity and it doesn't behave that way. There's a small amount of syntax sugar to make it easier to write curried functions because point-free style is important for functional programming, but even the syntax sugar doesn't elide the two. I can't blame you for not knowing this though, many Haskellers aren't well versed enough in the runtime to know when to use a real n-ary function, so they just always stick to the normative "everything is curried" paradigm.
>plus one "=>"
No more noisy than <> or [] imo. Also unlike the two others, you can also completely do away with it if the type constraint is expressed in a GADT. Afaik, you can't alias a typeclass like that in Go or Julia? I might be wrong on that.

>>108617048
nta but teledildonics

>>108617058
good enough

>>108613760
most accurate reddit comment I've ever seen. it's pretty obvious Go is just half-assed and the half-assery being sold as "simplicity."

>>108613743
yeah, I prefer it, less visual noise to have stray '!' instead of angle brackets

>>108617042
many languages manage to do this without shoving it into the language (which forces one implementation onto you, but you already lost if a runtime is already shoved anyway).
this functionality exists at the syscall level. so you can wrap it in any language anyway.
if it wasn't for the full lack of low-level knowledge, some people would have picked on that already.

>>108617087
rewrite the V in C

>>108616475
no they aren't. they're unreadable and can panic (send to hung up channel) or block forever (recv from hung up channel).

>>108617096
what does the code do?
(you can also provide that description to your favorite LLM, and should spit out working code for you. it's not as challenging as you seem to think.)

File: r_78064_8ZNye-2020157682.jpg (74.2 KB)

74.2 KB JPG

>>108612743
fuck java. anyone who is an enjoyer has never shipped fucking anything in their life. with go you get a nice native binary. with java you have to send a fucking xml to configure the jvm to not suck dick and you have to install the jvm on any desktop or server that uses it. people thing javascript is bloated... java requires gigs of jvm just to run a hello world.

>>108617087
Try to do the same as go channels with poll() and with type safety. You will see how more tedious it is.

>>108617097
>if i write incorrect code, my program behaves incorrectly
damning, absolutely damning

>>108617138
>pub fn send(&self, t: T) -> Result<(), SendError<T>>
>Result<(), SendError<T>>
I know this is a foreign concept to gotards, but panicing is full retard.

>>108617125
It fires off pings on one thread while reading responses on another. Ironically, a situation where select(2) or epoll is well suited.

>>108617151
rust is a poorer language for having channel ops removed from its syntax many years ago

>>108617163
no, it really isn't. there is no reason for the retarded syntax and implementing channels requires a runtime that has to be specified, which rust can't guarantee on no_std.

>>108617170
if rust still had channel syntax, you would think that was great

>>108616902
>>108616831
It's just an monad interface, really. Haskell has TChan for this particular usecase of channels.

do
    msg <- atomically $ 
        (Left  <$> readTChan c1) `orElse` 
        (Right <$> readTChan c2)
    
    case msg of
        Left   msg1 -> putStrLn $ "Got: " ++ msg1
        Right  msg2 -> putStrLn $ "Got: " ++ msg2

With c1 and c2 both as type TChan String
Of course, you won't really be able to use Either if you have more than 1 channel, but I just wanted to match the style using a pattern match.

>>108616886
System Fakup! hehehe

nice features there, Trontards

>>108617007
> nocoder unable to implement ArrayFloat32

capitano obviouso

>>108617200
no, I wouldn't. there is zero objective reason to bloat up syntax with something that can be represented as a function call.

>>108617170
are you the kind of retard who defends shit like operator<< operator>> for iostreams?

>>108617219
putting the concept of goroutines and channels into the language allows very fast channel operations
moreover,
>rustard accusing any other language of having bloated syntax

>>108617245
and yet go channels are slower than std::sync::mpsc. curious.

>>108617224
its just like my bash scripting :3

>>108617245
>putting the concept of goroutines and channels into the language allows very fast channel operations
relative to the complexity of the compiler
it does limit what kind of channel paradigms you can use though

>>108617245
provide a concrete example where you think go performs faster (than let's say rust) because of this.

>>108617369
during compilation

>>108617369

fn
func <-- here, see, go made 2x progress

keep on Troonification going, never stop language sloptuidzation procedures

>>108617490
>>108617495
provide a concrete example and let's actually measure, or are you a nocoder?

>>108617629
measuring implementations doesnt make any sense for a language, the language is either sound linguistically or not, look:

function <-- pass
func <-- fail
fn <-- fail

no more measuring required for syntax.

<> are less than and greater than. They shouldn't be used as brackets. Take the lisp pill and just use () for all brackets.

>>108618867
>putting the concept of goroutines and channels into the language allows very fast channel operations
provide a concrete example and let's actually measure, or are you a nocoder?

>>108618949
thats not my quote retard, i just laugh at you two, trying to apply Gram units to what has Meters measurement.