>>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.

>>108617208
how the blocking is done here? i don't know haskell but when i look at the implementation of readTChan, there is a "retry" being returned
https://hackage.haskell.org/package/stm-2.5.3.1/docs/src/Control.Concurrent.STM.TChan.html#readTChan

-- |Read the next value from the 'TChan'.
readTChan :: TChan a -> STM a
readTChan (TChan read _write) = do
  listhead <- readTVar read
  head <- readTVar listhead
  case head of
    TNil -> retry
    TCons a tail -> do
        writeTVar read tail
        return a

With go, the thread is paused and it's the channels who unpause the thread. there is no retry/polling loop.

>>108617245
https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/
old but I wouldn't be surprised if you could write your own, faster channels in go in 2026. also all that boilerplate because of how leaky all these bad abstractions are. lol.

>>108620679
important distinction, because the stm and tchan are more general than what go puts on offer.
you can effectively implement csp atop with the Maybe equivalent to reading from stm channels thats effectively non-blocking. it does get quite ugly though.

there's a csp monad lib, i think literally called csp, thats probably what you want.

File: syz.png (42.8 KB)

42.8 KB PNG

>>108616568

sum :: [AnyNum] -> AnyNum

is impossible. The input can be

[AnyNum (1::Int), AnyNum (2 :: Float), AnyNum (3 :: T)]

, and there's no way to even check that they're actually all the same. Change it to (Num a, Typeable a)=> and then Data.Typeable.cast one to the other type before adding. Haskell is already not the path of least resistance and runtime typing adds even more resistance.

File: 1767505028776629.gif (312.4 KB)

312.4 KB GIF

>>108620679
So it's important to remember Haskell is not an imperative language. I don't mean in the cope sense, I mean it's pretty much a meta-language that describes structure, and how that relates to machine code is highly variable. You're not really describing a program the same way you are with something like Go, it's a lot more... fluid. Expressions in the language don't map the same way, the compiler obliterates a huge amount of structure, the compiler's optimizer itself is programmable in a high-level way. It's hard to explain if you're familiar with other programming languages, because it's exposing things and a way of thinking you haven't realized exist quite yet.

When both channels are empty, retry walks up the stack to the orElse and runs into another retry. There is no repolling loop, the thread is put to sleep until one of the retries fires, which happens only once a channel has been written to. Now the thing is, typically in go it seems like channels are handled exhaustively and in an alternative thread. So in Haskell, that's handled like so:

forkIO $ forever $ do
    blah blah blah....

In go this is the equivalent of defining the handler as a goroutine and exhausting channels with a for. "forever" isn't really the same thing as a for, but it does compile into essentially the same thing in this case.

Haskell + GHC is a very wild thing. If you're at all interested in computers, I can't recommend learning it enough.

>>108622494
>>108622494
> retry walks up the stack to the orElse and runs into another retry.
that's a loop (you may call that a "linear iterative process" if you are a functional tard)

the thing is that with go channels, you can have 10 000 go routines being paused without them having a cost. once they are paused, they stay like this. they are not awoken time to time to poll channels. like for example

while(true)
{
  if (chan_a.ready())
  {
    element = chan_a.read()
     break;
  }

  if (chan_b.ready())
  {
     element = chan_b.read()
     break;
  }

  pause(1000); // wait 1000ms before retrying
}

just imagine 10 000 coroutines waiting like that. this is crazy. functional programmer have no idea about the real world ("lisp knows the value of everything but the cost of nothing").

>>108622891
>that's a loop
That's not how retry + orElse works. They form a single blocking mechanism with choice. You are interpreting the code to mean:
"Okay I have nothing, find the next retry. Okay that has nothing either, go back to the first retry."
What it actually means is:
"Put this thread to sleep, it can be told to be woken up by writing to these channels."

The thread does not magically wake up to poll channels, it does not ping-pong back and forth between reading channels to see if anything is there.
The thread will be woken up by the runtime when a channel is written to, and then the block terminates.
Without a forever:

forkIO $ do
    ...

A single message will print, whether from channel 1 or 2, and then the thread will die. There is no looping mechanism, the thread does not consume CPU time until it's woken up.

>>108623062
common gopher l

File: HD-cVm_XoAAiSxn.jpg (47 KB)

47 KB JPG

Every thread tangentially related to Go is just hundreds of posts of people who psyopped themselves into caring about academia nonsense seething at Go's pragmatic superiority.

>>108623062
How is that even possible? Like how can it handle that with function calls? Even if they're macros, how can you modify the AST to turn code into a functional signal handler without registering it elsewhere? What the fuck?

>>108622343
> I was researching Hoare’s Communicating Sequential Processes model of concurrency and the π-calculus under Matt Might’s UCombinator research group as part of my (now redirected) PhD work to better enable multicore development.

he just skips the absolute retardation of CSP book. he cannot judge concurrency in any other place.

> crypto/tls, but please keep openssl itself up-to-date!

plus, updoooter opinion matters not

Reminder that Go didn't have generics at all from 2009 to 2018 lol

>>108622891
the thing is that channels design is retarded, they are not defined in heirarchy allowing complete chaos of the threading model, that itself is flawed and ye, based on those stupid CSP books

>>108623209
can you show that pragmatic superiority with a concrete example?

File: 1751237347772630.jpg (1002.1 KB)

1002.1 KB JPG

>>108624371
Monads.

>>108612948
>>108624833
>maidposters
Are you writing your code on a handheld maid computer?

File: 1775672582791320.jpg (138.7 KB)

138.7 KB JPG

>>108624890
Perhaps. Still waiting on the pocket Reduceron to be fully realized...

>>108624748
he's tricking you. no one know how the locking/unlocking is being handled by ghc (which is nothing more than an academic project). does haskel even have green threads?

>>108613781
Channels are poverty tier compared to the actor model

>>108625398
the actor model is a entire computation model like turing machine (statements), lambda calculus (functions), or logic programming (rules). it's not really comparable.

>>108624748
I think they're perfectly suitable for a toy language like Go.

>>108625398
Stop posting, idiot