[ home ] [ adv / b / hum ] [ a / mu / v / vis / tech / x ] [ meta / nexo ]

/tech/ - Tecnología

No rompas las leyes de Isaac Asimov






(Para eliminar)
  • Lee las reglas antes de postear y para dudas las FAQ.


No.5766

>strlen de complejidad O(N)
>sin monomorfización porque carece de zero overhead abstractions
¿Por qué los boomers siguen usando C (o holyC si son autistas) en 2024 el año de nuestro señor?
>>

No.5769

¿Pero cuantas veces usas strlen? Es más que mas da la complejidad de las funciones en C cuando está casi al nivel de código maquina, por mucho que la cague va a ser más rápido.

C es un lenguaje donde todo lo tienes que hacer tú y tú solo eres el culpable de todo lo que le pase. Y sí, un programador no puede hacer un programa perfecto, pero de poder existir ese programa sería en C. Al final todo lo que haces con otros lenguajes se puede hacer en C lo único que necesitas escribir más.
>>

No.5770

>>5769
>l-la complejidad no importa bro
Mentalidad de diletante amateur que jamás ha trabajado seriamente. Rust por ejemplo, puede rescatar &str.len() en complejidad O(1) y si añades sus optimizaciones e inmutabilidad estricta tienes un lenguaje de sistemas objetivamente superior.
>casi al nivel de código maquina
Los cniles de hecho creen esto lol. C jamás fue hecho para ser "de bajo nivel". C es un lenguaje que se adhiere estrictamente a una máquina abstracta especificada en un documento.
>C es un lenguaje donde todo lo tienes que hacer tú
Por eso mismo está obsoleto. Actualmente tienes lenguajes con zero cost abstractions con un rendimiento igual o superior al de C.
>>

No.5772

¿Hay algún otro lenguaje que permita manejar directamente el hardware como lo hace C? Lo pregunto en serio desde el desconocimiento.

>>5770
>C es un lenguaje que se adhiere estrictamente a una máquina abstracta especificada en un documento.
¿Y eso es malo? De hecho es lo que hizo a C tan popular. Y por ser tan antiguo no creo que esté caducado sino es lo que le da robustez. Dudo que Rust o Go tengan tantas librerías como C.
>>

No.5773

>>5772
No, no es "malo". Pero desmonta la creencia de que C es supuestamente mejor para lidiar con hardware porque "está casi al nivel del código máquina". C no es mejor que Rust o Zig.
>¿Hay algún otro lenguaje que permita manejar directamente el hardware como lo hace C?
Rust, y con él puedes incluso tomar ventaja de las abstracciones y optimizaciones inteligentes que C jamás tendrá, sencillamente porque está en vías de obsolescencia. Cuando C tenga monomorfizaciones o fearless concurrency entonces eso siquiera será tema de debate.
>Dudo que Rust o Go tengan tantas librerías como C.
No hay nada que C pueda hacer que Rust no haga ya, y mejor.
>Go
Go no es un reemplazo para C ni está al nivel de Rust porque tiene muchas decisiones de diseño terribles que nunca lo harán viable para ello.
>>

No.5774

>>5773
El problema de Rust es que no está ni cerca de soportar el mismo número de plataformas debido a que se basa en LLVM. GCC en cambio te emite código hasta para literalmente una tostadora. Hay un grupo trabajando en un compilador de Rust alternativo basado en GCC, pero lamentablemente aún le falta mucho y el desarrollo avanza demasiado lento.
>>

No.5775

>>5773
>>5774
Me faltó agregar: había otro grupo trabajando en una solución alternativa que era permitir que el compilador existente de Rust haga uso del codegen de GCC, eso se ve mucho más prometedor.
>>

No.5777

typedef struct
{
s64 size;
char *content;
} string;

Listo
>>

No.5787

>>5777
>s64 para tamaños
Cfag reinventa String de C++ pero mal por 99999ésima ocasión. Cuando se enteren que size_t existe. De cualquier forma esa estructura de datos es inferior a la de Rust.
>>

No.6021

>>5766
bump



[ ]
[Post a Reply]
[ home ] [ adv / b / hum ] [ a / mu / v / vis / tech / x ] [ meta / nexo ]