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


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: gopher superiority.png (26 KB, 764x762)
26 KB
26 KB PNG
What other languages have systems analogous to channels and goroutines?
>>
>>103553290
clojure
https://www.braveclojure.com/core-async/
>>
Rust https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html
>>
>>103553290
rust, it does it better, we have channels, we have stream, we have async, we have broadcasts, we got other things that are better.
>>
File: file.png (73 KB, 1331x270)
73 KB
73 KB PNG
>>103553499
i generally go with tokio channel or async_channels but yea pm, also broadcast
>>
>>103553409
>>103553499
>Rust
Async was a mistake, but I wouldn't expect an abortion of a language like Rust to have done any different. Go did it right and it's the superior language
>>
>>103553290
Basically any language with multithreading.
Go just provides extra syntax for working with channels and green threads right away.

Java: Tasks and libraries for channels (e.g. JCSP)
C++: futures/async and libraries for channels (e.g. cpp-channel)
Rust (best lang): threads and channels in std (OS threads) or Tokio (recommended; green threads)

With, with Rust + Tokio, you get 1-to-1, many-to-1, and many-to-many channels, where go is just many-to-1 (last time I checked).
>>
>>103553574
>Async
>Green threads
>Goroutines
>Green threads
Go Rust niggers are retarded.
>>
>>103553581
Cry me a river
>>
stdin / stdout channels :]] those at least have a direction clearly defined, which is way more superior than some abstrasis above
>>
>>103553639
That's not even close to what's being discussed, nocoderkun...
>>
File: 1734439041447469.jpg (635 KB, 1206x1948)
635 KB
635 KB JPG
There are some other programming languages that implement equivalents of green threads instead of native threads. Examples:

Chicken Scheme uses lightweight user-level threads based on first-class continuations[15]
Common Lisp[16]
CPython natively supports asyncio since Version 3.4, alternative implementations exist like greenlet, eventlet and gevent, PyPy[17]
Crystal offers fibers[18]
D offers fibers, used for asynchronous I/O[19]
Dyalog APL terms them threads[20]
Erlang[21]
Go implements so called goroutines[22]
Haskell[22]
Julia uses green threads for its Tasks.
Limbo[23]
Lua uses coroutines for concurrency. Lua 5.2 also offers true C coroutine semantics through the functions lua_yieldk, lua_callk, and lua_pcallk. The CoCo extension allows true C coroutine semantics for Lua 5.1.
Nim provides asynchronous I/O and coroutines
OCaml, since version 5.0, supports green threads through the Domainslib.Task module
occam, which prefers the term process instead of thread due to its origins in communicating sequential processes
Perl supports green threads through coroutines
PHP supports green threads through fibers and coroutines
Ruby before version 1.9[24]
Racket (native threads are also available through Places[25])
SML/NJ's implementation of Concurrent ML
Smalltalk (most dialects: Squeak, VisualWorks, GNU Smalltalk, etc.)
Stackless Python supports either preemptive multitasking or cooperative multitasking through microthreads (termed tasklets).[26]
Tcl has coroutines and an event loop[27]
>>
>>103553855
bad ai
>>
>>103553499
>we
lmao. literal cult
>>
>>103553867
I copypasted from wikipedia lol
copy-pasting is something gophers should be very familiar with from 12 years of no generics
>>
File: gopherlook.png (10 KB, 200x120)
10 KB
10 KB PNG
>>103553916
>coming into a random thread and seething this hard
>>
File: pepe cobson.png (44 KB, 496x588)
44 KB
44 KB PNG
>>103553949
your language's "killer feature" is present in fucking every other language that has more than 3 users
seethe
>>
>>103554002
>he thinks golang is about shiny language features and not the process of software development
NGMI
>>
>>103553290
channeles/goroutines are so nice. I was doing something similar the other day at work with Promises in javascript and it wasn't too bad if I imagined them as channels/goroutines (i do golang mostly at work)
>>
>>103553855
asyncio/coroutines aren't equivalent to goroutines, so that safely eliminates 90% of the entries on that list. It turns out that it's actually pretty rare that languages do this properly.
>>
>>103553916
If you need generics you are either a hobbyist or reinventing the wheel.
>>
>>103554393
func Float64sAreSorted(x []float64) bool
func IntsAreSorted(x []int) bool
func StringsAreSorted(x []string) bool
type Float64Slice
func (x Float64Slice) Len() int
func (x Float64Slice) Less(i, j int) bool
func (p Float64Slice) Search(x float64) int
func (x Float64Slice) Sort()
func (x Float64Slice) Swap(i, j int)
type IntSlice
func (x IntSlice) Len() int
func (x IntSlice) Less(i, j int) bool
func (p IntSlice) Search(x int) int
func (x IntSlice) Sort()
func (x IntSlice) Swap(i, j int)
type StringSlice
func (x StringSlice) Len() int
func (x StringSlice) Less(i, j int) bool
func (p StringSlice) Search(x string) int
func (x StringSlice) Sort()
func (x StringSlice) Swap(i, j int)

>If you need generics you are either a hobbyist or reinventing the wheel.
Gophers really do have stockholm syndrome from being stuck with their awful garbage shit language. Pictured: excerpt from Go standard library, sort package
>>
i actually work with go at a big tech company.

it fucking sucks like every other programming language ever.

if you actually wrote anything in Go that isn't some gay side project you'd know that.
>>
File: pepe the frog.jpg (54 KB, 976x850)
54 KB
54 KB JPG
>>103554453
The total LOC for the implementation of every single one of these functions is about ~15 lines.
>>
>>103554453
and the issue is...?
do you want to reimplement the standard lib for some reason?
>>
>>103554393
Generics are one of those things that were supposed to be used for implementing standard libraries (and never really used outside of that).
In C++, this largely means the STL.

Of course it is used by people who think it’s “cool” to unnecessarily increase the size of the code while simultaneously obfuscating it for job security, and a power trip to make sure everyone is using their duplicative nonsense with their newspeak.

Kind of like go, and rust… they wanted new languages to form breakaway cults.
>>
>>103554630
why do nocoders think there's some massive gulf between the standard library, some third party library, and a custom utility library you/your team implemented? Every project will have a mix of the three, and there isn't really a fundamental difference between what sorts of functions they contain.
>>
>>103554689
there's an order of magnitude in the amount users between each of those
>>
>>103554453
Lmao, this is pathetic.
>>
Yeah I built software that keeps my media server updated 24 7 using Go. Why are you communicating with literal disabled autists from special needs schools with anime profile pictures and Dragonball Z collections?

You're literally sat here arguing with DISABLED people. Like if you encountered them irl it'd be like some barely sentient freak punching his mom in the face while wearing gayboy gamer hoodies.
>>
>>103554040
Clearly that’s what the OP thinks since they asked about what other languages have green threads
>>
>>103553521
Rust isn't trying to win by being a superior language. They trying to win with politics and brute force screeching.
>>
>>103555044
Wtf is "Chicken Script" or whatever? Omfg I'd love to just knock every autist out in one punch. Just BAM autist down, BAM autist down, BAM autist down.
>>
>>103555042
>Yeah I built software that keeps my media server updated 24 7 using Go
cute, but you could've simply put that apt upgrade invocation in your crontab file
>>
>>103554718
I would bet that it's below an order of magnitude in the case of boost. Regardless, what's the relevance of that? There are no doubt many functions in any standard library that are very rarely used, should they be barred from using generics as well?
>>
>>103554393
>>103554630
congrats on outing yourself as extremely inexperienced.
example 1: AST manipulation
>work on a language server
>need to manipulate AST
>one useful utility function is "find the deepest node in the tree containing this location which has type X"
>need to pass in the type X to the function
>generics
example 2: game engines
>creating a game engine using the ECS model
>need a way to get all components of a given type
>getComponent<T>
>generics
>>103554525
the issue is that I want to sort lists of things other than floats, ints and strings
>>103555068
>Wtf is "Chicken Script" or whatever
a better language than go lmao
>>
>>103555238
>Languages
not a go domain
>Game engines
not a go domain

congrats on your nothingburger post
>>
>>103555369
Can't tell if bait, or average Go programmer.
>>
>>103555403
>hurr durr this server language sucks because I can't make game engines in it!
>>
>>103554453
Generics in Go are a recent addition which is why you probably won't see them used in the stdlib. It's pointless to rewrite anything if it works.
>>
>>103555428
>Server language
Go programmer confirmed.
>>
>>103555238
Have your types satisfy an interface.
>>
>>103555369
Pretty much no other language has such egregious domain issues. Is go particularly bad?
>>
>>103555063
>>103553521
Cope and seethe. Go is an irrelevant language. Rust already won, and Go is no where close.
>>
>>103555123
Sounds like gay sex. That won't download and catalogue new videos from the web.
>>103555428
Gaming is synonymous with autists. I feel like the dude in They Live, except when I put on the glasses it reveals everyone on this site as severely disabled autists.
>>
>>103555544
Show me a self referential data structure in rust.
>>
>>103555544
Great that's so good for you, I'm so happy for you bro. Now you can accomplish literally nothing ever on the computer too, not just in real life. Brilliant!
>>
>>103555042
thanks for the reminder
>>
>>103555544
>Go is an irrelevant language
Yeah, it's so irrelevant that it powers all cloud native computing. Nobody uses Go, which is why every single web application is shipped as a Docker container and it's why every large corporation is using Kubernetes. Because Go is irrelevant.
Meanwhile, Rust is used uhhh........ For bluetooth on android? lol
>>
>>103555896
Rewriting echo, cat and grep.
>>
>>103555896
>Go is good, because web shitters and Jewgol
Do go fags really?
>>
>>103555965
do schizophrenic neet /g/ retards really?
>>
>>103555896
>Yeah, it's so irrelevant that it powers all [webshit]. Nobody uses Go, which is why every single [webshit] application is shipped as a Docker container and it's why every large corporation is using Kubernetes [for webshit]. Because Go is irrelevant.
You are not making your language look good
>>
>>103555982
I think your programming broke, that's not a sentence.
>>
>>103555925
I think you're confusing rust with go.
>>
>>103555994
>>103555965
>I DONT LIKE IT SO IT DOESN'T COUNT!!!
>>
>>103556010
Oh no, it definitely counts, it's just really embarrassing
>>
>>103556021
Maybe for you
>>
>>103556010
I didn't say it doesn't count, just that I look down on web shitters and don't consider anything you do to be either praise or noteworthy.
>>
>>103556050
That's okay, nobody cares what you think anyway. All of web infrastructure will be powered by Go regardless.
>>
>>103556056
>All of web infrastructure will be powered by Go regardless.
lol, lmao. Okay lil bro, whatever you say.
>>
>>103556079
Maybe you should try doing some research.
>>
>>103555238
> ast, pass in the type X to the function
The A is for abstract. A type ‘bool’ is not implemented as a literal boolean type. Typically, it’s an enum value for, say, bool, that you’re searching for, or the ID of some user defined type.
Creating a throwaway temporary object just to get the trick the generics system into searching for a node by type is the most insane shit I ever heard, and is exactly what I was talking about earlier.
>>
>>103556198
>The A is for abstract. A type ‘bool’ is not implemented as a literal boolean type
yes, you massive fucking dunning kruger retard. Instead, you'll have a bunch of different types to represent different kinds of literals, different language constructs (e.g. assignment statements, infix expressions, function declarations, type declarations, and whatever else your language has)
>>
>>103555997
Anytime someone mentiones "the Jews" or conspiracy theories, you know they are just the biggest outcast freaks in existence... Srs... Not cool big teddy bear grandpa KKK neurotypical Tom Metzger, that's who they think they are of course lmao. In reality they are anime outcasts.

Get beat.
>>
>>103555555
god can't you just stop referencing the same false meme again and again, there are tons of ways to do it either with unsafe or without.

you are only showing your lack of subject on the matter.
>>
File: file.png (124 KB, 483x351)
124 KB
124 KB PNG
>>103555555
>>103556434
here is a safe example, you could do without Option using "unsafe" code but it's not that hard to understand even this way.
>>
>>103556455
you could also use refcell, as previously said, there are tons of ways to do it.
>>
>>103556464
could also use box.
>>
>>103556434
lack of knowledge*
>>
>>103556455
Now do anything outside a toy example. Lets say the game of life using a self referential grid to calculate and update the next state. In C++, Go etc this is as simple as a struct with a vector of pointers then reading a bool held in that struct. Your data structures would look something like

base struct {
alive: bool
neighbours: []*base
}

grid struct {
grid: [][]base
}
>>
>>103556273
> different kinds of literals
I meant literal in the ordinary sense, not the compiler/language sense.
I’m sure your pocket calculator needs generics and a type system to distinguish operators and digits.
No wonder compilers are so slow nowadays, the compiler writers have the same brainrot.
>>
>>103556692
> grid: [][]base
good example of a shitty parser turning 60 years of programming and a 1000 years of mathematical notation on it’s head because they couldn’t figure out how to parse array indicators as a suffix so developers are forced to self-lobotomize.
>>
>>103557078
Lets see your implementation then.
>>
>>103553290
Not concurrency but Go interfaces are really comfy
>>
>>103557078
>because they couldn’t figure out how to
They deliberately decided to make it a prefix on purpose. It's clearer at conveying intent.
>>
>>103554453
I don't get it. other than seeing very similar code (which you can always copy & paste and modify according to your needs), what's wrong with this? you can, like, have a single file for each type and copy the code. that's it. and all you need to modify something is to go to the file that corresponds to a type and change the code.
>>
>>103556455
That's not a self-referential data structure though (it references a field in a separate value)...

