uACPI - a portable and easy-to-integrate ACPI implementation

[left orbit]

everyone being?

[calm latch]

who's everyone?

[torpid root]

idk I have seen multiple oses in the past days

[left orbit]

im only aware of mr pmos

i am planning on doing la64 but

it's far from being anything serious

[calm latch]

the fact that uACPI initialized means that I have full userspace working

[fiery turtle]

Lol cool

[calm latch]

(I mean I think everything pagefaults after that)

[calm latch]

Broken timer

[left orbit]

successfully loaded 1 AML blob, 840 ops in 0ms (avg 840000000000/s)

epic

[fiery turtle]

Update uacpi and it won't show time

[left orbit]

(update uacpi)

bruh

[fiery turtle]

I've added a check

Yeah

[left orbit]

why does everyone think faster than me

[calm latch]

i know about that, but it's not a priority

[calm latch]

Apparently they have a proper TSC-like timer, and I've missed it

[calm latch]

So I think I'll fix that, and then I'll try to implement the QEMU ACPI GED thing

[strong heath]

now do it in real hardware

[slim panther]

trolled

i think i'm the only one that has actual hw?

[left orbit]

you have la64 hardware?

wtf

why lol

[slim panther]

work

[left orbit]

ah

[slim panther]

i also have ppc64le hw

[left orbit]

that is actually cool tbh

[slim panther]

i have a 3A6000 la64

[left orbit]

what do you even do at suse?

[calm latch]

But there's no limine

[slim panther]

all sorts of things

[calm latch]

Though does it have EDK?

[slim panther]

not sure

probably not

[calm latch]

I've seen a port on GitHub

But I think it was not accepted to mainline

Wait a second

PPC

Why did I think about MIPS

[slim panther]

let me check our system

[strong heath]

painkillers

several kinds of drugs

to numb the pain of working at suse

[left orbit]

no but suse seems like a cool company to work at lol

thats why im curious

[strong heath]

its a cool company

[slim panther]

it's an IBM L922

power9

[calm latch]

What does it use to boot?

(like protocol)

[slim panther]

idk

[left orbit]

i mean it boots linux

so what do you think

[slim panther]

something something device trees

[lofty dragon]

loongarch64 is the coolest risc

they are actually on board with proper standards like UEFI and ACPI

there is actual hardware that works and is cheaper and powerful, unlike riscv

[calm latch]

Now somebody just needs to add SMP support to Limine

[lofty dragon]

and it is not boring unlike aarch64

yeah that is true

[calm latch]

There is a tiny issue

Lack of documentation

(like for vector extensions)

[lofty dragon]

i mean it still has some documentation, it's not completely undocumented

[left orbit]

linux

[lofty dragon]

i bet if you look for stuff in Chinese you'll find way more

[calm latch]

And the documentation that's there is translated from Chinese, with errors

[left orbit]

no the chinese one is also TBD

[calm latch]

https://elixir.bootlin.com/linux/v6.13.6/source/arch/loongarch/include/asm/asmmacro.h#L242 this looks like it's broken to me

And Linux is insane

[left orbit]

vector instructions and virtualization manuals are TBD in both chinese and english

and i guess from what mishakov says they are translated from chinese

[calm latch]

I've gotten vector extensions to work

[left orbit]

nice :^)

[calm latch]

(like the clang issued code does not crash)

It's a matter of saving and restoring registers from the kernel's point of view, so like not complicated

[left orbit]

ah makes sense

it was pretty readable to me tbh

i didnt notice many errors

[calm latch]

I've seen a bunch of them

But like it's fine, just not excellent I guess

[left orbit]

i guess i just didn't pay attention

[calm latch]

The only thing that was pagefaulting was Rust

Because it was linking against libc with brainrot bug in it

I think its ACPI looks more interesting than that of RISC-V

[left orbit]

that's really cool

[fiery turtle]

I guess now the only arch where uacpi hasn't been confirmed to work is itanium

[fiery turtle]

I see ged

[calm latch]

MIPS?

[fiery turtle]

no acpi there

[frank canopy]

pushed an update to zuacpi to update to zig 0.14

[fiery turtle]

nice

[jaunty fox]

yes, i think it seems quite promising

i'll probably buy a loongarch board if/when i come across one

[calm latch]

[gentle peak]

does looongarch have HPET? or is this something else

[calm latch]

It looks like an x86 hpet

[hollow crescent]

when are we getting shoortarch

[sterile egret]

MIPS

[fiery turtle]

after averagearch

[tired temple]

everyone wants it loong.

btw, doesn't anyone have MIPS Creator CI20? I won't ask to test anything on it, 😁 I just remembered, I had this tiny cute purple SBC. Good memories. My lowest level coding experience. sigh. I could take it with myself, but we hoped we return.

[hollow crescent]

Honestly I'm not sure it's still around anymore 😔

Was probably destroyed in the war

[tired temple]

You mean of mine? My town is completely destroyed. Everything actually. In 1000s km2 around. Below is photo of my house, yet in the summer 2023.
https://ant-upptech.sourceforge.io/res/NashDim-02-2023.jpg

And the 2nd pic is how it looks now. Totally "liberated from nazism".

[hollow crescent]

💔

hopefully your family is OK

[tired temple]

thank you. Are alive, already ok. As ok as it can be under almost everydays moped (drones) attacks and a bit rarer ballistic missiles attacks. Kyiv is targeted pretty often.

[strong heath]

Man that sucks, they will pay one day, if not in this life, the next one

[vale isle]

I speak Turkish and English, I technically studied German for 11 years but I can barely say Kartoffelsalad, I used to be intermediate in toki pona but forgot, I know enough polish to understand some basic song lyrics, I know a couple words of Zazaki - my heritage language

[vale isle]

marvin showed cool upcoming risc-v stuff and while I can't comment on price and power (I have no risc-v or loongarch hardware) risc-v is much more accessible

I've at least encountered risc-v boards

loongarch is pretty much still a china-only thing IMO

I'd love to see that (being china only) changed ofc

at least in my mind risc-v comes before loongarch in the list of possible targets

I'd like to see them as equals one day

[fiery turtle]

@gentle peak in old hydrogen u have event callbacks that run from a timer irq right

one of them is a scheduler thing

that can call into do_yield

wouldnt that yield from current irq handler, so u dont run lapic_eoi or other event handlers?

[gentle peak]

timer event handlers are run with preemption disabled, so the actual yield is only done after it's enabled again

which is done after eoi

[fiery turtle]

ohh

but next time u reschedule this task, would it then be basically on the enable_preempt(); line in the timer handler?

[gentle peak]

that's where the actual yield happens yea

[fiery turtle]

makes sense

is this how its normally done?

[gentle peak]

think so yeah

i didn't really look into how other kernels did it when i made it

i know this is basically equivalent to a two-level softipl thing

but i don't really know anything beyond that

[fiery turtle]

im gonna take a look at how keyronex does it

[surreal current]

WHY NOT MINTIA?!?!?!?!?!?!??!??!?!?

we do it identically so it doesnt matter

[fiery turtle]

not because its worse or anything lol

just the lang

[surreal current]

u hate jackal?

[fiery turtle]

if you would explain how you do it id appreciate it

more mental effort to read for me personally

[surreal current]

its just a C reskin

[fiery turtle]

not because its a bad reskin

just not used to syntax