You can use crates like "ouroboros" to do it safely, or just raw dog it in unsafe:
#[derive(Debug)]
struct Foo {
a: u32,
b: *mut u32,
}

fn main() {
let mut foo = Foo {
a: 13,
b: std::ptr::null_mut(),
};

foo.b = &mut foo.a as *mut _;

println!("{foo:?}");

unsafe {
*foo.b = 42;
}

println!("{foo:?}");
}

There's just not a lot of places where this pattern is useful, IMO (aside from some small buffer tricks).
>>
>>103553521
>meh async rust bad
of course the retard doesn't know that channels and async are orthogonal.
>>
>>103557043
>sure, go is unsuitable for writing a decent compiler (look at the go compiler, it fucking sucks geg)
>but go might be okay if all you have to program is a fucking pocket calculator
beyond parody
>>
>>103557217
> clear at conveying intent
To whom? Nobody in the software/programming/mathematics/engineering/science/graduated-high-school/GED communities.
More likely it made sense to programmers from Isreal who go right-to-left and thought now is their time in the great scheme of things.
>>
>>103558094
The go compiler puts every other compiler to shame. Completely portable, self compilable, no external deps. Supports cross compilation without llvm.

Rusty nails pretend to be good programmers but their compiler is dogshit built on LLVM. I have more respect for the Zig community, at least they are moving away from LLVM.

Rust trannies continue to bend over and let LLVM fuck them. Who knows, maybe they like that. ( Or they dont have enough skill to write a low level compiler).
>>
>>103558291
The free pascal compiler comes close, but it still has dependencies on GNU shit.
>>
>>103558291
>The go compiler puts every other compiler to shame
lmao. Is Go even an optimizing compiler? The ASM it produces is normally dogshit and I don't think I've ever seen it autovectorize.
>>
>>103555544
>Go is an irrelevant language.
I've been reading this for longer than the average /g/ lurker has been alive and I'm still reading it. How irrelevant can it be if people regularly talk about how irrelevant it is - for over a decade.
>>
>>103558291
It was the unoptimized experimental plan 9 C compiler, and they hacked it to look different like those comp sci cheaters I sold my assignment to did with shit like [][]array and other arbitrary nonsense.
>>
>>103556692
Again, you can do it exactly the same way with no issues but you are retarded, you should rather use data oriented design principles and have a single struct containing arrays.

Your data schema is literally pajeet tier programming.

There is nothing in rust preventing you from doing any kind of data structures besides skill issues!
>>
>>103558346
It's a lot newer, it is what it is. Go improves as a language faster than any of the others I'm aware of. Many features people autism about are now in the language.
>>
>>103557467
Ah you meant one that points to itself, i mean you can do it too and you don't need a crate or unsafe either.

I thought you meant one that reference to another instance of the same type.
>>
>>103557467
And yea linked lists suck anyway and we have those in std collection anyway.
>>
>>103558346
>>103558404
Thank you for proving my point, that theres nothing good to say about RustC, Clang or GCC. The go compiler having faults and still being better than everything else shows how bad the LLVM and GCC shitshow has become.
>>
>>103558291
The Rust users will never be women.
The Rust compiler will never be capable of code generation.
(The irony of Rust users fagging around about how its gonna replace C++, yet forgetting that their compiler codegen is entirely done in C++ will never stop being funny)
>>
>>103553290
>What other languages have systems analogous to channels and goroutines?
Java has Virtual Threads now which are basically like Goroutines. Channels.. well Java has queues but queues can't be closed but there's a small library that gives you Go like channels https://github.com/softwaremill/jox
>>
>>103558963
>doesn't know that rustc+cranelift is faster that /g/otardlang
>>
>>103558529
That's a lot of words but I see no code. I accept your concession.
>>
>>103553290
erlang
>>
>>103559251
Gleam is pretty nice.
>>
>>103559129
>>'swapping backends'.
I suppose a rust user like you would be very familliar swapping things in and out of your backend.
>>
>>103559315
>swapping
write more.
/g/tards are funny.
>>
>>103553290
https://learn.microsoft.com/en-us/windows/win32/procthread/using-fibers
>>
ive deleted fibers from PHP btw
>>
>>103560434
>php
uhh ok you smelly subhuman gypsy slav
>>
use case for non-c?
>>
>>103558943
>still being better than everything else
How? It was missing even basic optimizations like passing arguments in registers last time I checked. There’s a reason that go isn’t outperforming fucking java in benchmarks lol even though JVM languages should suck at benchmarks
>>
>>103558233
>To whom?
Literally anybody with a brain. They're on the left instead of the right. You read it as "an array of an array of bases" instead "base array array" Is that such a big difference that it blows your tiny little libtard mind?
>>
>>103553302
fpbp

>>103559251
>>103559265
also Elixir
>>
Haskell, does go have STM?
>>
>>103559235
I don't owe you my time, I'm plenty busy enough as is, I'm not living in my mom's basement like you
>>
>>103553521
Suggest a better alternative than async.
>>
>>103558963
>forgetting that their compiler codegen is entirely done in C++
Show me one (1) example of someone using Rust and thinking that LLVM is not made in C++.

pro tip: you won't because it never happens
>>
>>103561201
Goroutines and channels.
>>
>>103560630
hehe, plebeian, you cant even say something without falling into mud. gypsies slavs whata word salad.

the author is a dumbster as well, didnt know that a mass culture, no matter how you call them - goroutines co-co-coroutines fibers generators green greenish threads. this is what masses use and what is incepted long time ago.
>>
>>103558291
>>103558536
>>103558943
Implement yourself any algorithm of your choice in Go and I will implement it in Rust and we will compare which will be faster.

Care for little challenge? Or does Google only pay you for posting?
>>
>>103561254
Rust has coroutines and channels though.
>>
File: 1734449666532189.gif (1.55 MB, 250x445)
1.55 MB
1.55 MB GIF
>>103561263
here, i have a challenge for both rust trannies and go-goers (posted it here some time ago btw, nobody solved):

$p = SM\Promise::Row([# row/line runs concurrently
SM\sleep(1000),
SM\Promise::Func(function(object $r): ?object {
static $N=0;
$N++;
echo '['.$N.']';
return $r->promiseDelay(200);# repeat in 200ms
})
], 0, 1);# stops when: 0=breaks, 1=finishes
echo "> example #1: ";
$t = hrtime(true);
SM\await($p);
echo " in ".((hrtime(true)-$t) / 1000000)."ms\n";
>>
>>103561290
Solved what? I asked to implement an algorithm in Go, not post code diarrhea.
>>
>>103554453
>Pictured: excerpt from a stdlib package that is kept around for historical reasons but is completely deprecated by the generic slices library
This isn't as much of an own as you think it is
>>
>>103553290
Occam
>>
>>103561337
>you don't need generics!
>why are you posting code that got deprecated by ganerics
Gotards are really retarded
>>
>>103557246
What's wrong with it is that you wouldn't need a copy of everything for each type if the language wasn't created by braindead boomers

>>103561337
>boomers insist for 10 years that generics are bad
> massive Go codebases are now relying on APIs without generics
>boomers finally come to their senses and add generics
>now there's two different APIs for everything
>all actual code except greenfield project still relies on idiotic old APIs
It's a pretty big own.
If they fucked up something so fundamental as not having generics in 2009, there must be a million other things they also fucked up.
>>
>>103559235
>>103561171
What do you actually want, if it's just a template I'm willing to make you a base schéma of what it would look like. If you want a full blown program i don't have half an hour to give you without remuneration, there are already plenty games of life existing in rust.
>>
>>103561308
ye, sure, thats how you pleb accept conceccion. patrician would appreciate the challenge. but you just a bunch of dumbsters

i have a javascript patrician who did it with generator, but you plebs just cant
>>
>>103555544
Are they even in the same domain space? I've mostly seen Go for web stuff and Rust for systems stuff. I know both can work in the other domain but each seems specialized enough to have little overlap in usage.
>>
>>103561423
You are correct. Go is NodeJS replacement and Rust is C++ replacement. Go programmers just really don't like to be reminded about it.

>>103561421
I am fine accepting whatever consession you want of that means I don't have to look at that ugly clump of symbols.
>>
>>103561290
here is the javascript counterpart with generator, which i consider worse

function *nums() {
let n = 0;
while (true) {
console.log("[%d]", ++n);
yield* sleep(200);
}
}
function *sleep(ms) {
const end = Date.now() + ms;
while (Date.now() < end) yield;
}
function race(...gens) {
main: while (true) {
for (const gen of gens) {
const s = gen.next();
if (s.done) break main;
}
}
}
race(sleep(1000), nums(), nums());


show me, show me there are not only plebs among you. show you can at least complete something. or show the superiority.
>>
>>103553290
limbo
erlang
>>
>>103561399
I'm not sure what the actual problem is? New code just uses the new API, and old code uses the old API (which is mostly just synonyms for the new API now), and nothing seems to be breaking. I get that Go is an insanely opinionated language and some of its opinions (like not having generics initially) are kind of dumb, but at least that particular opinion is one they realized was stupid
>>
>>103561534
They won't even let you have unused variables which is infuriating in the process of writing code if you just want to lay down some schema first.

There is not even the option to make it a warn.

So gophers will do tons of _ := quackery
>>
>>103561399
you forgot the best part
>decided to ask java people about how to do generics right
lmao
the premise of this retarded language was debunked on day 1, or rather day 1 outside of google:
https://youtu.be/2-pPAvqyluI?t=3399
"philosophical difference" hehehe.
one can't expect /g/eets to get any of that of course.
i mean rob pike himself pretty much called gophers retards (with a positive spin of course):
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
this tickles the "a genius admires simplicity" retards just about right.
>>
>>103561610
>>decided to ask java people about how to do generics right
go is mostly descended from a language called limbo, limbo had generics that work pretty much exactly like how they do in go.

limbo's generics as well as java's generics are pretty much entirely derived from C++'s generics.
>>
>>103561861
are limbo and "C++ generics" erased?
>>
File: take this.png (33 KB, 1536x2048)
33 KB
33 KB PNG
>>103561263
func Compute(n int, m *sync.Map) *big.Int {
if val, exists := m.Load(n); exists {
return val.(*big.Int)
}

res := new(big.Int).Add(Compute(n-1, m), Compute(n-2, m))
m.Store(n, res)
return res
}

type result struct {
num int
val *big.Int
}
type processchans struct {
input chan result
output chan *big.Int
done chan struct{}
}

func processResults(chans processchans) {
var nextExpect int
backlog := make(map[int]*big.Int)

for item := range chans.input {
if item.num == nextExpect {
chans.output <- item.val
nextExpect++

for {
if val, exists := backlog[nextExpect]; exists {
chans.output <- val
nextExpect++
} else {
break
}
}
} else {
backlog[item.num] = item.val
}
}

close(chans.output)
chans.done <- struct{}{}
}

var numToFib = 5000

func main() {
numcpu := runtime.NumCPU()
runtime.GOMAXPROCS(numcpu)

memo := sync.Map{}
memo.Store(0, big.NewInt(0))
memo.Store(1, big.NewInt(1))

var wg sync.WaitGroup
chans := processchans{
input: make(chan result, numcpu),
output: make(chan *big.Int, numcpu),
done: make(chan struct{}),
}

go processResults(chans)

jobs := make(chan int, numToFib)
for range numcpu {
wg.Add(1)
go func() {
defer wg.Done()
for n := range jobs {
chans.input <- result{num: n, val: Compute(n, &memo)}
}
}()
}

go func() {
for i := range numToFib {
jobs <- i
}
close(jobs)
}()

go func() {
wg.Wait()
close(chans.input)
}()

for res := range chans.output {
fmt.Println(res)
}

<-chans.done
}
>>
>>103562109
is that how gotard code looks like. lmao.
wtf. even atomics in (actual) system languages are nicer.
>>
>>103562190
your code, saar?
>>
>>103562109
You should probably add a context cancellation select check if this is a long running thing.
>>103562190
There's nothing wrong with it. I can read it easily. Excited to see the GPT Rust code (an inherently aesthetically ugly language and inherently unproductive).
>>
>>103562109
This is retarded and the most convoluted way I've ever seen to implement fibonacci, why the fuck use channels here? It's a totally CPU bound problem.
>>
>>103562500
>why the fuck use channels here?
Because I could.
>>
>>103562591
expected retarded code from a gopher.
try posting actual useful and idiomatic go code and i'll make you a rust versoin that's better on all metrics (consize, readable, fast, etc).
>>
>>103562775
>just change your code to fit my ideal of what it should be and ill hold up my end of the bargain.
No. My code lazily computes fibonacci numbes using concurrency and goroutines, backed by a thread-safe memo map to ensure de-duplication of effort across processes, communicating results to another process that ensures that all results are printed in the expected order. You can either write the Rust equivalent or concede.
>>
>>103562775
It was so you can't. It's purposefully using "brilliant language" (like the quote) elements to make your job a nightmare... Channels and concurrency are very useful... Ytdlp still gets videos ONE AT A TIME like a beta male cuck. A simple Go wrapper you can make in half hour or less can turn it into a concurrent beast with ease.
>>
>>103562991
This kills the crab
>>
>>103562991
we have channels in rust you know.
also concurrency for fibonnaci, fucking morons, it is an inherently sequential algorithm.
>>
>>103563034
>>103563082
>>
>>103563034
>>103563082
>>103563115
we also have concurency, and streams.

you can literally do for_each_concurrent on a stream (think of it like an iterator where the data is comming and you may not have all of it yet, ie data comming from the network or io or anything else)

also streams can be generic.
>>
>>103563082
It's a sequential algorithm that you're running concurrently in order to process different inputs
>>
>>103563082
>>103563160
>>103563034
>>103562109
Are you people retarded? Using concurrency here is likely making your algorithm slower. Concurrency works when there's IO, if you have something CPU bound, then it's not doing anything and you've added a load of overhead for no gain. If you had threads, then this might make sense.
>>
File: morgan-freeman-true.gif (146 KB, 640x476)
146 KB
146 KB GIF
>>103563196
>If you had threads
Goroutines are multiplexed onto threads as needed
>>
>>103563196
even with threads, fibonnaci is inherently sequential, you cannot make it faster by paralelization.
first one you quoted was me, i was explicitly stating that it was retarded.
>>
>>103563231
same for rust async tasks.
tokio dispatches them on threads (and it does a much better job).
anyway, it's pointless because >>103563234
>>
>>103563082
>>103563133
>>103563196
>>103563234
okay, it's inefficient. so what? are you scared to desecrate your religion by using it to implement something that isn't perfect?
>>
>>103563196
>>103563234
Irrelevant ramblings. You sit here doing bullshit fairytale Advent of Code crap that never appears in real life, and won't do this in crablang. You didn't stipulate that the code must be most performant...
>>
>>103563246
I thought tokio was a third party library?
>>
>>103555238
>work on a language server
So that was a yes to the "do you want to reimplement std
>>
>>103563291
Cope.
>>103563231
>Mommy runtime, pls schedule threads for me
lmao, cucked language.
>>
>>103563307
i never said you couldn't use one.
also you don't have to use tokio, you can use async_std which is official.
there is good reasons for it to be separate, they didn't want to uncessarily add bloat to the language, most programs do not need an async runtime.
but even then you can do it with async_std alone.
>>
>>103563330
>>103563307
also you don't need any crate, you can make a pretty minimal runtime in less than 50 sloc, but yea continue with your bullshit example no one uses in the real world.

gophers cannot think of any real use for their language.
>>
>>103563377
>you can make a pretty minimal runtime in less than 50 sloc
I’m seeing a lot of claims like this and not a lot of implementation. Why is that?
>>
>all this crab seethe
>not a single line of rust code posted
>>
>>103563234
>fibonnaci is inherently sequential
The point is that you can have one computer computing fibonnaci and send it to another computer no problem. Or you can have one computer start from a certain point and another from another point
his code is too complex thought, behold go's simplicity and the following example on power series: https://youtu.be/hB05UFqOtFA?t=1671
>>
File: file.png (570 KB, 921x824)
570 KB
570 KB PNG
>>103562109
>>
>>103563463
>>103563479
>>
>>103563479
>>103563487
>>103563463
see the thing however, is that i could easily turn that channel into a stream and then use .map() .zip() .fold() etc on it.

i could even do stuff like for_each_concurrent(|n| async {}) and then do http request concurently with n as an argument as an example.
>>
>>103563479
That’s not the same algorithm moron. Throw a memoizer and worker pool
in there to match >>103562109 and tell me how many lines it takes
>that’s not efficient
that’s not what was asked. rust *can* do this, correct?
>>
>>103563528
i don't want to read your retarded go algorithm, only pajeets like to have shit thrown at their eyes
>>
>>103563528
>>103563545
and yes you can do it with rust without any issue, you are just assuming it can't because you don't know it.
there isn't a single thing go can do that rust cannot, the reverse isn't true however.
>>
>>103563528
also, fucking asking for a memorizer and worker pool on a fucking sequential algorithm
at least the memorizer can make sense, but worker pool that's just retarded.
>>
>>103563575
>>103563528
memoirizer you can just use any mutex or rwlock over your hashmap really (we also have thread safe hashmap that do it for you as crates).