[surreal current]

basically rescheduling is a software interrupt but not in the int 0x80 type way

there are interrupt priority levels (IPLs)

the lowest 3 are reserved for software interrupts

0 is everything enabled, 2 is preemption (among other things) masked off

ignore 1 thats out of scope

when a new thread should be scheduled in, a software interrupt is set pending at IPL 2

[fiery turtle]

by software interrupt u mean dpcs?

[surreal current]

next time IPL drops below 2, the pending bit is seen and the software interrupt handler is called which performs the actual reschedule

[surreal current]

that is one software interrupt at IPL 2

i dont do preemption as a DPC because itd be bad to preempt in the middle of dispatching the DPC queue

i dispatch all the DPCs and then i check for preemption and switch to a new thread if necessary

https://github.com/xrarch/mintia2/blob/main/OS/Executive/Ke/KeIpl.jkl#L43-L100

[fiery turtle]

ok i see that keyronex basically sends an ipi to itself in the timer irq

which then runs the dispatch dpc thing

which then calls reschedule

[surreal current]

yeah we diverge there, he does it with a self-hardware-interrupt and uses cr8 to implement ipl, i do it completely in software

[fiery turtle]

isnt doing in hw kinda overkill just to do a context switch

[surreal current]

i think my way is better

[fiery turtle]

and slow

[surreal current]

thats my opinion

especially bc software raise and lower ipl you can make like 1 and 3 instructions respectively in the fast path

on x86

so its not like that much more than setting cr8. actually its much faster if youre running under a hypervisor

[fiery turtle]

this thing you run in your enable_preempt type of function?

[surreal current]

yeah KiLowerIpl

[fiery turtle]

basically, when do u check pending software irqs

oh ok

so basically u do the same thing as proxima

[surreal current]

it sets the new ipl and then checks if there are soft ints pending and if so it calls KiDispatchSoftwareInterrupts

otherwise branches around the call

[fiery turtle]

QuantumEnd is what triggers a preempt?

[surreal current]

it like does quantum end processing like priority boost decay (if necessary) and selecting the next thread yeah

but doesnt actually switch to it yet

its just one source of thread preemption among others so thats not rolled together

[fiery turtle]

when does it actually switch?

[jaunty fox]

what's this i hear about UltraOS returning

[fiery turtle]

currently just accumulating knowledge lol

[fiery turtle]

where is this?

[jaunty fox]

in any domain in particular?

[fiery turtle]

mostly around scheduling i guess

[surreal current]

literally is in that function i linked

[jaunty fox]

i see you invited hyena as visiting lecturer

[fiery turtle]

ah lol

[surreal current]

i invited myself bc im annoying

[fiery turtle]

he's automatically present if you start discussing anything about virtual memory or scheduling

lmao

i appreciate it tho

[surreal current]

ohhhh i introduced a bug

recently

and only just noticed

thx for making me stare at that

[fiery turtle]

ah ok, so basically:

1. Timer irq sets quantum end
2. Does a RaiseIpl
3. RaiseIpl checks pending software irqs
4. If current thread's quantum is over, call into KiQuantumEnd, which picks the next thread to run
5. That thread is switchd to at the end of RaiseIpl

[surreal current]

not EXACTLY

[fiery turtle]

btw, dpcs are just a linked list of function pointers? what sort of dpcs are there usually, who queues them?

[jaunty fox]

although i liked it for the fact that it collapses the abstraction altogether and is simple, i'll certainly adopt your new approach at some point

and distinguishing raise/lower to/from software levels was a nice trick which i think should be no great difficulty to adapt to and enables those common cases to be written much more optimally

[surreal current]

1. timer irq decrements current thread timeslice and if it reached zero ticks left, it sets curcpu->QuantumEnd=TRUE and sets a soft int at IPL 2
2. return is about to occur from the outermost interrupt handler (they can nest if higher priority interrupts are taken). if there are now pending soft ints at the last IPL before the interrupt was taken, then the interrupt handler calls KiDispatchSoftwareInterrupts directly before returning. it turns out to be weird and fucked up to call KiRaiseIpl and KiLowerIpl for these things. if the last IPL before the interrupt was taken was too high to dispatch the new soft ints, they will be dispatched at the next KiLowerIpl to a lower IPL, and not at this moment
3. interrupt handler for IPL 2 (aka KI_IPL_DPC) calls KiQuantumEnd which determines what thread should run next (if any); it gets set into curcpu->NextThread if so
4. if curcpu->NextThread is set before returning from the IPL 2 handler, a switch directly into this new thread is conducted

[hollow crescent]

my used to do the former too but a while ago i changed it to do the latter

[jaunty fox]

do you have any concrete plans or concepts at present? other than linux abi compatibility

[fiery turtle]

nah, nothing concrete like that atm, mostly in the deciding phase

[jaunty fox]

good to see work on boron again btw

[fiery turtle]

hmm

point 2 is a bit too big brained

[surreal current]

note that NextThread is checked locklessly there (bc its safe to do so just to check for for transition from null->set) but actually setting it or using it is guarded by the per-processor ready queue spinlock

[jaunty fox]

any ideas you like particularly?

excuse my cross-examination

[fiery turtle]

im definitely more interested in the hw side, so it wont be sophisticated algorithm-wise probably

just the bare minimum to not be embarassing

[hollow crescent]

indeed, well i kinda finished what i needed to do for anon memory for now, now i need to implement memory mapped files, after that i can implement dll mapping and finally some kind of userspace

[surreal current]

whats confusing about it

[hollow crescent]

but i need to build an idea of how things are structured first

[fiery turtle]

"if there are now pending soft ints at the last IPL before the interrupt was taken"

what does this mean

last IPL?

[surreal current]

ok so like if you were at IPL 0 when you took the interrupt, and the timer interrupt set the pending bit for IPL 2, then it will be dispatched before returning from the interrupt

[hollow crescent]

if there are any pending DPCs or quantum end, is what i understood it to be

[surreal current]

however if you were at IPL 2 when the interrupt was taken, this soft int will not be dispatched yet

because it is masked off by the IPL you are returning to from the interrupt

it will be dispatched next time the interrupted code lowers its IPL

[fiery turtle]

like its probably a simple idea but i cant parse it because of these terms i dont understand that well

i need an x86-ified explanation

[surreal current]

the current IPL masks off any interrupt with an associated IPL that is <= the current one

[fiery turtle]

right

[hollow crescent]

on x86_64 that can be directly represented with the cr8 register

[fiery turtle]

no like i understand cr8

i dont understand what problem this is solving or working around tho

[surreal current]

so basically if you were at IPL 2, masking off preemption, and then the timer interrupt was taken and decided to do a quantum end, you probably dont want to get preempted

so you dont get preempted, it just returns without dispatching that soft int

it gets dispatched when you lower IPL

however if you were at a lower IPL then you do want to get preempted asap

so in that case it is dispatched in the interrupt handler before returning

[hollow crescent]

this allows the scheduler to be interrupted by hardware interrupts and also allows DPC/quantum end dispatch to be done in software

[fiery turtle]

what IPL is timer interrupt?

[hollow crescent]

ideally one of the highest

[surreal current]

in mintia2 its the second highest after the IPI which is the highest

[fiery turtle]

so higher than 2?

[surreal current]

yes

its like 30

ipi is 31