thread pool, you can just make the compute function a self standing task and run a bunch of them.
>>
>rust can do it, retard
>I just don’t want to post code because it’s stupid to do it this way
>let me reply to the same post four times to show how not angry I am
lmao >>103563262 nailed it
>>
>>103563528
>lines
Gay ass metric
>memoizer
No changes in loc, it's just RwLock::new().
>worker pool
It's worth pointing out that the other anon didn't implement a worker pool, they're just sending results on an unbuffered channel to a waiting go routine (although I suppose you could say that this is actually a worker pool, just with a single worker). Implementing a worker in Rust isn't that complex either (it's one of the last projects in The Book see: https://doc.rust-lang.org/book/ch20-02-multithreaded.html). Not sure about loc, probably like 30-50 tops.
>>
>>103563516
I guess you could embed a poor reinvention of unix into your langauge but it would just make it more difficult to read.
>>
>>103563595
i just don't want to have to read the garbage that is that go code, it's an insult to beauty.
also, it's boring pajeet tier stuff with no practical uses.

at least tell me the exact requirement as english text if you really want me to do it but there is nothing preventing it from being done besides me having more intesting things to do.
>>
>>103563619
nah, it's pm as easy as implementing poll() which is pretty trivial, ask chatgpt if you want and even that retarded ass llm can figure out how to do it in < 50sloc.
>>
>>103563619
>>103563626
also "hur durr do something retarded to prove that rust can do retarded things too" fucking moronic.
>>
>>103563657
>>103563626
why not flip it the other way around, show proper metaprogramming in go, or just conditional compilation that does not suck balls (no only being able to do a whole file conditionally is not sufficient).

in rust you can make a single line or statement conditional.

or just a struct definition conditional.
>>
>>103563479
looks like a bunch of vomit
>>
>>103563701
lmao, fun comming from a gopher
if err != nil bullshitery lmao
>>
>>103563554
>the reverse isn't true however.
What about powering all native cloud infrastructure via docker, kubernetes & et al.? Rust has a pretty hard time actually playing a part in the world of software, unlike Go....
>>
>>103563737
lol
ad populum fallacy

also, rust is also widely used so what even is your point.
>>
>>103563759
>what even is your point.
My point is that Go powers all native cloud infrastructure. What domain does Rust have anything close to as strong of a claim on?
>>
>>103563771
cloudflare's load balancer literally is built on rust.
4chan is relying on rust to run.

there are tons of widely used software written in rust and they generally are of higher quality than anything else.
>>
>>103563810
Let's Encrypt!, which provides SSL certificates for more than 400 million websites, is also 100% written in Go.
>>
>>103553855
>Nim provides asynchronous I/O and coroutines
lol, lmao even, have you actually used that pile of garbage? it's legit broken
>>
>>103563810
https://blog.cloudflare.com/tag/go/
oh no no no fellow crustaceans!
>>
>>103563829
alright, some software is written in rust and some in go, i never said nothing is written in go.
but a lot of things being written in it doesn't make it a good language, ie php, java etc.

so what is your argument again?
>>
>>103563861
https://blog.cloudflare.com/tag/rust/
what's your point exactly ?
>>
>>103563881
I don't know, what's yours? Golangers have never seethed over the mere existence of Rust, but this thread is fulled with seething crab meat.
>>
>>103563330
>they didn't want to uncessarily add bloat

Yeah as much this as electric car manufacturers and low emissions zone BS just wants to save the planet... You know e=mc2, but learn that reality=(time×money)2

Using that formula we can see that the reality is they are lazy people. Go improves rapidly. Your criticism today will be obsolete within a few years. We have seen this already with a few things like generics (which many see as a BAD addition, but simply demonstrating the point). We can see their laziness in their projects and threads. Many Go users have created software that does things they rely on in their daily computing lives. By themselves. No team effort, maintained easily. These get posted in Go threads all the time. Rust threads? A barren desert.

Just reproduce the retarded program. I thought you were going to use GPT anyway so just ask it the thing. Fibonacci is useless itself anyway, even without routines.
>>
>>103557246
there's nothing actually wrong with it, it's simple code that you can read through and easy to search for the exact type you need.

complexity circlejerkers keep crying about generics that can be replaced by a fucking simple code generators, not even needed to be at the language level, literally just generate code programatically and forget about it
they fucking do this to generate bindings for all languages with a single click, fucking C had code generators and the 90s
yet people still bloated the language and compiler with generic shit and templates
>>
>>103557246
>>103563963
now do that with a file that has more than 10 different conditional compilation conditions possibly nested.

that's gonna be fun to write and read.
>>
File: file.png (1.09 MB, 1145x1232)
1.09 MB
1.09 MB PNG
>>103563463
there you go, also hashmap was retarded when you could use a vec.
>>
>>103564102
>>103563463
also i would argue he did it in a retarded way especially because he was a gopher and go was literally made for retards.
>>
File: file.png (357 KB, 1505x892)
357 KB
357 KB PNG
>>103553290
>imagine being so retarded that you think that simple shit is exclusive to go...
python with asyncio and JS do it too, brainlet.
Yes kiddo, I posted it again.

>also rustlets and gotards in the same thread,
Already leaving, no serious conversation about programming can happen with you tards.
>>
>>103564097
nobody is doing something so backwards-head-up-the-ass-cnile retarded in golang such as to need complex conditional compilation
>>
>>103564136
> what even are feature flags
> what even are different platforms with different needs.
>>
File: IQ-bell-curve.jpg (41 KB, 466x264)
41 KB
41 KB JPG
>>103564130
>I'm a smart person, and that means I need a smart, complicated language. If someone smarter than me decides that a language should be simple, then that means it's for people stupider than me.
>>
>>103564136
fun how gophers will say "muh usecase" when an obvious flaw with their lang is pointed, then literally ask someone to do fib in parallel to show that their language can do it lmao.
>>
>>103564146
>he needs conditional compilation to cross-compile for different platforms
lol
>>
>>103564167
alright, write me a program that injects graphic tablet pen inputs, it needs to run on windows linux and mac os.

for linux you can use ioctl
for windows you'll have to make a custom driver and use write() to that driver.
for mac os it'll be again different

but muh conditional compilation useless.

your fucking retard language compiler is made using conditional compilation.
>>
>>103564155
You can be smart and enjoy legos, doesn't mean you're gonna build an actual skyscraper using legos.
>>
>>103564189
how about you finish writing this in rust first?
>>103562109
>>
>>103564155
> seeth in not being able to use the most basic stuff like .map() and .filter().
> have to write 50 lines of codes for things that are oneliners in rust and other languages.
> often making mistakes in the process
> think your language is superior
>>
>>103564232
Rust derangement syndrome
>>
>>103564219
That's okay, Go powers all cloud native computing anyway.

>>103564237
>filtered
>>
File: file.png (563 KB, 1920x1080)
563 KB
563 KB PNG
>>103564232
i actually have such a program nigger.
>>
>>103562078
yes? obviously? though the way they do both is different, since C++ is monomorphized.
reified generics are a shit concept that shouldn't exist. not even haskell uses them.
what's your excuse for wanting this shit? are you one of those retards who thinks runtime polymorphism is a good idea? how about you go use a dynamically typed language then?
>>
>>103564232
>>103564102
>>
i like money
which lang will bring most money to me?
spare me your cult following and autism and just answer as if you were normal men
>>
>>103564130
This is a great screenshot! It would be a shame if I actually went and visited the blog it was posted on.
>EDIT: This is now an old post and my opinion of Go has changed a great deal over the years. This article has been used to cause harm on the reputation of Go and its community which is not warranted. Over the years i’ve come to appreciate the simplicity of Go and the ethos behind its creation. Today, I’m employed as a Go engineer and I enjoy using it tremendously. In fact, I’d go further and say it’s one of the finest languages I’ve ever used. With all honesty, my opinion was wrong when I wrote this article and the quotes by Rob Pike were obviously a reaction to the complexity of other bloated languages.
>>
>>103564277
he said that because he's a cniles and haven't tried rust.
yea go is simpler to use than c.
but i'd take c++ or rust over go any day.
>>
>>103564289
Maybe Rust should try having a language specification first.
>>
>>103564297
classic argument that has been show false again.
rust has rfc, rust is stable since 1.0, meaning, your code won't magically stop working with a newer rust version, and even if it did, the fix would be trivial.
>>
>>103564102
compute_fib is blocking If you watched the go vid I linked you would know how to implement a simple async function
>>
>>103564308
i could make async, i didn't bother to because it's cpu bound, can you stop nitpicking on bullshit now ?
>>
>>103564308
>>103564316
also,
> he thinks all function called within async must also be async.

fucking lmao.
cpu bound tasks don't need to be async in 99% of cases.
>>
>>103564316
Then why use mutex? you are blocking vec
>>
>>103564306
I forgot the name of it, can anyone help me?
>it won't happen but if it did it's fine anyway
It's not slippery slope, but it's kind of like it, and I just can't remember the name which bothers me.
>>
>>103564276
your capacity to make money as a programmer is entirely based on you, not the tools you use. you will never be a top earner in this field if you're seriously limited by something so fucking droll.
if you want money, don't be a programmer either. there are far better careers for making money than being a fucking code monkey. go to business school.
>>
>>103553302
this
>>
>>103564341
you could use rwlock, you could use other types, but for the requirments that were stated you don't need anything more complext than that.

pragmatism is one of the most important thing when engineering anything.

the requirement was that it could return fib for n, and return a cached version if it was already there, whilst also being able to reply to many concurrent request, that code can do that.
>>
>>103564276
>>103564362
i make 130k / y
my job is mainly writing rust code.
>>
>>103564362
imagine thinking you can earn as much money with fucking useless shit like haskell or rust compared to C++, javascript, java...
thanks for a non-answer you useless college fag
>>
>>103564364
But if a thread tries to access vec then it will be blocked, so "reply to many concurrent request" is actually "reply to no concurrent request"
>>
>>103564377
that's great. you could have been an executive making 10x that amount while your only duties are sending emails and sitting in on meetings. instead you're a junior programmer bidden to higher powers.
>>
>>103564394
If you can write Haskell you can write any other programming language.
>>
>>103564397
the vec will be blocked only as long as fib n isn't known.

in all case you have to wait for fib n to be known to be able to reply to any request asking for something higher than fib n.

also i could have made it a little more complext to not block when n is known and one request ask for a n that isn't, that's like a 5 sloc edit so who cares really.
>>
>>103564412
you shouldn't respond to bait anon
>>
>>103564407
i'm senior and that's only one of my contracts.
i do multiple contracts.
>>
>>103564397
in previous iteration of the code i did use channels;

i could just use channels again, and only locking the vec for insertion.
>>
>>103564432
if you're a senior making $130k, you're getting ripped off. ESPECIALLY if you're a fucking 1099
>>
>>103564247
>That's okay, Go powers all cloud native computing anyway.
>shit I pulled from my ass
like they dropped everything written in Node? Do you even enterprise?
>>
>>103564432
im a "senior" and i make 200k
>>
>>103564471
there are other advantages such as having shares of the company, full remote, i choose my schedules and other nice pros etc...

i could make more money still, but this job is just so flexible that i don't care about making more.
>>
>>103564486
>>103564492
>>
>>103564297
https://github.com/ferrocene/specification
>>
>>103564499
>>103564492
im full remote and have shares of the company and much more benefits like full private health insurance and travels and i make 200k
>>
>>103564276
The language doesn't matter. You gotta go up into management as soon as possible.
>>
>>103564397
>>103564424
>>103564451
anyway, i wasted enough time on a problem that has no practical uses and we know can fully be done in rust, there is nothing that inherently prevents you from doing it in rust, and it'll be much simpler than the go code so whatever.
>>
>>103564526
how do I do that god damn it fucking corpo world is gay as shit
how does one transition from engineer to management
>>
>>103553290
Iirc go is an implementation of a more abstract way to handle multi-threaded applications called the "CSP model" (Communicating Sequential Processes), so you can start by looking up what languages implement this or something akin to it.
>>
>>103564412
Haskell has null it's called bottom
>>
>>103564526
not the one you replied to, but fuck i do not want to do managment lol.

i'd take 150k with no managment rather than 300k with.
>>
>>103564254
monomorphized != erased
retard
>>
>>103564543
Idk and idc. I am a programmer because I like programming.
>>
>>103557599
Huh? Without async channels are useless.
>>
I work in a financial systems company and almost all new server code is written in Go. Rust and C# were also demoed R&D wide to see which could scale and be maintainable.
Go won. C# came second. People started laughing when Rust was demoed in our team, and judging by the final results it was the same for other teams.
This pretty much repeated in the US, UK and Japanese branches as well.
>>
>>103564632
You can use channels with regular threads too. That's how I make most of my Rust multi threaded stuff.
>>
>>103564492
Again, none of that matters. $130k annually is nothing if you're worth your salt. The other anon getting paid $200k is still low depending on just how much of a senior he is.
When I still worked, my monthly invoices were for @ $135k. $35k was for me, 5x $20k for my team. I always had contracts with termination clauses with no-less than 8-digit payouts. Never had to invoke them, but I wouldn't do work without a robust contract to protect me and my guys.
>full remote, i choose my schedules
That's basic 1099 shit. If you're a 1099 and your client doesn't like you doing this, you should drop that client immediately.
>>
>>103564665
>I work in a fictional company*
FTFY
>>
>>103564600
It is in the context of C++.
Go ahead and bypass the compile-time type checking to pass a std::vector<int> into a function that works on a std::vector<std::string>. Let me know how that goes for you.
>>
>>103564666
Multi threaded is async.
>>
>>103564697
Multi threading is orthogonal to async as well.
>>
>>103564665
We maintain some patches to the compiler to add support for systems dropped by the current Go version.
Newbies like it because its easier to learn, seniors love it because thay can get their shit done quickly.
An upcoming epic is actually focused on moving a C# and Java server to Go.
Feels good man.
>>
>>103564708
What do you mean by async then? I just thought it meant multi threaded.
>>
>>103564297
Why would Rust need a spec?
>>
>>103564679
Its well known so you could probably guess by the locations I listed. I dont want to be the one breaking my legal contract.
>>
>>103564686
no erasure != no compile-time checking
dumb retard
>>
>>103564762
Its constantly devolving after all. A language and community on a downward spiral doesnt need a spec, only a rope to hang themselves with.
>>
>>103564743
Async means coroutines. You can have coroutines in single threaded environment, that's the most common situation. Like JavaScript or Lua for example.
You can also have async in multi threaded environment, where multiple native threads are used to execute coroutines. For example in Rust, it all depends on what async runtime you choose, and it limits some stuff you can accomplish.
>>
>>103564743
async is OS callbacks, not threading in the application
>>
>>103564780
>no erasure != no compile-time checking
That's not what I said in the slightest.
No erasure = run-time checking.
>>
>>103564786 (Me)
>>103564787
This is also a different but also valid interpretation of async term.
>>
File: file.png (1.48 MB, 1418x1284)
1.48 MB
1.48 MB PNG
>>103564397
this one is fully concurrent.
>>
File: naked pepefrog.png (217 KB, 655x599)
217 KB
217 KB PNG
>>103564823
I can barely understand this code.
>>
pthread.c
>>
>>103564859
skill issue.
and it's a lot simpler than the original go crap.
>>
>>103564864
>it's a lot simpler than the original go crap.
no its not
>>
>>103564859
>>103564864
anyway, it's dumb, but the original go code is retarded, no one would do that in the real world but i was asked to replicate something retarded, a lot less sloc and much simpler.
>>
>>103564870
>>103562109
lmao, ok gotard.
>>
>>103564891
yeah the rust code is literally unreadable unless i go spend 3 hours digging through the documentation for the rust stdlib
meanwhile the go code means exactly what it says
>>
>>103564785
>Its constantly devolving
And why would that require a spec?
>>
>>103564859
Also i could say the same about the original go code, it is crap, and no one would ever do that in the real world.
>>
>>103564928
This is only true if someone already knows go and doesn't know Rust. A basic fallacy.
>>
>>103564928
>>103564937
The issue is not the language here.

Also no kidding you can't read a language you don't know, my point is that if you know it rust is a better language.

Go will be easier to learn, but if you master both rust will be a much more productive and readable language.
Also less prone to mistakes, you can do race conditions in go.
>>
>>103564958
Also, I'm not even sure the original go code makes sure there isn't two function doing the same compute at the same time, mine does.
>>
>>103564937
What don't you understand about the Go code, compared to what I don't understand about the Go code?
>>
>>103564973 (me)
compared to what I don't understand about the Rust code*
>>
>>103564891
>>103564864
there's literally a second vector and operations to copy between the two, on what planet does that constitute simplicity?
>>
>>103564973
mpsc:
multi producer, single consumer
https://docs.rs/tokio/latest/tokio/sync/mpsc/

pinning is to give a garantee that the memory location won't change during runtime, there are other ways to do it, but it's a safety feature.
>>
>>103564958
>rust will be a much more productive and readable language.
rust is second only to c++ in inherent unreadability
i'd literally rather read forth and lisp shit than fucking rust. stop acting like it's ocaml, because it's not.
>>
>>103565013
>>103564973
len is length of the vector

i get the 2 last elements of the vectors because we want to compute fib.

drop is to drop the handle to the lock, so that other threads can lock the vec whilst computation is running, also so that i can write to it, because you can only have one writer at a time with rwlock.

i make a semaphore to make sure only one function is doing compute at a time to not do the same computation multiple times concurently to not waste cpu, i drop the semaphore so that another may acquire it if it does compute.

while let is basically reading a channel, there is other ways to do it some simpler, you could make a stream and just do for_each

extend a.extend(b) means add all of the elements of vec b to vec a
>>
>>103565025
bullshit, it's one of the easier language to work with and i got years of experience with it and others.

you don't have to use all the features of the language and can keep it pretty minimal and simple, but it gives you power when you need it
>>
>>103564973
do you really need the demo of parallelism, i did in previous code but sure i can do it if you want

just do for _ in (0..100 {
tokio::task::spawn(async {
your bullshit task
})
}
>>
File: 1719385299685924.jpg (31 KB, 628x182)
31 KB
31 KB JPG
i see you totally skipped my examples :]

okay retards, here comes PHP parallelism
if ($e = Process::init(['role'=>'auto','group'=>'test'])) {
exit(1);# failed
}
if (Process::has_master()) # worker
{
Process::on_command(function(string $name, $data): void {
if ($name === 'compute')
{
offload(Promise::Func(function() use ($data) {
###
for ($x=0,$i=0; $i < $data; ++$i) {
$x += $i;
}
return Process::info('computed-result', $x);
}));
}
});
halt();
}
$JOB_DONE = false;
Process::on_info(function(array $info) use (&$JOB_DONE) {
foreach ($info as $e)
{
if ($e[1] === 'computed-result')
{
$JOB_DONE = true;
echo "> result: ".$e[2]."\n";
}
}
});
$r = await(Process::start(__FILE__));
if (!$r->ok) {
exit(1);
}
$pid = $r->value;
$num = rand(1000, 9999);
echo "> started process pid=".$pid."\n";
echo "> asking to compute sum to ".$num."\n";
$r = await(Process::command(
$pid, 'compute', rand(100, 999)
));
if (!$r->ok) {
exit(1);
}
await(Promise::Func(function(object $r) use (&$JOB_DONE) {
return $JOB_DONE ? null : $r->promiseDelay(300);
}));
echo "> exit\n";
exit(0);


indeed, its bigger than your cryptotroonerism, but easier for digesting.

asynchronicity is not about algorithms, retards.
>>
>>103564801
>No erasure = run-time checking.
no erasure != required dynamic dispatch
dumb retard
>>
>>103565060
>it's one of the easier language to work with
Which has nothing to do with whether or not it's readable, and yet even this is nonsense. The affine type system makes working with the language inherently more difficult as *part of its design*.
Rust is not a simple language and it's not designed to be easy to work with. Nor should it be, because that would defeat the entire fucking purpose of the language. Why are you flagrantly lying through your teeth to defend a fucking programming language? What the hell is wrong with you?
>>
>>103565081
[filtered]
>>
>>103565136
nta
>Rust is not a simple language and
"simple" is a made up metric. "small" is a better one. and rust is relatively small (go < rust <<<<<< c++).
>it's not designed to be easy to work with.
being easy to work with always was, and always will be a priority. it is a big reason for the language's success even.
you're clearly a retard who is just recycling /g/eet talking points thinking they are real. the attempty at deflection was as transparent as the average /g/eet retardation.
>>
File: file.png (2.9 MB, 1595x1946)
2.9 MB
2.9 MB PNG
>>103565078
>>103564973
here is an example of a few ways you can then run it concurrently !
>>
>>103565233
also, concurency limit can be 0 or None which mean unlimited
>>
>>103565090
Reified generics absolutely require dynamic dispatch or a cognate like dependent typing. Their entire fucking reason for existing is because dipshits (like you, evidently) who think they can write code that acts like it's dependently typed in a language without dependent types and a proof system.
>>
>>103565233
there are a few other ways such as making a vec of futures and joining it.
>>
>>103565171
why are you filtered by such a primitive examples?

before diving into algorithms and into multiple communicating processes/threads, show the basis, basic example that you can do.

you say PHP is too big and slow, but computation may be separated, compiled separately and put in a binary that PHP will call, so the performance wont be much different.

>>103565078
i can run those in windows batch file, like:
@echo off

start "" cmd.exe yourPerfectJob.bat
start "" cmd.exe yourPerfectJob.bat
start "" cmd.exe yourPerfectJob.bat
>>
>>103565200
>you're clearly a retard
you opened your post to argue about semantics and objective measures, and speak nothing of any actual objective measures. who can possibly take anything you say seriously when you only pay lip service to your virtues?
i will hold you too them. let's see that <26k LOC commented implementation of a rust toolchain and stdlib. a small language can be implemented in far less space than that, but let's be generous as that's about the size of hamlet.
>>
>>103564219
Go builds actual complex software via simplicity and scalability. If literally sole lone developers can use it to EASILY build useful fully featured software, obviously a whole team of people could create a lot more with it.

Things like Rust just build like, a support beam lol. I mean that is really literally what it's for. Kernels, whatever crap like that, largely. Redundant repetitive things which people use to build new, novel, inventive things. Nothing not already done 100000 times before. Probably at that point more fun to be a real engineer and work on building the hardware itself.
>>
>>103553290
>>
>>103564627
yeah bcs ur young, stupid and have no wife and you dont own a house
it will come
>>
>>103565254
guess what language has reified generics, monomorphization, and dynamic dispatch when the user wants it? it has been mentioned a lot in this thread.
and remember that this chain started with pointing out how gophers looked for inspiration from java (retarded type erasure), and you(?) replying with:
>limbo's generics as well as java's generics are pretty much entirely derived from C++'s generics.
>>
>>103565399
There are none because there aren't even multiple Rust compilers. The language is as bloated and complex to implement as sepples. The retards who think it's simple will turn around and say shit like C# or Clojure are also simple.
>>
File: file.png (994 KB, 1071x1070)
994 KB
994 KB PNG
>>103565233
btw, here is another reason streams are nice, i can compute the sum just like that:
>>
>>103565426
yeah seriously why dont people create new kernels and new approaches to computing?
the core stuff of computing is 50 years old ideas and nobody dares to change them
in 100 years nobody will know how it started just how to maintain it, proably everyone will think its alien tech
>>
>>103565582
you are actually wrong, there are other compilation backends, one of which is cranelift.
>>
>>103565634
also, the core language itself is not that bloated to write a compiler for.

you don't have to rewrite the stdlib...
>>
File: file.png (368 KB, 748x646)
368 KB
368 KB PNG
made a small error with my locking mechanism in do_fib.

either way, that's only because i chose to use a vec which is more efficient than a hashmap, so the order needs to be preserved but i'm not rewriting values again and again, much faster to access too.
>>
File: file.png (139 KB, 565x316)
139 KB
139 KB PNG
>>103562109
lmao your shitty go program crashes if num to fib is just a hundred, my rust code can do billions. you also have deadlocks:
>>
>>103565608
It's autism. Autists can't handle change. See also the C programmers when Rust autists came in to their kernel. Both groups are extremely, insanely autistic. If you ever met these people like >>103566122 or whatever, it's literally like meeting a disabled person.

I don't know if you've ever come across autists in real life but they're really fucking disabled. Like way worse than you think, and almost always stink.

Autists just want like rigid repeitive routine. Kernels every day. Same shit. Extremely autistic things to dive into and obsess over.

Autists are not really good at creating useful stuff. Hence obviously they work for others to produce the useful ideas invented by others.

Is any of this inaccurate?
>>
>>103566457
>>103566457
that's me yes, yes i'm actually diagnosed with autism.

however, i have very good hygiene, i'm almost ocd about it, and no i have a pretty normal life besides a few obsession with my center of interest.

i even have a gf and i live in the swiss mountains and hike pretty often so i'm not lacking grass touching lol.

and no, i do a bunch of stuff, some of which are more artistic, some of which are more useful.

all in all i'm doing pretty okay considering the circumstance i think.

autism can have draw back but you can aleviate a lot of them if you are high functioning.

the most crippling things in my day to day life is OCD and not having enough free time to pursue all the things i obsessively wanna learn and do.
>>
File: file.png (1.61 MB, 1277x1421)
1.61 MB
1.61 MB PNG
>>103566546
i misquoted the post id, i meant yea i'm the guy you mentioned ie >>103566122

here is some proof with me making it work with bigint
>>
>>103565608
>yeah seriously why dont people create new kernels and new approaches to computing?
waste of time
linux is a beast greater than any person or company at this point and is basically massively shared tooling
The utility of most software is interoperability, so if you try a new approach, it's going to be useless for many years
Look at programming languages for instance, it takes in some cases decades for them to become useful because they need to have tons of libraries
>>
File: fuck the 4mb limit.gif (3.87 MB, 485x135)
3.87 MB
3.87 MB GIF
>>103566376
>>103566590
Works on my machine.
I know it's slow, but I never intended my original code to be fast, it was slow on purpose since there was a big thing about a language performance comparison recently and one of the things it measured was a dumb recursive fib. I made it use channels and goroutines just as an excercise and because Go makes it so easy. Additionally it's way easier to understand than your convoluted Rust solution, since it's just simple functions communicating pieces of information across channels. You don't need any of the locking mechanisms you're implementing which I did actually have while I was writing my Go code but I removed them because a pure channel implementation was simpler. I'm sure I could make the Go code faster because the there is a lot of needless overhead and I could buffer the printing in batches instead of 1-by-1, but you could always make the Rust code win because you there will always be some magic stdlib function that's hidden 7 layers deep under pairs of ::'s. That doesn't make it the better language, it just makes it more like C++, the very thing Go isn't trying to be.
>>
File: file.png (2.98 MB, 1274x2160)
2.98 MB
2.98 MB PNG
>>103562109
>>103566556
i consider it a win against go lol your program would crash with those numbers.
>>
>>103566643
>>103566646

i only did such a locking mechanism because i used vec instead of a hashmap and the insert order needed to be preserved, using a vec is more efficient and you don't do as much useless inserts.

i could also make the rust version better in tons of ways but that was just a way of showing nothing prevent rust from doing it, heck i could have copied your exact same way of doing it and it'd probably have been simpler since i'd not have to write a bunch of stuff as they are onliners, i just didn't like it.

your example of printing in batch is typical, i could just use chunk() on my stream and be done with it, whereas in go you'd need to push to an array within a for loop and whatnot.

anyway, there are tons of go code that require 20+ sloc which are oneliners in rust.

heck sometime a whole go file can be turned into a few rust function chain with iter().chunk().map().filter() etc...

anyway, i think you can write most things in go, but i don't think i see a scenario where rust wouldn't be a better pick.
>>
>>103566693
>there are tons of go code that require 20+ sloc which are oneliners in rust
And for every one-liner you get to enjoy in Rust, there are hundreds of hours of compiler engineering behind it to ensure that the language balloons in complexity and reaches the same heights as C++.
>>
>>103566737
No, those are defined in std and libraries.
you can easily create new function that allows you to make more oneliners without touching the compiler...

the compiler is not that complex most of it is the safety checking stuff which you could just not implement if you wanted.
>>
>>103566737
>>103566761
also, what's your issue ?
i don't care about how complex the compiler is, i care about having a productive tool.

meanwhile go doesn't even use llvm or a known compiler and doesn't benefit from decades of compiler optimisation.
>>
>>103566772
>>103566737
also fun how you are moving the goalpoast to "muh compiler"
>>
>>103566772
yeah it uses a better and faster one
>>
>>103566837
binary won't ever be faster, it does not do tons of optimizations, how is it better exactly ?

also cross platform support lmao, you can target nearly all architecture with rust, and then there is embeded.
>>
>>103566872
you are stupid as shit
Go is more portable than your useless troon shit
>>
>>103566945
alright, show me a list of all the cpu architecture supported.

there is no way in hell it supports more architectures than llvm
>>
>>103566945
also fun how you go about the troons, they are a vocal minority and it's mostly a nsa psyop to keep software unsecure.
>>
>>103566772
>>103566872
>also, what's your issue ?
>how is it better exactly ?
Freshly pulled from Github:
Golang repo size: 375.56MB,
12391 files,
and 2,487,906 lines of code for the entire language, compiler, stdlib and all.

Rust repo size: 541.97MB,
50802 files,
and 2,171,722 lines of code for just the language, stdlib, and the LLVM IR compiler.

LLVM repo size: 1.66GB,
148,222 files,
and 17,033,342 of code, just to compile Rust's LLVM IR.

Which one of these do you think is more maintainable, and sustainable, as a piece of technology? Which one do you think is easier to understand not only as a user but as someone who might have to work with the guts and insides of one of these systems, possibly even comprehend how it all works?
Because it's definitely not Rust. Nobody is going to wrap their heads around a 17MLOC compiler.

>>103566982
Who cares how many random architectures you can build Go for? It supports the only ones that matter: x86, x64, and ARM. Why are you even pretending like anything else is relevant?

I wrote this entire post during the time it took me to download and check the lines of code for LLVM. My laptop fans were spinning at max the entire time. How is this the computing of the future?
>>
>>103567014
still rust because go is a language that suck and is written in go.

i'd take 2.1 millions lines of rust over 2.4 millions lines of go, heck even if it was 500k lines of go i'd still take rust.

also, you seem to ignore that llvm isn't the only rust backend.
>>
>>103567014
fun how gopher keep saying what about rust
and we say "yes but who cares" and you are like "oh no it's important".

but whenever we point out something go lack then the gophers are happy saying "who cares".

this has happened a few time in this thread already, and when you are cornered you just change the subject because you cannot win.
>>
>>103567014
you do realize you are arguing with jobless welfare autists coding Rust on their 128GB of RAM shiny RGB LGBT battlestations right?
>>
>>103566982
>there is no way in hell it supports more architectures than llvm
NTA, and AFAIK Rust doesn't support all architectures supported by LLVM
here's the list of targets supported by the Go compiler:
https://go.dev/doc/install/source#environment (ctrl+f "The valid combinations of $GOOS and $GOARCH are")

and here's the list for Rust:
https://doc.rust-lang.org/rustc/platform-support.html
>>
>>103567048
not jobless and 32GB, my computer is 8 years old and i'm upgrading next year.

i don't game either.
>>
File: lol.jpg (8 KB, 239x211)
8 KB
8 KB JPG
>>103567032
>still rust because go is a language that suck and is written in go.
>>
>>103567049
yea i tried to post it but 4chan didn't let me.
either way rust still wins on that list.

anyway, it's not even that i'm so "pro rust" and i think "it should replace everything".

i just fucking hate go for being a retarded language.

and people claiming it's better than rust is just a ridiculous statement to me.

whenever we win a point in the argument they either move the goalpost or ignore the argument and move on to something else they are gonna lose again.
>>
>>103567055
we already confirmed that rust is more readable so yea.
>>
>>103567075
if you think this, you are retarded.
>>
>>103567088
if err != nil {
hur durr
}
if err != nil {
hur durr
}
if err != nil {
hur durr
}
if err != nil {
hur durr
}
if err != nil {
hur durr
}
>>
>>103567094
>if err is not nil, hurr durr
>if err is not nil, hurr durr
>if err is not nil, hurr durr
>if err is not nil, hurr durr
>if err is not nil, hurr durr
What exactly is unreadable about this?
>>
>>103567104
the issue is more that it represent 40%+ of a go codebase, it's visual vomit, and it's only one of many things in go that look like shit and make things more convoluted.
>>
>>103567113
>garbage personal opinions
I also think that every C++ and Rust codebase I look at is visual vomit.
>>
>>103567113
The design choice is clever and intentional. It is annoying but so are error paths in general, nobody wants to deal with them. Research has shown that nesting is the worst thing about a code's readability, by far. So they chose to do something akin to an inline to avoid nested try and catch. That's the logical reasoning, as well as the fact it is very explicity and clear.
>>
>>103567123
well whatever, i know both go and rust and i find rust much more readable.

do you even know rust ?
if not learn it, be proficient at it to the point you can build pm anything with it, then come back and tell me you still prefer go.

i've had to use go in a former job and oh god never again, not only it is a shitty language, it encourages design principles that turns a lot of codebase into shit.

i've both had to contribute to existing go and rust codebase and the go ones always were more of a pain to do anything with.

i can work with both, but i'd just rather not.

heck i'd prefer fucking java over go and i hate java.
>>
>>103567151
>do you even know rust ?
I started working through the Rust book until I realized I should probably be learning a language that people are actually usually employed for. I don't regret not learning Rust since it is just another over-complicated and over-engineered solution to simple computing problems, at least in the contexts most people use it in.
>>
>>103567141
go's error handling is subpar at best, there are many silent errors that can happen, you are not even forced to deal with them.

with rust, either you have to use unwrap / expect (which is easy to search for with grep / rg)

or you use ? or if let.

there is no way to use your data without dealing with errors one way or another.

it is not unfrequent that people use unwrap for deving purpose, then use rg / grep to find all cases of them or expect and deal with them apropriately.
tell me how go is better about the way it goes at it.

you end up with rust codebases where errors are almost never unhandled.
>>
>>103567170
so i can agree on one thing, rust is not the simplest language to learn.

if you have 2 programmer and they both have to learn either go or rust and build something within a week, i'd probably bet with go yes.

but if you have 2 programmers that both master their language, one go, the other rust and we assume they are on the same intellect level, i'd definitely bet on the rust dev.

honestly working with rust was not super fun for the first few days.

then you get an instinct on what you can and cannot do and it just goes smoothly without thinking about it, once you are there i find it very comfy, i can just build what i want without having to think about it.
>>
>>103567173
>tell me how go is better about the way it goes at it.
You get an error value. It tells you if there was an error. You can check it and stop, check it and see what type of error it was and do something based off of that, collect it into a pool of errors that will be evaluated later after everything returns, ... etc. It's just a value. You don't have to think about the complicated dynamics of handling unwraps and option types. The error is nil or it wasn't. Even if there was an error, you are just given an empty value.
>>
>>103567213
yea but my point is you can simply ignore the error value and not check it.
rust forces you to deal with errors.

but it doesn't force you to do if bullshit each time, you can just use "?" after your thing that may result in an error and let your error type manage it

where your function returns a Result<output_you_want, your_error_type>

one example of that is that in a company project i have an error type that's pm general accross the project, and it can handle all the errors including logging precise backtraces when -vvvv is used with the program.

the errors however do not stop the program because it must keep going to finish its job.
>>
>>103567234
>>103567213
one thing nice about that design is that there is isolation of tasks and errors are backpropagated up.
however i do not have to think about them too much.

it allows me to separate the error handling code from the code that does the work and makes things not only less repetitive but also simpler to read.
>>
>>103567049
sorted
for Go:
386_android,386_freebsd,386_linux,386_netbsd,386_openbsd,386_plan9,386_windows,amd64_android,amd64_darwin,amd64_dragonfly,amd64_freebsd,amd64_illumos,amd64_linux,amd64_netbsd,amd64_openbsd,amd64_plan9,amd64_solaris,amd64_windows,arm64_android,arm64_darwin,arm64_ios,arm64_linux,arm64_openbsd,arm64_windows,arm_android,arm_freebsd,arm_linux,arm_netbsd,arm_openbsd,arm_plan9,arm_windows,loong64_linux,mips64_linux,mips64le_linux,mips_linux,mipsle_linux,ppc64_aix,ppc64_linux,ppc64le_linux,riscv64_linux,s390x_linux,wasm_js,wasm_wasip1

architectures only:
386,amd64,arm,arm64,loong64,mips,mips64,mips64le,mipsle,ppc64,ppc64le,riscv64,s390x,wasm

for Rust:
tier 1: aarch64, i686, x86_64
aarch64-apple-darwin
aarch64-unknown-linux-gnu
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-linux-gnu
x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-unknown-linux-gnu

tier 2 w/host tools:
aarch64-pc-windows-msvc
aarch64-unknown-linux-musl
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
armv7-unknown-linux-gnueabihf
loongarch64-unknown-linux-gnu
loongarch64-unknown-linux-musl
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-linux-musl
s390x-unknown-linux-gnu
x86_64-unknown-freebsd
x86_64-unknown-illumos
x86_64-unknown-linux-musl
x86_64-unknown-netbsd

tier 2 without host tools (too lengthy so I'll only list architectures):
aarch64,arm,arm64ec,armebv7r,armv5te,armv7,armv7a,armv7r,i586,i686,loongarch64,nvptx64,riscv32i,riscv32im,riscv32imac,riscv32imafc,riscv32imc,riscv64gc,riscv64imac,sparc64,sparcv9,thumbv6m,thumbv7em,thumbv7m,thumbv7neon,thumbv8m.base,thumbv8m.main,wasm32,x86_64

IIRC Go used to support powerpc. also doesn't support loongarch.
ARM is rather big and I'm not wasting more effort on this shit

I can see that while Rust supports more architectures, Go and Rust are more or less on par regarding mainstream architectures
>>
>342 replies
kekk
>>
>>103567300
honestly i'm fine with this thread dying, it was getting anoying lol.

anyway, in most cases you can't convince someone.

crustaceans are gonna stay crustaceans and gophers are gonna stay gophers.

people only switch when they themselves end up seing the truth.
>>
File: pope gopher.png (1007 KB, 1170x647)
1007 KB
1007 KB PNG
and the truth? well....
>>
>>103567348
lol keep beliving
also fitting that you use the corrupt pope as the holder of your idol.
>>
>>103567348
>>103567367
only one that master boths can know the truth.
>>
>>103567348
holy based
>>
>>103564786
>Async means coroutines.
No. You can do async in other ways (like with callback functions or futures) but coroutines are a lot nicer than most of the other options.
>>
>>103567234
>yea but my point is you can simply ignore the error value and not check it.
You know that you can’t accidentally ignore an error, right? The compiler forces you to either knowingly
value, _ := canReturnError()
or handle it somehow since it also doesn’t let you define variables and then never use them
>>
>>103567444
you just confirmed what i said.

you ignored the error.

in rust you cannot access the data without handling the error.

the only way is to use unwrap / except, which are are trivial to search for in a codebase.
>>
>>103567444
that's only true if you don't reuse the variables.
a subsequent call that assigns to a previous err variable will not force you to do anything with those values
>>
>>103567444
>>103567485
my point is that because of tech debt you'll end up with huge codebases where this is done a ton, and it can become a pita to find and fix later.
also this >>103567487
>>
>>103567485
why shouldn't it be possible to ignore an error? that's my prerogative.
>>
>>103567498
nobody does that a ton, if at all, especially not in professional settings
so yeah once again the hobbyist nature of Rust is uncovered
>>
File: file.png (20 KB, 308x65)
20 KB
20 KB PNG
>>103567515
you should be able to ignore an error, but only in a way that would be easy to search for, example :

otherwise it will inevitably accumlate in codebase and lead to errors that'll bite you in the back in prod.
>>
File: file.png (25 KB, 404x70)
25 KB
25 KB PNG
>>103567540
if i actually search for unwrap( or except( because unwrap_or is not it.
>>
>>103567534
lmao, i've seen that a ton in prod codebase, and i've seen production crashes because of it.
>>
>>103567564
>>103567534
the whole point is that you *can* do it when you shouldn't be able to in a way that's not easily searchable.
>>
>>103567540
grep .*, _(:=|=)
>>
>>103567571
doesn't fix >>103567487
>>
>>103567580
That doesn't matter. In order to ignore the error value you still have to be conscious of the fact that the function you are calling one is returning one.
>>
>>103567571
>>103567580
also doesn't fix things that don't return a value.
>>103567590
not my point, my point is that you'll end up with unhandled errors in the codebase which yes were conscious decision at the time because of tight schedules and whatnot.

but it'll bite you in the back in the future and it makes it a mess to check all code path to be sure there is no unhandled errors.

good luck finding all unhandled errors on a 500k lines codebase, in rust this is trivial to do.
>>
>>103567564
I don't know what to tell you, you worked with shit colleagues on a shit codebase with no standards

it would never cross my mind to just ignore an error, even in development, and i've never seen anyone do it, not to mention your tests should cover error paths holy shit.
>>
>>103567605
>if you ignore errors there will be problems later
This is why you aren't supposed to just ignore errors, and it's why there are if err != nil checks all over the place. Because Go is for real software.
>>
>>103567607
i've worked on both.

but to that i can add a futher point.

i see tons of pajeet go devs, i don't see a lot of pajeet rust dev.

because the bar to entry in rust is higher you generally have much less bad rust engineer than bad go engineer in my experience, it's a nice filter.

if i have to work on a team and 5 developpers in the world will be randomly picked, and either they are go devs or rust dev, regardless of which language i prefer i'd go with the rust team because i expect them to be more proficient.
>>
>>103567623
my point is that it is something that DOES happen.

and it is good if you can easily search for all the places where it happened when you wanna fix it.

som unhandled errors can be really hard to find in existing codebases mostly because of : >>103567487
>>
>>103567638
>and it is good if you can easily search for all the places where it happened when you wanna fix it.
Saying that Rust is good for your personal hobbyist projects because you get to ignore all errors before cleaning them up later isn't a very strong sell.
>>
>>103567623
i can frame it another way, what is the worse rust software you know that has over 10k stars on github.

i'm pretty sure i can find a lot of go projects with more stars that are rotten to the core.
>>
>>103567655
I have a better challenge, you find me a Rust repo that is as important and integral to the world of software development as Docker & Kubernetes are
>>
>>103567649
no, you don't ignore the errors either, like go, professionals don't do it.

my point is that you can SEE where all those ignore were made, whereas in go it is harder to see.

again, there is only a single expect / unwrap on the rust codebase i shared, and there is a very specific comment explaining why the error is not handled.
>>
>>103567673
>the grep searches i can do for my language are better than the grep searches you can do for your language (in this one specific scenario)
You are demented.
>>
>>103567666
fun how you refused to play the game because you knew you'd lose this one.

also Docker and Kubernetes are proper example of software that terribly suck.
>>
>>103567605
>but it'll bite you in the back in the future and it makes it a mess to check all code path to be sure there is no unhandled errors.
you see this is the difference between rust and go devs, go devs don't consider error handling to be an afterthought.
>>
>>103567684
it's not about grep search, it's about tooling.
a grep search is enough for rust.

give me a tool that'll show me all unhandled go errors.
>>
>>103567688
well rust engineer neither.
but the thing is, rust devs consider safety to be one.

go is not memory safe, it can very easily do race conditions without the compiler telling you.

memorry errors bugs are even worse than typical error, and go doesn't address those properly.
>>
>>103567687
>also Docker and Kubernetes are proper example of software that terribly suck.
Still more important than the entirety of Rust.
>>
>>103567695
https://github.com/kisielk/errcheck
can be integrated into your linter
>>
>>103567710
ad populum.
nice once, we are talking about which is best to use, not which has been used the most up until now.

by your logic we should all use php, c, java and javascript.

by your same logic go should never have gotten popular because it hadn't been used on influential project when it released.
>>
>>103567687
substantiate why you think kubernetes "terribly sucks"
>>
>>103567717
still won't check memory corruption errors such as race conditions lol.
>>
File: Go_gopher_mascot_bw.png (128 KB, 1200x1200)
128 KB
128 KB PNG
>>103567709
>it can very easily do race conditions without the compiler telling you.
go run/test/build/install . -race


>>103567728
>ad populum
Yes, Go is popular. Because it solves real problems that people have during the difficulties of software development.
>>
>>103567737
i was more talking about docker, kubernetes is alright.
>>
>>103567740
goalpost
>>
>>103567748
it is popular because it was literally designed for retards that shouldn't code in the first place.

lmao, this won't work in a lot of case.
>>
>>103567748
>>103567763
also the same language that bitch about unused variable will make such important checks optional lol
>>
>>103567763
More like Go was designed so that people could actually code without the language getting in their way.
>>
>>103567780
my point is that it literally does get in your way, i'd legit rather use java
>>
File: 1732137779847.jpg (88 KB, 1280x720)
88 KB
88 KB JPG
>>103567789
Then go use Java.
>>
>>103567794
no, because i got rust which is a much better language than either.
>>
>>103567709
>>well rust engineer neither.
>but i need to be able to not handle my errors at first and then when my project has 5k LOC i will grep through it all
>it's not an afterthought bro!
>>
>>103567805
i never not handle errors, my point is that i've seen go codebases where errors where not handled, and finding those is a much more tedious job than with rust.

also your fucking language can ignore errors.

rust you don't ignore them, unwrap is not an error ignoring, it mean panic if the error happen.
>>
File: retarded.jpg (8 KB, 200x280)
8 KB
8 KB JPG
>>103567801
>my bare-metal systems language is better than general purpose network service languages (one of them runs on a VM)
>>
>>103567818
rust is better than go even in the niche go is supposed to be good at.
>>
File: come on man.png (1.2 MB, 963x940)
1.2 MB
1.2 MB PNG
>>103567827
Is that why nobody uses Rust for network services and Go is raping that area and increasing in dominance and usage every year?
>>
>>103567836
also wrong.
cloudflare's networking is literally written in rust, our posts go through some rust binary as we speak.

there are tons of network services made with rust.

also, ad populum again, and rust is gaining traction anyway.
>>
File: 1733495935636.jpg (67 KB, 750x678)
67 KB
67 KB JPG
>>103567861
>ad populum again
Yes.... Go is popular. For a reason.
>>
>>103567872
are you saying php and java are better than go ?
>>
File: erika (rat).png (180 KB, 627x650)
180 KB
180 KB PNG
>>103567881
Nobody uses PHP except PHP dude. It's a dead language.
>>
File: OIPIFunny.com.jpg (21 KB, 474x355)
21 KB
21 KB JPG
go compile fast.
rust compile slow.
>>
File: file.png (146 KB, 916x1132)
146 KB
146 KB PNG
>>103567889
still doesn't change the point for javascript, java and a tons of shitty languages used more than go.
also you lose on the polls of what people like using the most
>>
File: wtf3.jpg (296 KB, 1397x1606)
296 KB
296 KB JPG
>>103567910
>muh dumb internet shit
How about furry anime girls?
>>
>>103567895
features have a cost, you are only admiting that your language lacks feature.

by your logic you should use C and tcc as it's really fast to compile.

also, rust isn't that slow to compile, you can compile big ass projects in less than 0.5s on an 8yo computer, and that's without even using cranelift.

most of the time is actually spent linking and not compiling, and you can easily change your linker to something like mold and make builds much faster.
>>
File: wtf.jpg (754 KB, 1901x1391)
754 KB
754 KB JPG
>>103567920
me and you
>>
>>103567815
>rust you don't ignore them, unwrap is not an error ignoring, it mean panic if the error happen.
This is exactly equivalent to what you think “ignoring” errors in Go entails
>>
>>103567949
nope, because in go if you ignore an error, it'll continue the flow of execution and run things that may possibly not crash until you end up crashing your program or fucking your data up.

in rust it'll immediately stop the program.

that's a dummy example but imagine something like this pseudo code.

get data from db
delete that file
create that new file with that data.

in rust you'd panic at get data from db if you ignored the error.

in go it'll delete the file and crash at the create spot.

bear in mind that's a dumb dummy example but i could imagine more realistic scenarios where it'd really fuck things up.
>>
>>103567973
tldr, in rust if you want to do anything with data, you have no choice but to handle the error case.
>>
File: my wife beatrice.jpg (143 KB, 997x1165)
143 KB
143 KB JPG
>>103567973
>>103567988
>>
>>103567920
>features have a cost, you are only admitting that your language lacks feature
The thing about costs is that some things are overpriced. And you can go somewhere else if you don't want to pay them.

>by your logic you should use C and tcc as it's really fast to compile.
yea C is good too, or Odin/Zig. Its just a bit of hassle for performance that I don't really need. Would rather get something up and running quickly that just works.

>also, rust isn't that slow to compile
maybe, especially if you're jumping through hoops. But Ive seen the video of the 7+ minute compile times
https://www.youtube.com/watch?v=T1GWT0FP7hQ
>>
File: 1717058414393920.jpg (407 KB, 1920x1080)
407 KB
407 KB JPG
>>103565634
Code generation from IR isn't a "Rust compiler", and don't get me started on a 200k line "back-end".

>>103565645
>also, the core language itself is not that bloated to write a compiler for.
The type system alone is more complicated than a Prolog, and several orders of magnitude more complicated than a Forth or Lisp, and that's just dealing with the type system.

The implementation can be anything. It doesn't have to be an optimizing compiler. Let it be the absolute simplest implementation of an interpreter. HaMLet is exactly that (though it's far from the smallest SML implementation to ever exist, it's just the standard reference one!) Here, let's disregard the stdlib for a second and do some comparison with hard numbers.

Rustc has 558k lines of Rust code and 110k lines of comments. That's half of a compiler. Do you have any idea how fucking absurdly large that is?

GHC has 277k lines of Haskell code and 177k lines of comments, and 5k lines of Yacc. This includes the whole fucking package, the entire (optimizing) compiler and its many back ends, the linker, the intermediate STGM and everything that comes with that, as well as the extremely sophisticated runtime.
Haskell is a gigantic language which is bloated beyond belief and has more syntactic sugar baked in than you can shake a stick at.
And yet the entire toolchain with all of the above is less than half the size of rustc.

Go's entire toolchain is ~50k meaningful LOC.
tcc is 45k.

Now given all of this information, let us think for a moment. Can we truly call something where HALF of a compiler is nearly twice the size of a fucking huge language, and 10x the size of some medium weight languages, a "small" language? No. I don't think that we can. I think you have no idea what the fuck you're talking about. Rust is easily as bad as C++ and there's a reason only rustc exists. For fucks sake, stop being a retard. I get you like the language, don't white knight for it like an ignorant faggot.
>>
>>103568032
cranelift allows you to compile much faster
we also have gcc backend that no one uses.
>>103568032
and ?
a strong typing system is good, also a complicated typing system does not mean it'll result in a much more complicated compiler.

and ?
a large codebase isn't necessarily a bad thing.
if a thing needs a lot of code to be done that's just how it is.

and i'd rather have my compiler to have a large codebase, than having to write a large codebase to do a trivial thing.
>>
File: i didnt want to do this.jpg (61 KB, 1280x720)
61 KB
61 KB JPG
>>103568067
holy esl retard
>>
>>103568075
how does knowing more than one language makes me a retard exactly ?
can you say the same ?
>>
File: GaXwdIEX0AABcHf.jpg (161 KB, 1170x1066)
161 KB
161 KB JPG
>>103568081
>>
>>103568102
what are you trying to convey to me lol
>>
>>103568108
>>
>>103568067
Wasnt a tranny (you perhaps?) crying about you do what go does Go does in 10 line in one line of rust code?

The compilers prover otherwise. The go compiler does so much more in less lines than rust, and rust still has to piggyback on C++ LLVM to do its codegen.

So in rust you do less with more lines of code.

Btw, Go has a GCC, LLVM ports too. We dont need to use them unless in very soecific circumstabces because the Go cross compiler is so good.
>>
>>103568067
>and ?
And it's not a small language, as you asserted it is. And with it inarguably on display, you continue to grasp for anything to argue about. What the fuck is wrong with you?
>also a complicated typing system does not mean it'll result in a much more complicated compiler.
Look at the stupid shit that you say. And for what? To continue to bicker in a domain you clearly don't know shit about and will continue to be thrashed in? Jesus tap dancing Christ dude. Sorry, I'm not doing this. Get a fucking life you pathetic loser, I'm out.
>>
File: file.png (578 KB, 772x648)
578 KB
578 KB PNG
>>103568145
weren't you the one that said go is more minimalistic ?

i'm not a tranny, i'm the guy that posted code sample to do that fib shit.

also no, rust is 2M lines of code rn i just checked.
go is 2.3M so go has more code, whilst having less language features, kinda proves my point.
>>
>>103568170
> i'm out
good.

yes a more complex type system will mean more complex compiler, but it's not like the relationship between the two is exponential.

> you continue to grasp for anything to argue about

it's gophers that keep moving the goalpost whenever they lose an argument, i at no point moved to a new topic, each time it is the gopher that did following one of my replies.
>>
File: fox portrait.jpg (116 KB, 880x1024)
116 KB
116 KB JPG
>>103568214
>>
>>103568228
not a furry but cute one
>>
By the way. Something I really like about Go is how easy the porting process is.
In Go, if you want to port the compiler to a completely new platform the process is as such;

(From Aram Hăvărneanu):
1. Add GOOS/GOARCH support to the toolchain
2. Add some support for GOARCH in cmd/internal/obj
3. Add some support for GOARCH in cmd/asm
4. Add some support for GOOS/GOARCH in cmd/link
5. Iterate through 2-3-4 until you can produse some kind
of binaries from assembly files. Depending on the specifics
of GOOS/GOARCH you might, or might not need to use external
linking.
6. Once you can produce binaries, thoroughly test them (link
just assembly programs, without runtime). Basically make
sure the low-level toolchain works.
7. Start working on the Go compiler for GOARCH.
8. Write a minimal alternative runtime for Go. The runtime
is much too complicated as a first test Go program. Basically
write your own runtime in assembly that is just stubbed
out, but can run a good bulk of the programs in go/test.
9. Once that works well enough, start using the real runtime.
This requires implementing a lot of assembly, but you can
use the lessons learned from #8.
10. Make all the tests in go/test work.
11. Make all the stdlib tests work. You are still working
amd64 now, and executing on GOARCH with go_GOOS_GOARCH_exec.
12. Run bootstrap.bash
13. Move over the artifacts on GOOS/GOARCH machine.
14. Make sure make.bash works. You will still likely have
to fix problems to make this N-generation compiler work.
15. Make sure all.bash works.
16. Done.

Support has been added for new platforms in a matter of days (including bare metal).

In Rust, you have no control over it because you would have to depend on what LLVM decides for you
>>
File: oh no no n.jpg (127 KB, 1024x989)
127 KB
127 KB JPG
>>103568189
>rust is 2M lines
Okay... Now include LLVM
>>
>>103568239
llvm is not the only rust codegen backend.

and rust binaries are much more optimized than go binaries ever will dream to be.

let alone the fact that the language's sementics allows for better optimization.

again, go does less in more lines.

also llvm has a shit ton of IR which is not very line efficient so that's not an amazing metric.
>>
>>103568239
>>103568189
The fucking idiocy of arguing this when Go does its own Code gen to support a huge range of platforms and have its own cross compiler.
Clearly the go compiler is more effective, and does more with an equal amount of lines to rust.
>>
>>103568261
You look like this.
>>
>>103568273
no, not really.
we could just exclude the codegen part from both projects and rust would still win.

go has less features too.
>>
>>103568277
i'm a guy living in switzerland with my gf.
i'm not a tranny nor a furry.
>>
>>103568282
Prove it. The ball is in your court.
>>
>>103567300
426 now!

>>103568238
Rust faggots mentally masturbate over their shit language yet they couldn't make their own simple compliler like that and had to rely on external tools... kek
>>
>>103568293
that's called pragmatism, because we care about solving real world problems, not circlejerking over bullshit fibonnaci toy problems.
>>
>>103568290
gopher again moving the goalpost.
but sure i'll play your game if their codebase isn't so shit that everything is mixed together.
>>
File: 20210801_154729~2.jpg (1.26 MB, 3619x2237)
1.26 MB
1.26 MB JPG
>>103568313
Correction:
You look like this.
>>
>>103568306
I've never really thought about Go as a pragmatic language but I guess you are right. There really is comfort knowing that you by yourself could maintain a port of the language as needed. Without having to touch GCC or LLVM (although both are possible with gccgo and tinygo)

I hope Zig follows suit in ditching LLVM.
>>
>>103568313
NTA, but the Oberon07 compiler mogs RustC and Cranelift in this regard as well.
>>
>>103568345
well you can do that in rust too knowing llvm is not the only backend and i find rust more readable anyway.
>>
>>103568313
Also the Free Pascal Compiler. Has more support and native code gen for many escoteric platforms
>>
>>103568356
i mean it targets the jvm what's your point?
>>
>>103568327
i'm not a fucking furry
>>
>>103568367
The saddest thing with this claim is that compiling rust requires python of all things. (I know the compiler itself doesnt use Python).

But Go doesnt even need "make" to build itself.
>>
>>103568385
Then why do you look like this?
>>
File: file.png (610 KB, 817x557)
610 KB
610 KB PNG
>>103568395
rust is self hosting...
anyway, here's a small rust compiler in just 200k sloc, it doesn't do all the verifying and assume the code is correct, but you can bootstrap rust from it.
https://github.com/thepowersgang/mrustc
there are other of such projects.
>>
>>103568374
The Oberon07 compiler I talk about does code gen by itself you idiot.
https://github.com/AntKrotov/oberon-07-compiler
>>
>>103568398
nope, never wore a furrsuit
>>
>>103568423
Wrong. You look like this.
>>
>>103568419
> a 63 stars no name repo
how was i supposed to know that crap?
>>
>>103568428
keep your fetishes to yourself.
>>
>>103568416
>>No native code gen.
Sigh... You didnt even read the readme did you?
The Go compiler can release assembly too? So I'm not sure why this is relevant?
>>
File: Fz5kswraMAIey2d.jpg (816 KB, 1802x2679)
816 KB
816 KB JPG
>>103568435
Mine? They're yours. This is you. You look like this
>>
>>103568440
https://github.com/bytecodealliance/wasmtime/tree/main/cranelift
couple that with cranelift, and there you go.
>>
>>103568416
>>200K
Look at all those depedencies. How many lines of code is a C++ compiler..
>>
>>103568440
anyway, why is using llvm a bad thing exactly ?
especially when it's not the only option ?

benefiting of decades of compiler optimisations for free is a good thing imo.
>>
>>103568468
this could very well have been written in rust, the goal is to bootstrap, what's your point ?
>>
>>103565558
You are right. However I plan to own my own place in 2-3 years. No wife though, I only care for my waifu.
But no matter what, I don't think I will change my approach to programming any time. It has always been my passion. There is no job that would be more fulfilling for me than software engineering and R&D.

>>103567289
You have skipped over tier 3.

>>103567440
True, but generally when you talk about async as a language feature you mean coroutines.
>futures
Futures in Rust are nothing more than coroutines. At least the ones that you get from async functions.
Unless you mean futures as more abstract term representing some value that will be set in future. Like some fancy rpc protocols that let you use values that haven't been received yet.(Capnp does it IIRC). But that's hardly a language feature.
>>
>>103568459
Whats your point?
>> Combine a 200K incomplete compiler with an incomplete code Gen
Ok, and Go has the code code gen. GCC and LLVM.
Also, presenting something that is not self hosted and needs a C++ compiler is not a gotcha.
>>
>>103568499
sure, but they got shitty codegen that doesn't optimize for shit as the default.

i mean, the point is to bootstrap, so it'd make no sense to self host.

rust is self hosted, the rust main repo can generate ir, cranelift which is written in rust can turn IR to machine code.

the default backend is LLVM because it benefit from all the fancy optimization but you can use rust codegen + cranelift alone.
>>
>>103568499
cranelift is 160k lines of code
rust is 2M lines of code

160k + 2M < 2.3M of go, and all that with more features.
>>
>>103568475
LLVM is proven to be very hard to maintain. Fore reference it needs a small army of developers to maintain itself and has half baked support for many platforms.

If your language / compiler (not speaking about only Rustc here) is dependent on LLVM or GCC, I dont consider it something maintainable long term simply because you might have to maintain LLVM some day as well.

Also see Zig, some things that they want to do just arnt possible because they have to depend on LLVM. Im sure its the same for Rust.

Anyways, Im pretty happy about Cranelift. Im suprised that the Rust community hasnt jumped on it more.
>>
>>103568558
>>103568542
>>103568558
we could use cranelift and be fine, rust could survive if llvm and gcc disapeared overnight.

it'd come at a performance cost until it is rewritten though.
>>
>>103568558
Sigh you stupid idiot.
Does Cranelift support all the platforms that the Go compiler supports? Including WASM? RISC x86 ARM ARM64 and so on?
>>
>>103568499
>self-hosted
who gives a flying fuck? I mean, it's nice to know that your language can be used to write a compiler, but go's compiler is really unimpressive. haskell is better in this regard because GHC is actually a cool project
>>
File: file.png (15 KB, 719x85)
15 KB
15 KB PNG
>>103568588
hahaha, got you, gopher moving the goalpost again.

cranelift is retargetable, it's pretty trivial to add new platforms.

and it is only 160k sloc, if you were to do less sloc than go, cranelift + rust you'd still have almost 3 millions lines of code to go.

and sorry to break your bubble, but it already supports a bunch.
>>
>>103568601
Yeah Haskell is cool. So is Pascal and Oberon, but they are not the focus here.
>>
>>103568609
>>103568588
all in hole, we got a rust toolchain that can be fully self hosted, that does less lines of code than go by 3 whole millions whilst having a shitton more feature as a language.

how do you recover from this ?
>>
>>103568620
>how do you recover from this ?
if err != nil {
// handle err
}
>>
>>103568634
kek, nice avoiding the issue.
>>
>>103568620
>>103568609
What cranelift are you talking about again
https://github.com/rust-lang/rustc_codegen_cranelift
>>
File: file.png (447 KB, 773x419)
447 KB
447 KB PNG
>>103568644
they are the same.
it's just the codegen backend using cranelift
and now we are down to 18K sloc, it makes you look even worse actually.
>>
>>103568620
Broken targets doesnt mean much of abything. I can claim my code gen targets xyz but its all fluff unless you have it running which cranelift does not on many platforms, according to their own repo.
>> Self hosted rust.
Lol then try to self host it and see how far you get.
>>
>>103568620
You look like this.
>>
>>103568673
wrong again, it runs on the targets that matters.

also to quote probably you or at least another gopher :
>>103567014
> Who cares how many random architectures you can build Go for? It supports the only ones that matter: x86, x64, and ARM. Why are you even pretending like anything else is relevant?

> Lol then try to self host it and see how far you get.

i've actually used cranelift, so there you go.
>>
>>103568660
Ha! Did you even take a look at their build scripts? To see what they need to build?
>>
>>103568693
>>103568673
also fun how you suddenly care about targets (which rust support a lot more with the llvm backend) as soon as i show you that you don't have to use the llvm backend.

you retard.

again, gopher moving the goalpost after a loss.
>>
>>103568699
You look like this.
>>
>>103568698
what's your point exactly, the build script is a single line that runs cargo...
>>
>>103568703
no i don't stop spamming already
>>
>>103568721
>no i don't stop spamming already
>>
What a thread lol
>>
thread conclusion:
gophers seething, their shitty language compiler needs more sloc than the smallest rust toolchain and less features.

they also support less targets / platform when you use the llvm flavor of rust.
>>
>>103568760
Tell us the LOC of LLVM, rustacean!
>>
>>103568760
rust compiler : 2M
go compiler: 2.3M sloc
>>
>>103568760
>>103568763
again, i said using the cranelift backend which is 160k lines of code, even then 2.16M vs 2.3M rust still win read the thread retard
>>103568416
>>103568660
>>
File: fat fuck pepe.png (55 KB, 320x320)
55 KB
55 KB PNG
>>103568774
Okay but LLVM is 17 million lines of code.
>>
>>103568774
i quoted a wrong post, anyway.

the sum rust codebase + cranelift is 2.16M
which is lower than go's 2.3M
>>
File: file.png (432 KB, 790x433)
432 KB
432 KB PNG
>>103568795
okay but you don't need to use LLVM at all, can you fucking read.

the rust repo is 2M sloc
the cranelift repo is 160k sloc

you can have a full llvm free rust backend for 2.16M sloc
>>
File: impressed pepe.png (41 KB, 623x506)
41 KB
41 KB PNG
>>103568806
>okay but you don't need to use LLVM at all
That doesn't excuse the fact that every single Rust program uses LLVM
>>
File: file.png (197 KB, 777x227)
197 KB
197 KB PNG
>>103568774
>>103568763
>>103568660
>>103568644
>>103568774
>>103568760
>>103568795

full self hosted llvm free rust toolchain : 2.25M sloc
full go toolchain : 2.3M toolchain

on top rust has more feature.

rust wins.
>>
File: completely-normal-pepe.png (154 KB, 1024x920)
154 KB
154 KB PNG
>>103568849
Wrong. LLVM is 17 million lines of code.
>>
>>103568830
>>103568830
how's the copium ?

> that doesn't excuse the fact that almost no go program use the llvm toolchain and are thus shitty unoptimized binaries.

also you are wrong, i use cranelift a ton.
>>
>>103568858
>>103568849
can you read, you don't have to use LLVM you fucking moron.

you can use cranelift instead of llvm, and cranelift is 160k sloc.
>>
>>103568849
>>103568858
>>103568864
>>103568868

i'm repeating because you can't read


full self hosted llvm free (ie not using llvm at all but cranelift instead) rust toolchain : 2.25M sloc
160k lines of code for cranelift
2M for rust
and some more for the backend linking the two.
total 2.25M.

full go toolchain : 2.3M toolchain

on top rust has more feature.

rust wins.
>>
>>103568891
the mere fact that both compiler are written with the language itself.
and that rust manage to self host in less lines of cost whilst having more language features show that rust is a language that needs less slocs to do the same thing.

gophers seething.
>>
File: IMG_3766.jpg (68 KB, 1036x1158)
68 KB
68 KB JPG
Haskell won
>>
>>103568923
i like rust, but i'd take haskell any day over the utter shit that go is.
heck even common lisp is much better.

fuck go.
>>
>>103568891
GOPHERS SEETHING LMAO
>>
>>103568891
Ok, and if you add all the platforms that go supports it easily evens out.
So what is your argument?
>>103567289
See this for reference
>>
>>103568891
If they are this close despite cranelift supporting less platforms than Go. Then your argument that...
>> Write 10 lines of Go code in 1 line of rust code
Is completely wrong
>>
>>103568952
rust supports more platforms with the llvm backend, but gophers will ignore that because it doesn't go their way.

also, the cranelift backend is 160k sloc, it would have 2M sloc or 10x its size of margin to match llvm.

it is also trivial to add new archs to cranelift as it is built to be retargetable.

and lastly, funny that when i mentioned that rust supporst more platforms, gophers will reply :
> Who cares how many random architectures you can build Go for? It supports the only ones that matter: x86, x64, and ARM. Why are you even pretending like anything else is relevant?

>>103567014
>>
>>103568991
you ignore the fact that rust is a much more featurful programming language, rust does 10x more stuff in ~ 2M sloc than go does in 2.3M.

or now the language is suddenly not more complex because it goes against your argument ?
>>
>>103568991
>>103568952
Why bring up LLVM? You were talking about Cranelift + RustC
and that is more or less equal in lines to Go
>>
>>103569018
yes, it is more or less, but the language has a shit ton more features at 100k less sloc.

yes the cranelift backend supports a little less platforms, but being only 160k sloc it would have almost 1M of margin or close to 10x its size to match go, and it's only the ir to machine code part.

do you really think it couldn't manage that ?
>>
>>103569010
And go ssimply supports more platforms so if you take them line by libe, feature by feature then Go and RustC would be Roughly equal.
>>
>>103569041
nope, rust supports more platform, did you even read :
>>103567289

it did not even include tier 3 support and rust still won.
>>
>>103569041
so now rust's not more complex than go ?
weird i thought go was a simpler language lmao.

or you say rust is more complex but then you have to admit that it does more in less sloc.

you can no longer win this.
>>
>>103569050
>>103569041
>>103569059
also, the usual gopher losing and moving the goalpoast again.

gophers seething.
>>
File: file.png (363 KB, 1191x1809)
363 KB
363 KB PNG
gpt thread summary.
>>
>>103569039
>> Only a 100K line of difference
You wer arguing that Go is only 1/10 as efficient as rust in pure code. That is clearly wrong.
>> Rust has additional features
What are these features and how much lins would they take to code in Go?

Also you are an idiot becuse you forgot that Go has an internal runtime and GC. Which rust does not.
>>
>>103569059
>weird i thought go was a simpler language lmao.
Go is a simple and performant language and it's easy to write good code using the language. Go lets you ship good software fast and is the best choice for all applications where you don't need explicit memory control.
>>
>>103569083
metaprogamming.
macros.

traits.
generics.
advanced type system.
borrow checker.
static checks.

are you even joking, or you wanna keep pretending rust isn't more complex than go now ?

in which case, why use go if rust is not more complex ?

you can't win this one.
>>
>>103569088
>>103569095

blindly repeating a moot point, it has literally been proven that rust does a lot more in less lines because its fully self hosted compiler (using cranelift instead of llvm) is less sloc than go's compiler by over a million whilst having a shit ton more features.
>>
gophers being real silent since the rust wins compiler sloc argument droped.
>>
>>103569072
lol
>>
>>103569072
>cringe emojis
>didn't even mention the furry allegations
Now show us what the BASED AI says
>>
>>103569118
oh, that one is too racist for 4chan lol
>>
>>103569109
Your 17 million lines of LLVM, sir?
>>
>>103569131
gopher repeating something that has been debuked 10x in the same thread already, YOU DON'T NEED LLVM NIGER.
this is a screen of the line count of a full rust toolchaiin that can self host and compile without using llvm at any point.
>>103568849

i won lmao.
>>
File: file.png (232 KB, 777x227)
232 KB
232 KB PNG
>>103568891
>>103568849
>>103569131
i'm repeating a third time because you can't read


full self hosted llvm free (ie not using llvm at all but cranelift instead) rust toolchain : 2.25M sloc
160k lines of code for cranelift
2M for rust
and some more for the backend linking the two.
total 2.25M.

full go toolchain : 2.3M toolchain

on top rust has more feature.

rust wins.
>>
>>103569131
>>103569117
you can compile rust without using llvm.
the cranelift backend is only 160k sloc
rust is 2M, both combined takes less sloc than go

seeth harder gotard
>>
i always thought the true holy war was cniles v rust but it turns out its gophers v rust
>>
>>103569163
>>103569153
i'm the rust guy, it's not that i love rust so much.

i can enjoy C, it's that i fucking hate go, i'd think it'd be a net positive if it burned and i'd want it to to have a 0% chance of ever having to work with it again.
>>
>>103569161
>>103569153
>>103569143
anon....
>>
>>103569174
i mean, i'm getting annoyed, the guy repeats mu 17 millions when i told like 5x already that you can build without llvm and with cranelift instead rust is fully self hosted and less sloc than go.

and i can bet someone will come with muh 17 millions again within this thread because they cannot read.
>>
>>103569184
not being able to read and understand english is to be expected from a gopher.
>>
>>103569172
How can you hate Go?

Go is simple, smart, and opinionated, which makes it easy to write good code using Go. The standard library is great and Go has a great concurrency model. It's easy to be productive in Go and write high quality and performant code.
>>
File: lff.gif (192 KB, 632x640)
192 KB
192 KB GIF
>muh 17 gorillion
>>
>>103569197
read again that :
> anyway, there are tons of go code that require 20+ sloc which are oneliners in rust.
>>103566693

a fully self hosted rust compiler having less sloc whilst having a shit ton more features as a languge prooves that rust can do more with less sloc.

>>103569095

rust is simply a better language.

now why i hate go is another topic, but tldr, it is a retarded language made for retards.
>>
>>103569203
lol
>>
>>103569221
Simplicity is beautiful, especially when you work on big software projects. Go is a great tool for getting things done while also writing performant and maintainable code. It sounds like you're either very young or unemployed.
>>
>>103569242
rust code is simpler because you need less code to do the same thing.

the compiler needing less sloc even though the language has a lot more features than go proves that.
>>103569153

you repeat yourself too much to not be a llm.
go has a ton of issues which were mentioned in this thread, it is a shit tier programming language, even fucking javascript is better.
>>
>>103569253
>rust code is simpler because you need less code to do the same thing.
Rust is not simpler than Go. You're either trolling or have no idea what you're talking about.
>>
>>103569264
the compiler sloc count just proves that.
you need less code to do more.

>>103569153

heck even the shitty go fibonnaci vs its rust counterpart in this thread proves that.



[Advertise on 4chan]

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

[Enable Mobile View / Use Mobile Site]

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