other device interrupts are in the 3-29 range

[fiery turtle]

so what you're saying is, you only dispatch context switches when you lower ipl to some small number?

[surreal current]

when i lower ipl to <2 yeah

since 2 and up is what masks off preemption

[jaunty fox]

just define IPL = %cr8, raising a soft interrupt as sending yourself an IPI on a vector that's within that priority class, and every interrupt handler starts by raising %cr8 to the appropriate value for that priority class, and ends by lowering %cr8 to its previous value. that's the kind of concrete processor that the abstract processor that the IPL concept prescribes, and which an IPL mechanism emulates in software to a greater or lesser degree (and it's useful for efficiency to do more emulation than necessary)

[fiery turtle]

but then how do you preempt if you were at ipl 0 and got a timer irq? u cant context switch because current ipl is very high

[surreal current]

you can

[hollow crescent]

A hardware interrupt can interrupt a few circumstances:

• User mode / normal IPL kernel mode code
• Code running in IPL 2 (DISPATCH_LEVEL) in NT
• Another hardware interrupt at a lower level

[surreal current]

right before you return from the interrupt handler

[jaunty fox]

in short everything is conceptualised as interrupts existing in a hierarchy of priority classes, with the ability to raise IPL to a level such that some priority class of interrupts is blocked (this includes the level 2, that level which does DPC dispatch and does context switch if one is pending)

[fiery turtle]

before return u loweripl to previous, and if it was smaller then 2 than u context switch?

[hollow crescent]

Think about it like this. You basically "morph" the interrupt into a lower level interrupt

[fiery turtle]

otherwise u defer to the interrupted code?

[surreal current]

i do lower IPL to the previous one yeah

but i dont use KiLowerIpl to do it

[hollow crescent]

The timer interrupt essentially "becomes" the dispatch interrupt

Without bearing the cost of a return from interrupt and another hardware interrupt

[fiery turtle]

what do you use?

[fiery turtle]

but only if the interrupted code was running at a low ipl right

[surreal current]

essentially bc KiRaiseIpl and KiLowerIpl are hyper optimized for the case of moving between software ipls which is the vastly most common case and does not require touching hardware interrupt masking

[hollow crescent]

This can only be done if you interrupted an IPL lower than dispatch level yes

[surreal current]

so i can just forego that entirely and pretend ipls that affect hardware interrupts dont exist in those routines

which makes them inappropriate for raising and lowering ipl in hardware interrupt handling

[fiery turtle]

and if it wasnt, then u just set a bit somewhere that a preemption is pending and then it preempts later on in loweripl?

[hollow crescent]

If you interrupted dispatch level then you have to return from that interrupt back into dispatch level

[surreal current]

dispatch level = ipl dpc = ipl 2 = irql 2

in case terminology is confusing u

[hollow crescent]

now i'm not sure if the timer interrupt or something else is supposed to determine if a quantum is over

[fiery turtle]

but u can only context switch if < 2?

[surreal current]

yes since >=2 masks it off

[hollow crescent]

in boron the timer interrupt does

[surreal current]

it does

[fiery turtle]

ok i think i understand

[hollow crescent]

when it detects that a quantum is over it sets a flag "PENDING_QUANTUM_END"

[fiery turtle]

why does it need to interrupt self in this case, if loweripl checks for quantumend anyway?

[surreal current]

because it wont call KiDispatchSoftwareInterrupts (which calls the IPL 2 interrupt handler if necessary) unless that bit is set

this basically enables a fast path where you just go like

KiLowerIpl(new):
  curcpu->Ipl = new
  
  if curcpu->Pending >> new != 0:
    KiDispatchSoftwareInterrupts()
  
  return

where Pending is a bit set

[hollow crescent]

https://github.com/iProgramMC/Boron/blob/master/boron/source/ke/sched.c#L635 is my somewhat more complicated for little reason version

[surreal current]

KiSoftInterruptSelf sets a bit in that bit set

if this looks racey bc interrupts can come in and fiddle with it and whatever while youre in KiLowerIpl, youre right. and i noticed that and would take time to disable interrupts for that routine and stuff. however one day i realized that all of the races are harmless and instantly self-correcting and that i dont need to do that

[fiery turtle]

hm ok makes sense

i see it calls it in Hal

[surreal current]

it do?

[surreal current]

yeah thats explicitly coded in a few places, the actual KiLowerIpl implementation is this though (the fox32 version for somewhat increased readability for x86 ppl)

[fiery turtle]

i see u also have a similar function for Apcs

[surreal current]

the magic number 0xFFFFF000 is where i map the per-cpu structure on fox32 (where there is only ever one cpu)

dont ask why i did that i forgot

i think it micro optimizes some stuff

[fiery turtle]

btw what sort of dpcs does this run usually

[surreal current]

one of them is the ULE global work balancer

runs each second on the boot processor and moves threads from the most loaded processor to the least loaded processor until theres balance

[fiery turtle]

it's just a list of function pointers right?

[surreal current]

(or until it has moved a lot of threads and needs to take a breather bc its currently holding up literally all threads from executing on that core)

[fiery turtle]

DPCs

[surreal current]

essentially yes

[fiery turtle]

whats the difference vs apcs?

[surreal current]

DPCs are targeted to a processor and run with preemption disabled

APCs are targeted to a thread and are next executed when the thread is next scheduled in and is at < KI_IPL_APC (which is IPL 1)

they are preemptible

they can also access the userspace of the thread's process

and take faults on it

[fiery turtle]

hmm interesting

[surreal current]

so an APC is used to asynchronously write out the IO status block after an async IO request finishes for instance

[fiery turtle]

what apcs does mintia have

[surreal current]

new mintia has none yet, old mintia used them extensively for async IO completion and so will new mintia

basically targeting an APC at the originally requesting thread to cause some completion work to be done in its context

i actually implemented them early on in old mintia and then like a year later i hadnt found a use for them so i removed them

and then a year after that i implemented async io and was like "oh. thats what theyre for." and had to dig thru the repo history to resurrect them

[fiery turtle]

damn yours is very nice

clean and abstracted away

[fiery turtle]

makes sense

[hollow crescent]

will, do you mind answering some of the questions in my boron thread

im again kinda lost. i have an inkling of an idea what to do but im not totally sure and would appreciate some feedback

[fiery turtle]

does dispatch refer to DPC in this case? since u cant actually dispatch at dispatch level lol

[hollow crescent]

DPCs run at dispatch level yes

[surreal current]

its the level the dispatch interrupt runs at

where dispatch is a VMSy way to say scheduling

aka preemption

so raising to that level masks off the dispatch interrupt ie masks off preemption

[fiery turtle]

so the scheduler doesnt preempt itself basically?

[surreal current]

yes

[fiery turtle]

ah

[surreal current]

my scheduler never disables interrupts (except at architecturally necessary moments where itd explode if it didnt)

[fiery turtle]

yeah it seems unnecessary if u have ipls

[surreal current]

architecturally necessary moments being like where youve only partially switched context and if an interrupt came in at that moment youd blow up for whatever reason dependent upon the architecture's interrupt dispatch details

unavoidable stuff like that

[left orbit]

you can do raise ipl lazily, basically store the new ipl in a per-cpu struct and when an interrupt arrives that should be masked out by the new ipl you can just write to cr8 and return from the irq handler

[surreal current]

ik you can but thats still slower than software dispatch

and i was trying not to completely overwhelm infy with information lol

infymation

[fiery turtle]

nah i know about lazy ipl

[left orbit]

mov gs:[0xNNN], new_ipl

how is that slow

[surreal current]

its not

its exactly as fast as my way

[left orbit]

ah

well you said slower so

[surreal current]

and then lowering is either the same or slower

[fiery turtle]

u still have to run the handler later right

so u must save that info somewhere

[calm latch]

This sounds overly complicated for no reason

[surreal current]

and dispatch is definitely slower

[left orbit]

lower is slower, yeah

you always have to write cr8 when lowering

[surreal current]

its not

its pretty simple

its just complicated to explain

[left orbit]

interrupt priority levels are a very nice thing

[fiery turtle]

nah its very simple once u understand

[left orbit]

i dont understand them fully yet but

[calm latch]

pmOS solution is to just gtfo as soon as possible/dispatch to lower level if the kernel preempted itself

Not tied to priority levels

[fiery turtle]

for lazy ipls im not sure when ur supposed to run the hardware handler properly

maybe u queue it as dpc to run later or something

[calm latch]

(I mean in theory, I haven't implemented timer preemption yet)

[surreal current]

also again dispatch is taking a whole ass interrupt exception in your way

in mine its a branch

[fiery turtle]

in vms, writing cr8 is much more expensive

because it's a vmexit

on real hw, probably

[calm latch]

(though the fact that I don't switch kernel contexts drastically changes everything I guess...)

[calm latch]

But is it actually a better solution?
Like how often do you get preempted by timers, compared to extra branches stuff

because an exception is like 100 cycles?

[calm latch]

Every time you enter the kernel

[surreal current]

in mintia2 i do not really use ipl outside of the innermost parts of my kernel that are called relatively infrequently and briefly

so ive probably mostly removed whatever 0.1% loss from that branch from most of the hot paths

noncontended locks dont raise ipl for instance

also its a forward branch so in the absence of any history or hints its predicted taken (ie no softints pending, the common case) on most uarches :)

[fiery turtle]

jackal allows u to do FN (<typedef>)?

[surreal current]

nvm

[fiery turtle]

thats interesting

[surreal current]

i got that backward. forward branches are predicted NOT taken on most uarches. :(

backward branches are what are predicted taken bc they are Probably A Loop

which Probably Loops At Least Once

[surreal current]

yeah

and then it screams at you violently if you even name a parameter differently than the typedef

[calm latch]

[[unlikely]]

[hybrid turtle]

https://osdev.wiki/wiki/Unlikely?action=edit&redlink=1

[surreal current]

ik

in the absence of hints the branch prediction is primed using the sign bit of the branch offset is the common trick i think

[fiery turtle]

cool

[surreal current]

actually you have to do that

before you can assign a field of that type with a function pointer

[slim panther]

new bios dropped for my faulty mobo

we shall see if they touched the AML at all

[fiery turtle]

it should

[lofty dragon]

damn new microcode

[dusky glade]

boo

[slim panther]

inb4

we will see in a few hrs

[dusky glade]

i havent slept

[slim panther]

@rustic compass @fiery turtle could i work on uacpi-rs?

[fiery turtle]

i dont have a say in this lol, but i dont mind

[slim panther]

well, you control the orga don't you?

[fiery turtle]

yes but uacpi-rs is shinribo's code

[slim panther]

ah

just pinged you so i could get write access

but yes, waiting for shin

[rustic compass]

yes, let me just push my changes

which is basicly 99% of types.h

except handlers, i will figure out how to do them once i encounter them and see how they are used by uacpi

also as of now i copy all strings used by uacpi which are exported to the user into rust code so that i can guarantee that only the reference to the string is passed to the user instead of the entire string (maybe i can cast a reference to a c string to a &str then we can just use uacpi string stuff)

also sorry for taking so long

i assume you want the table api for now so maybe we could just get barebones mode first

[slim panther]

yea

i don't really do anything with handlers yet

only hpet and mcfg and madt

[rustic compass]

i would say those standard table names which are also defined by uacpi should go into a enum

[slim panther]

i guess

how would that look like

[rustic compass]

you would call the table find method with a member of that enum as a parameter and internally it would use match to turn it into a string and call the string variant

pushed everything

barebones mode included

but no cfg! added to the functions yet

[slim panther]

k

[fiery turtle]

Do u want to be added to the org?

since you're gonna work on it

[slim panther]

yes

im actually not aware of any other user of uacpi-rs atm (besides shinribos os)

[rustic compass]

also i didnt pass the use buildin mem functions so aparently that works out of the box with rust (core exports mem stuff with c abi)

me neither

[fiery turtle]

sent

[slim panther]

accepted

[frank canopy]

the way i do it for zuacpi is to have a u32-backed enum and each member's value is the four-byte string treated as a u32

idk how youd do that in rust

but its very nice to use in my experience

[kind mantle]

You can select the ordinals for your enums

enum MyType {
    OptionA = 0xdeadbeef,
    OptionB = 0xcafebabe,
};

But I think you probably mean this

match packed_name {
  0x54445352 => Thing::Rsdt,
  _ => Thing::Invalid,
}

[rustic compass]

more like

enum table {
  fadt
  hpet

}


match var {
  table::fadt => "FADT"
  table::hpet => "HPET"
...
}

[fiery turtle]

uacpi_table_find takes a struct with uacpi_object_name which can technically work on a u32 signature

[frank canopy]

i usually use find_by_signature

can just @bitCast the u32 back to a [4]u8

and it just works

make it inline and the compiler will do it eagerly too

[slim panther]

cant do this safely in rust

[frank canopy]

rip

[vocal geyser]

when an interruption occurs, for example, from the power button, what will happen if cr3 is not a kernel ? (my scheduling changes cr3 for each task)

[left orbit]

it's an interrupt like any other interrupt

how you handle it is up to you

how do you handle other interrupts if your kernel isn't mapped lol

[vocal geyser]

it's always mapped

[left orbit]

well then where's the problem?

[vocal geyser]

i mean suddenly uacpi will use some addresses which are not mapped

[left orbit]

then that's your problem

why aren't they mapped?

kernel stuff should probably always be mapped

or just defer that work instead of doing it in an isr

really up to you

but i don't see why uacpi should be concerned by that, literally nothing about handling interrupts is specific to uacpi

do what you need to do in the isr to either a) defer that work to a worker thread b) allow uacpi to run properly

[urban galleon]

sounds like a skill issue language, what is there unsafe about this

[slim panther]

invalid state

rust enums can only be converted into an integery not the other way around

because of the pattern matching rules

if you suddenly have an unhandled enum representation you'd fall through and get ub

[urban galleon]

Default case?

[slim panther]

not a thing

[urban galleon]

[slim panther]

enums in rust are not layers upon ints

[urban galleon]

Breakign news assembly is more flexible than rust

[urban galleon]

Are the CT?

[slim panther]

ct?

[slim panther]

what's that

[rustic compass]

It would be sufficient to turn a enum into a int and define each enum element with the value corresponding to a table

Like defining it as a [c_char;4]

And then casting it into a u32

And put that into the enum

[urban galleon]

Compile time

[kind mantle]

You mean more memory-unsafe than even C

[slim panther]

"are the compile time"?

not sure what you're trying to say

[kind mantle]

Whether enums are compile time. No. They're not macros but like any other value, expressions with them can be evaluated at compile time.

[urban galleon]

Safety = Limits

The language doesn’t have to be safe

The code should be safe

™️

[kind mantle]

I used to think this way you know

I considered myself an expert C programmer and still do

And then I tried Rust and immediately fell in love with it

It's very nice not to have to worry about:

• Heap corruption
• Garbage pointers
• Use after free
• Double free
  And as a bonus, while not impossible, it's much less common to leak memory.

[flat badge]

Rust doesn't really help with memory leaks over C++ though

[vale isle]

it does in specific cases

[flat badge]

all the stuff that prevents memory leaks in Rust also exists in c++

like refcounting pointers, containers, box/unique_ptr

[leaden fox]

yeah but Rust makes them mandatory

[flat badge]

not really

you can just call Box::leak etc

in safe code

[leaden fox]

yeah but that's on purpose

[flat badge]

just like calling raw new in C++

Rust protects against memory safety issues and that's very valuable, but it doesn't really improve memory leakage over C++

[slim panther]

but memory leaks aren't inherently unsafe

rust doesn't solve logic issues

[flat badge]

i know. i'm not claiming that they are

[flat badge]

exactly

[slim panther]

ah you edited your msg

[leaden fox]

just never free

[urban galleon]

When I tried it I immediately hated it, it felt like it was limiting me while offering no advantage

Which is different to languages that provide abstraction like C++ which don’t limit you and only allow you to make your code look nicer

[kind mantle]

But Rust isn't trying to replace C++

If it's "replacing" anything it'd be C

Personally I'm not a big fan of C++

[urban galleon]

I am comparing C and rust

I just mentioned C++ as something that doesn’t do explicit safety and it works well

[frank canopy]

this is exactly what zuacpi does fwiw, though zig enums are always int-backed and can be defined as non-exhaustive or have an error for an unexpected value depending on what i want it to do

its just that zig also lets me safely convert that back into a 4-char-array-with-compile-time-length so i can pass it to uacpi

[slim panther]

rust is meant to help you write "correct" code

taking shortcuts everywhere is bound to cause some footguns

[jaunty fox]

there is a place for safe rust but i think it's rather smaller than people imagine

[urban galleon]

you can’t have good code without footguns

[loud ice]

i dont understand the point of rust

safe rust is way harder to write than safe go

[fiery turtle]

Strange to hear that coming from you lol

[urban galleon]

real

[slim panther]

I mean yes

[jaunty fox]

in particular the fearless concurrency and memory safety are not compatible with big shared state machines like kernels (yes, i know we try to localise the state per cpu or per thread or w/e, but we still have it)

[fiery turtle]

Yeah it works best for cli tools or like data processors like compilers

[loud ice]

wdym?

[fiery turtle]

Youre like the biggest rust guy here

[loud ice]

am i?

god i hate rust

[fiery turtle]

Yes

[slim panther]

kinda

malding

[jaunty fox]

the simpler truth is that an efficient kernel needs Frightful Concurrency and Memory Chill

[loud ice]

the problem with rust is that i dont see where it makes sense

i dont think it makes sense in app stuff

because in that case you have plenty of GClangs to choose from

[fiery turtle]

I trust your opinion because u know it well

[slim panther]

gclangs are slow

[loud ice]

lolnope

[fiery turtle]

Go is pretty fast

[jaunty fox]

they're not, they're roaring fast

[loud ice]

go is pretty shit lol

[fiery turtle]

And safe af

[fiery turtle]

L opinion

[loud ice]

dotnet, HotSpot, JavaScriptCore, V8, LuaJIT...

[loud ice]

i mean in terms of performance

[jaunty fox]

in fact they tend to outperform all but the most sophisticated techniques of manual memory management or automated-but-simplistic

[slim panther]

dotnet is also very slow in comparison

[loud ice]

they are objectively really really bad

[fiery turtle]

Just needs a better gc impl

The lang itself allows for better optimizations

[loud ice]

yeah

[jaunty fox]

what a good JIT can do is absolutely incredible

[loud ice]

go is not a very good gclang

and they still have great perf

[jaunty fox]

v8 can make even something like JS run like lightning

[loud ice]

really?

[loud ice]

JavaScriptCore is a bit faster afaik?

but yeah they all do an incredible job of making code run really fast

[fiery turtle]

i mean how much money has been invested in optimizing it

and manhours

its crazy to think about

[loud ice]

it is

[loud ice]

benchmarks?

[slim panther]

you can optimize a jit and gc all you want, but it's still bound by the language design. a lot of the dotnet abstractions are not zero cost

[jaunty fox]

by now a lot, but the dirty secret of JITs is that most of the technology was invented for Smalltalk in the 80s (and then elevated to a high art with Animorphic Smalltalk/Strongtalk in the 90s)

[hallow marten]

what's cool is that JITs have inherently a better overview of program runtime so they can optimize accordingly

[loud ice]

this is really ideas without any evidence to back it up

[fiery turtle]

the cool thing about dot net is struct vs class etc

[hallow marten]

rust fan L + cope + seethe + mald

[fiery turtle]

allows for some extra optimizations

[jaunty fox]

HotSpot was written by the Animorphic Smalltalk team, and google later hired all of them to write V8. so it has a remarkable degree of overlap

[urban galleon]

I am a big fan of D

[fiery turtle]

didnt know that

[hallow marten]

HotSpot is very cool

[urban galleon]

I think tsoding even made a video on it

[jaunty fox]

in fact even terminology as fundamental as the Oop (ordinary object pointer) can be found in common between Strongtalk, HotSpot, and V8

[loud ice]

but yeah the problem with rust is that it really doesnt make sense imo

[fiery turtle]

good because i kinda hate it lmfao

[hallow marten]

I think it can fit somewhere as a C++ replacement for some user apps

[loud ice]

GClangs are way better for apps stuff

[kind mantle]

Says the person whose nickname is rustc

[loud ice]

for high performance things yeah idk maybe?

[hallow marten]

I did not choose my name

it was given to me by the allfathers

[fiery turtle]

also the next ubuntu will ship with rust tools instead of gnu stuff right

[slim panther]

well who wouldn't want to write high performance apps

[jaunty fox]

and the Smi as well (SmallInteger, a smalltalk class of integers below (system word size) >> a few tag bits. V8 iirc rejects NaN boxing as an unwanted innovation and retains traditional Smi-tagging

[fiery turtle]

that will be fun

[loud ice]

v8 doesn't have nan boxing yeah

actually i think they dont have unboxed pointers in general?

[loud ice]

but go, c#, java etc all provide similar levels of performance

without objectively hard to work with borrow checking issues

[jaunty fox]

the cowards, they didn't even use js or lua coreutils

[slim panther]

similar compared to rust?

[loud ice]

yes i think

[fiery turtle]

lol

python better

[torpid ferry]

if you exclude autovectorization yeah

[loud ice]

i suspect that dotnet and hotspot can autovectorize your code too

[torpid ferry]

yeah but they're not very good at it compared to LLVM

[slim panther]

almost every comparison i see is them being worse than rust/c/c++

[jaunty fox]

david chisnall actually argues for a lot more use of high-level languages in the core userland of operating systems, he thinks a service manager/"init system" would actually be better off as a small C++ core and lua on top to provide more complex semantics. and he may have a point

[loud ice]

worse yes, but the question isnt "is it worse" but "is it significantly worse"

[slim panther]

i would argue yes

[fiery turtle]

isnt that basically the "entirely managed os" idea

[torpid ferry]

2-4x worse is not significantly worse for large apps where the ease of developement benefits justify it 10 fold

[slim panther]

oh yea sure

[jaunty fox]

in those, the kernel too is usually in the managed language

[loud ice]

isnt v8/javascriptcore something like 2x lol

[fiery turtle]

ohh ok

[torpid ferry]

like, for mid-high performance userspace stuff like some web servers Go and Rust are head to head

[loud ice]

lmao

[slim panther]

random article i found

[loud ice]

except that go is like 10 times easier to write code in

[torpid ferry]

that's memory usage

[slim panther]

no

[loud ice]

link?

memory is expected yeah

[slim panther]

https://medium.com/@shyamsundarb/c-vs-rust-vs-go-a-performance-benchmarking-in-kubernetes-c303b67b84b5

[torpid ferry]

oh i read only the beginning, the issue is that GC memory usage is really hard to measure

[fiery turtle]

^

[slim panther]

i don't really mind memory usage of dotnet et al

im more about the cpu usage

[loud ice]

the cpu usage is nowhere close to 100%

[fiery turtle]

imo its less important than performance

[jaunty fox]

the truth in the end is that a lot of apps and core userland as well don't even remotely need to be fast, and this isn't a case of getting drunk on the overabundance of processing power and memory at your disposal today, it's a case of "a service manager running on a 40 year old computer could happily be mostly in Lua without any detectable impact)

[loud ice]

so the benchmark is kinda not super useful

that could be like random quiescent work

[fiery turtle]

u can call into the gc after every statement to bring it down

[torpid ferry]

emacs is almost mostly written in a shoddy intepreted lisp, and that was plenty fast even 40 years ago

[loud ice]

go hits a better p99 in those benchmarks as well

[torpid ferry]

gcs can be faster than manual allocation too

[loud ice]

yeah

and gc semantics are easier to optimize around

[slim panther]

duh? that's under no load

[loud ice]

yeah you cant really benchmark fairly like that

[jaunty fox]

so i am very sympathetic to chisnall's position now, that writing a service manager in C or C++ or Rust is giving yourself a lot of pain and adding some risk in the case of the former two, for nothing. it simply doesn't cost much to maintain and operate on a graph of what's probably going to be at most a few hundred services

[kind mantle]

Modern CPUs are crazy overpowered for what we actually use them for most of the time

[loud ice]

C# and go use more memory because there is no memory pressure

so theres no point collecting and wasting cpu time

c# stays under 3%

[torpid ferry]

i'd say no, modern cpus are fast at a lot of things but for others they're hardly faster than 90s stuff (relatively speaking)

[slim panther]

unused memory = wasted memory

[torpid ferry]

like memory latency

[hallow marten]

emacs with libgccjit is now pretty fast

which is cool

[loud ice]

literally yes

[slim panther]

i keep seeing people mald over windows memory usage

[kind mantle]

But they're still completely overpowered for the average office job

[fiery turtle]

lmfao

[loud ice]

yeah because peope are stupid

[kind mantle]

Wasn't that a case of caches reported as in-use memory?

[fiery turtle]

microsofts fault for choosing the algo for displaying free memory in task manager

[torpid ferry]

text rendering is a fucking mess
like, doing it faster will break some unicode edge caes

[slim panther]

that too

when openFont

hw accel for typeface rendering

[kind mantle]

I know but I mean you don't need a high-end CPU to render text

And if you're editing documents a lot of it doesn't need to be re-rendered because it's just scrolled around

Be that literal scrolling or inserting lines

[loud ice]

but yeah the problem with rust is that its lacking good use cases:

• for web server stuff, go is about as fast at runtime and way faster to write code in (async rust is a mess)
• for kernel stuff, it kinda works? but it's not oom safe so you need lots of ugly hacks if you want to be a real kernel etc
• for embedded, its cool ig? but how much of that is there
• for tools, go works better too imo

[torpid ferry]

have you seen redox code

[fiery turtle]

Why is it cool for embedded

[slim panther]

very much embedded actually

[torpid ferry]

like, look at redox futexes

[loud ice]

i mean it works well enough

it has a nice ecosystem

embedded != osdev

[slim panther]

rustsbi, oreboot

[loud ice]

not this kind of embedded lol

[kind mantle]

Because embedded has always been an environment where robustness is imperative

[fiery turtle]

You mean like toolchain support?

[loud ice]

i meant more the "microcontroller shit" kind of embedded

[loud ice]

no like libraries

[fiery turtle]

Oh

[slim panther]

rustsbi works on microcontrollers afaik

[hallow marten]

ah yes my 4mb binaries on my microcontroller

[loud ice]

but why the fuck would you use it

[slim panther]

idk

[slim panther]

no_std rust is quite small tbh

[jaunty fox]

most embedded people don't seem to be very good at what they do so rust can only help them really

[loud ice]

optimized rust isnt that big if you are careful about using libraries

its not as great as C

but yeah no rust is cool there

[jaunty fox]

the embedded people are getting away with murder

[fiery turtle]

Lol

[kind mantle]

Well actually modern microcontrollers have legit become that large

[fiery turtle]

Maybe firmware devs should take note

[loud ice]

also this

[loud ice]

no please dont

rust is hell to rev

[hallow marten]

yeah I know

river was fairly small

[loud ice]

at least with c you can pop their code into ida and see what kind of crap they did

[slim panther]

firmware devs when they have to produce working software:

[fiery turtle]

Lol

[fiery turtle]

How did your bios update go btw

[loud ice]

but yeah the problem is like. you either are on a platform which is desktopy enough that a gclang is fine

[slim panther]

terrible

[loud ice]

or you are in embedded which isnt that big

[kind mantle]

A friend of mine is a professional embedded dev and he describes his coworkers as incompetent

[loud ice]

or you are anything where you need async

where rust is insane cbt

[fiery turtle]

Lol why

[kind mantle]

And when I hear the things he says they're incapable of I agree

[slim panther]

now my mobo never wakes up again once it hits s3

[fiery turtle]

Also cryptobros like rust a lot iirc

[fiery turtle]

Bruh

[loud ice]

they are all about hype lol

[slim panther]

do they? that's news to me

[loud ice]

and rust is also like 90% about hype

[fiery turtle]

True

[jaunty fox]

they love to use it for smart contrats

[slim panther]

most crypto bros dont know shit about coding

[kind mantle]

Have you tried rust?

[loud ice]

yes lol

[slim panther]

lol

[kind mantle]

Because this is what I thought before I tried it

[hallow marten]

rust is very much overhyped

[loud ice]

yeah

[hallow marten]

it's a good language though

[loud ice]

its a cool langauge

[hallow marten]

I would rather see it with a GC

[loud ice]

wouldnt want to write an app in it

[loud ice]

100% this

[jaunty fox]

i'm not surprised, it is an area people imagine is full of carmacks, knuths, and other greats, but in reality most of it is not important work and treated as such

[slim panther]

am i stupid

[loud ice]

rust with gc instead of borrowck crap would be so good

[hallow marten]

the ocaml stuff is nice, the C/++ stuff is nice, the borrow checker sucks and is annoying to work with

[slim panther]

rust gives you the benefit of gclangs without requiring a gc. how is this a bad thing?

[jaunty fox]

the most of the job is probably knowing how to mix freertos and lwip and other things made by the talented ones

[loud ice]

because it doesn't give you the benefit of gclangs

lol

[kind mantle]

Scala?

[loud ice]

it fails pretty miserably at it

[slim panther]

example?

i cant wrap my head around it

[hallow marten]

the benefit of gclangs is not having to care about it

in rust you very much do

[loud ice]

type Foo struct { Thingy *Bar }
type Bar struct { Items []*Foo }```
please write this go type in rust

[gentle peak]

the main benefit of gclangs is that you don't have to worry about memory management

[jaunty fox]

this

[loud ice]

yeah 100% this

[jaunty fox]

as someone i can't remember put it

[gentle peak]

in rust you do, you just experience the issues at compile time instead of runtime like with c

[loud ice]

the main point of a gclang is that there is 0 thinking required

[jaunty fox]

low level languages is when you have to think about things you don't need to care about

i badly butchered this quote but it went something like that

[slim panther]

eh, the compiler is good enough that i can mindlessly write code

when compile fails i just do what it says

[jaunty fox]

and the truth of the matter is most apps do not need to care about memory management

[loud ice]

also: without using a lock, refcell, unsafe, a weak pointer, or an enum

[kind mantle]

struct Foo {
   pub bar: Box<Thingy>
}
struct Bar {
   pub foo: Vec<Foo>
}

[loud ice]

you got the type for foo.thingy the wrong way around

foo has a pointer back to bar

[hallow marten]

It's something like "when you have to care about the irrelevant"

[kind mantle]

Oh

[loud ice]

the point is that this type is cyclic

[loud ice]

or an arena

[jaunty fox]

thanks, now i've been able to find it with google

it's alan perlis

"8. A programming language is low level when its programs require attention to the irrelevant."

[loud ice]

that is 100% rust tbh

like rust with GC and good async or goroutines would be very nice to have

[hallow marten]

The MLisms in it are cool

[slim panther]

i fucking hate having opinions
when i didnt like rust everyone was praising it
now i like it and everyone says how trash it is
???

[gentle peak]

especially as soon as you need unsafe

[loud ice]

the second you touch rust unsafe rust begins to suck even harder

tbh

[kind mantle]

I think it's this then:

struct<'a> Foo {
    pub thingy: &'a Bar<'a>
}
struct<'a> Bar {
    pub items: Vec<Box<Foo<'a>>>
}

[loud ice]

this type is not constructible

you cannot construct <cycle>: Bar { items: vec![Foo { thingy: <cycle> }] }

the only way to do it requires a Cell

[slim panther]

just put an option around it

[loud ice]

still unconstructible

[kind mantle]

IIRC the idiomatic way to do this was to use weak refcounting pointers

[loud ice]

which is slower than what go does

is less ergonmic

[rustic compass]

Oom handling is being worked on and the allocator api handles oom

[loud ice]

and is also STILL unconstructible without a refcell

[loud ice]

okay cool but i evaluate current results, not theoretical future results

[kind mantle]

In Rust you sacrifice some of the memory-safe programs and in return you get a type system that guarantees* your code is memory-safe.

[loud ice]

also, rust unsafe semantics are insanely hard

[fiery turtle]

no proper oom handling in rust is truly hilarious

[gentle peak]

in gclangs you get that as well without the sacrificing

[loud ice]

*except in the case of LLVM bugs, rustc bugs, or type system soundness holes

[loud ice]

yeah, that's pretty much the point

[kind mantle]

Well

Languages with garbage collection do not generally compile to machine code

[loud ice]

this is also a common compiler patterns

[loud ice]

what lol

[kind mantle]

Not directly

[loud ice]

from JITs you have DotNet, HotSpot, JavaScriptCore, V8

[kind mantle]

They all have an intermediate representation

[loud ice]

from AOT you have NativeAOT, Go

GCC Java back when that was a thing

[slim panther]

nativeaot is actually pretty bad though

[jaunty fox]

they all do in the end, and you can haply use C or C++ with a tracing GC if you want

[loud ice]

wdym?

i dont have a lot of knowledge about that tbh

[slim panther]

i've used it when .net 8 came out

it uses clang to compile

[loud ice]

yeah whats the problem?

[slim panther]

startup is faster, but overall perf is lower than regular c#

[loud ice]

huh

[slim panther]

and you lose all runtime reflection

[loud ice]

unity's il2cpp has reflection

[slim panther]

yea but nativeaot is not il2cpp

[loud ice]

same idea tho

so its defo possible

[gentle peak]

aot is almost always gonna be slower than a decent jit for the same language, because decent jits utilize info that's only available at runtime

[loud ice]

you have PGO though

go has PGO for example

[slim panther]

you have some form of reflection, but only the things that are statically determinable

[loud ice]

yeah idk this is one somewhat shitty impl tho

what about literally all of the others?

[slim panther]

wdym

[loud ice]

oh theres also GraalVM

which is like nativeaot but for java

[slim panther]

cant comment on that as i haven't used it

[loud ice]

dart has AOT as well i think

[loud ice]

basically every good language has an IR :^)

[slim panther]

when os in llvm ir

[loud ice]

but yeah static PGO kills most of the gains from JIT PGO i think

[kind mantle]

What about this though: Are there other "well-supported" languages with the same kind of traits system that Rust has? Another one I really like is how Rust deals with generics compared to C++. C++ templates are a good idea executed poorly and IMO Rust does that same thing better.

[loud ice]

AFAIK, no

it is a cool think in rust

[slim panther]

i like rust error handling

[loud ice]

but damn i would not want to do it in my lang lol

its insanely complex

[kind mantle]

Definitely

[loud ice]

yeah its cool

its also stolen straight from other languages

[kind mantle]

? operator my beloved

[loud ice]

but thats besides the point

[frank canopy]

oh god i looked away for 90 minutes and this place has gone nuts now

[slim panther]

yes

average rust flame war

[jaunty fox]

traits are an old idea, here they are being put in smalltalk in 2003 https://rmod-files.lille.inria.fr/Team/Texts/Papers/Blac03a-OOSPLA03-TraitsHierarchy.pdf

[loud ice]

rusts error handling is cool

[frank canopy]

rusts error handling just reminds me of haskell tbh

that isnt a bad thing per se but it does

[loud ice]

traits are cool too, but they don't outweigh the pain of the borrow checker to me

[flat badge]

TBH I don't really like Rust's error handling

[loud ice]

why?

[flat badge]

every library has their own error types and converting between them is a pain

[loud ice]

yeah true

i dont think theres a good way to solve it without a gclang though

speaking of which go has a single error type, which works everywhere!

but no try operator

[jaunty fox]

what i like about rust error handling is that they added a way to catch a panic! and now they've got exceptions

[frank canopy]

this is basically my feelings on rust tbh. going oh thats a neat idea while never being able to write anything because it turns out everything i want to write has a natural in-memory model that the borrow checker hates

[loud ice]

you shouldnt catch panics tho

[kind mantle]

That's unfortunately inherent to how Rust deals with inheritance

[slim panther]

they did?

[loud ice]

yup

[fiery turtle]

well because go's ideology is to be simple af

[jaunty fox]

the fate of every programming language that boldly declares "We have something better than exceptions" is to eventually add them in, with some limitation or other

[loud ice]

i believe gleam doesnt have exceptions

(but for real)

[frank canopy]

i do like zig's error handling tbh. no exception type stuff there either but its a fairly early lang

[loud ice]

no idea how that plays with BEAM and JS though

[loud ice]

yeah true

[frank canopy]

you can "catch" a panic insofar as you can control what panic calls

[loud ice]

i dont like zig's lack of a good error type

because a status code is not enough

[gentle peak]

exceptions

[loud ice]

you cant make that OOM safe

also exceptions arent a good solution /j

[frank canopy]

honestly ive never found it that limiting. if you need more you can declare that infrastructure yourself and do getlasterror type stuff

[loud ice]

go's solution is way better than exceptions

[jaunty fox]

what becomes clear from the history of programming languages is that new ideas come up, they're a fad for a while, then they fade away, and old ideas that were despised for a few years have a habit of coming back

[loud ice]

getlasteror is ugly imo

and has kinda the same issue as rust

it doesnt compose particularly well

[kind mantle]

This is why I think C will still be around in another 70 years

[loud ice]

i do think rust is here to stay though

[fiery turtle]

noooooo

[loud ice]

okay so now that we have complained at length about rust language

[slim panther]

okay i think i have formed a well-thought out opinion

i want a language that gives me the profile of c++ without looking like c++

[loud ice]

lets discuss rust libs

[slim panther]

liberals 😡

[loud ice]

aka the ecosystem shitshow

[flat badge]

My hot take on Rust's viability is that most (but not all) situations in which people reach for Rust would better be solved by a GC lang

[fiery turtle]

very true

[loud ice]

i agree tbh

[kind mantle]

oh probably

[slim panther]

same could be said about c++, no?

[kind mantle]

Also probably

[slim panther]

the second you need more than C, you're doomed anyways

[loud ice]

that is true for basically every non gc lang

tbh

except maybe ada

[slim panther]

fair point actually

[loud ice]

because you may use ada for their theorem proving magic

[flat badge]

if you're writing a webserver that needs to process 500 requests / sec, you probably do not want to use Rust

[loud ice]

500 per second is nothing

[slim panther]

*need

[jaunty fox]

it's not so hot, i think many of us are all aligned on this opinion

[kind mantle]

You mean 5000 per second if not more?

[fiery turtle]

yep

imagine gc-based autopilot

or a c based autopilot

one hangs the other segfaults

[loud ice]

autopilot for what?

for a plane?

[fiery turtle]

like a boeing

yeah

[loud ice]

they can hang for quite a while without it being a problem tbh

so long as its not like a critical phase of flight

[jaunty fox]

we can say this: rust is unsuitable for any app which isn't extremely sensitive to performance to such an extent as it can't handle a tracing GC, because rust would require the programmer to invest completely unnecessary effort by virtue of using a too-low-level language;
rust is of limited suitability for complicated shared state monsters like a kernel, because those rely exactly on Frightful Concurrency and Memory Chill techniques for efficiency, and Fearless Concurrency/Memory Safety are pure poison here;
rust may be useful for those apps which don't fall into either category

[kind mantle]

AFAIK airplane software is written in C and they have (like embedded actually) strict requirements about acceptable programming and memory management patterns

[jaunty fox]

and most apps are in the first category

[slim panther]

do go and c# have something like typed enums and/or options

[frank canopy]

c# does not yet though i think theyre looking into discriminated unions now

which i assume is what you mean by typed enums

[kind mantle]

I believe that's actually called a fat union

[fiery turtle]

go doesnt have anything like that

[frank canopy]

tagged, fat, or discriminated union

[loud ice]

go does not

sadly

[frank canopy]

terms used fairly interchangeably

[slim panther]

tagged union yea

[kind mantle]

More languages should do tagged,fat,discriminated,etc unions

[slim panther]

more languages should get rid of nullable shit

regardless of memory safety

[kind mantle]

100%

[loud ice]

yeah

on the other hand

sometimes it can be useful

[kind mantle]

Also why doesn't stuff like Java support having just a plain ol' struct in an array? why does it need to be full on class instances?

[slim panther]

when

[frank canopy]

java doesnt have plain ol structs lol

[slim panther]

c# has structs

[frank canopy]

or didnt last i checked

c# does yeah

[loud ice]

default init

[kind mantle]

I know and I'm mad

Also java is way too verbose for my liking

[frank canopy]

c# structs are great. you can even set explicit field offsets on them

[flat badge]

yeah java's type system is very limited

[slim panther]

kinda ironic

[kind mantle]

That's why I pointed out Scala

AFAIK still doesn't the struct

[frank canopy]

yeah no

scala still relies on the jvm so cant add structs properly

[kind mantle]

But at least it's got better types than java

[frank canopy]

yup

[loud ice]

if anyone wants to hear more shit about rust: the lack of TLS and async in the standard library is kinda ludicrous

literally every other good language has it

[fiery turtle]

huh

they dont have tls?

[loud ice]

nope!

[frank canopy]

god c#'s async is so good. legit the biggest reason i use c# for general high level stuff still

[fiery turtle]

well global variables are a crime in rust anyway

[kind mantle]

My opinion on language to use:

• Kernel -> C and maybe Rust
• Command-line -> Python
• GUI application -> It's a mess either way
• Embedded -> C

[loud ice]

for embedded rust is definitely better

[kind mantle]

I guess there's also:

• Website -> You're fucked

[fiery turtle]

for gui u really want inheritance

[slim panther]

website -> typescript

[fiery turtle]

which rust doesnt have

[slim panther]

[loud ice]

i mean what other options do you have lol

[loud ice]

which is like

what the actual fuck

[fiery turtle]

web assembly

[frank canopy]

website is typescript or js5 preferrably with as few libraries as possible and plain handwritten html

[loud ice]

good options i meant lol

[frank canopy]

speaking as a hobbyist web dev lmao

[fiery turtle]

lol

[frank canopy]

over the years ive migrated to modern js over typescript but both i still like to use on occasion

[hallow marten]

I think the JS ecosystem is fucked but react is pretty cool

[loud ice]

why not typescript?

[kind mantle]

Actually that's something I don't find myself missing when programming in Rust. Say about the borrow checker what you want but the way Rust simply prevents thread-safety bugs is very nice.

[fiery turtle]

btw for the typescript thing they chose go over c#

and that was microsoft themselves

soo

[hallow marten]

they had a reason

I forgot tho

[frank canopy]

this is why i said as few libraries as possible lmao, though i say also fuck react personally, give me jquery or give me nothing

[slim panther]

idk why

[frank canopy]

build system woes mostly

[hallow marten]

preact is pretty good for small stuff

[fiery turtle]

yes but what if its a thread local variable

[slim panther]

#[thread_local]

[kind mantle]

Rust does support thread-local storage but no matter the programming language I don't really find myself ever using actual thread-local globals and just pass around a context instead.

[fiery turtle]

so thats a thing

[loud ice]

gotta use jjquery

[frank canopy]

tbh i cant remember the last time i needed a thread local outside of kernel dev, where language threadlocal support isnt applicable anyway

[fiery turtle]

@loud ice did u mean something else by tls

[loud ice]

yes