Portada
mis comunidades
otras secciones
#15:
"Rust addresses the memory management problem in C"
C no tiene ningún problema con la gestión de memoria. Lo que pasa es que C es superpoderoso, te da la herramienta para hacerlo todo. Y con gran poder viene gran responsabilidad. Si luego los programadores son incapaces de devolver la memoria que piden o se pierden con los punteros no es problema del C, es de la capacidad del programador. Si, los programadores son humanos, pero para eso estan los warnings.
Los lenguajes no se han hecho mejores. Unos han limitado sus capacidades para evitar los errores de los programadores, otros se han convertido al equivalente de los bloquecitos de madera de los niños, y otros por el contrario se han convertido en monstruos ininteligibles
Aun diré más. La abstracción con la máquina debería ser mínima. Un programador medio debería ser capaz de programar en ensamblador eficientemente en al menos una arquitectura. Pero lo que estamos haciendo es normalizar la pereza, el descuido y la ignorancia.
C no tiene ningún problema con la gestión de memoria. Lo que pasa es que C es superpoderoso, te da la herramienta para hacerlo todo. Y con gran poder viene gran responsabilidad. Si luego los programadores son incapaces de devolver la memoria que piden o se pierden con los punteros no es problema del C, es de la capacidad del programador. Si, los programadores son humanos, pero para eso estan los warnings.
Los lenguajes no se han hecho mejores. Unos han limitado sus capacidades para evitar los errores de los programadores, otros se han convertido al equivalente de los bloquecitos de madera de los niños, y otros por el contrario se han convertido en monstruos ininteligibles
Aun diré más. La abstracción con la máquina debería ser mínima. Un programador medio debería ser capaz de programar en ensamblador eficientemente en al menos una arquitectura. Pero lo que estamos haciendo es normalizar la pereza, el descuido y la ignorancia.
#26:
#15 No, lo que estamos haciendo no es normalizar la pereza y el descuido. Lo que estamos haciendo es ser más productivos.
Hace décadas lo caro eran los ordenadores y lo barato los programadores los cuales tenían que afinar sus programas porque los ordenadores no daban más de sí. Ahí un Ensamblador o un C era la apuesta necesaria.
Hoy en día sucede a la inversa, lo barato son los ordenadores y lo caro son los programadores. Como además los ordenadores son órdenes de magnitud más potentes puedes poner capa sobre capa de seguridad para que los ordenadores controlen lo que se está ejecutando liberando tiempo a los programadores para que éstos se centren en lo que deben: funcionalidades y reglas de negocio, no en si se me ha ido un puntero y la he cagado.
Sí estoy deacuerdo contigo en que todo programador debería saber cómo funciona un procesador por dentro, el mítico Motorola 68000 por ejemplo y cómo programarlo con ensamblador para saber qué ocurre por debajo. Pero eso no quita que debamos añadir más capas por encima por seguridad y para aumentar la productividad.
Como curiosidad, hay compañías aéreas cuyos mainframes se programan, todavía hoy, en ensamblador. He visto cosas que no creeríais
Hace décadas lo caro eran los ordenadores y lo barato los programadores los cuales tenían que afinar sus programas porque los ordenadores no daban más de sí. Ahí un Ensamblador o un C era la apuesta necesaria.
Hoy en día sucede a la inversa, lo barato son los ordenadores y lo caro son los programadores. Como además los ordenadores son órdenes de magnitud más potentes puedes poner capa sobre capa de seguridad para que los ordenadores controlen lo que se está ejecutando liberando tiempo a los programadores para que éstos se centren en lo que deben: funcionalidades y reglas de negocio, no en si se me ha ido un puntero y la he cagado.
Sí estoy deacuerdo contigo en que todo programador debería saber cómo funciona un procesador por dentro, el mítico Motorola 68000 por ejemplo y cómo programarlo con ensamblador para saber qué ocurre por debajo. Pero eso no quita que debamos añadir más capas por encima por seguridad y para aumentar la productividad.
Como curiosidad, hay compañías aéreas cuyos mainframes se programan, todavía hoy, en ensamblador. He visto cosas que no creeríais
#1:
Dentro de 50 años todavía existirá C y la base de casi todo seguirá estando escrita en C. Ya veremos entonces qué ha pasado con Rust...
Comentarios
"Rust addresses the memory management problem in C"
C no tiene ningún problema con la gestión de memoria. Lo que pasa es que C es superpoderoso, te da la herramienta para hacerlo todo. Y con gran poder viene gran responsabilidad. Si luego los programadores son incapaces de devolver la memoria que piden o se pierden con los punteros no es problema del C, es de la capacidad del programador. Si, los programadores son humanos, pero para eso estan los warnings.
Los lenguajes no se han hecho mejores. Unos han limitado sus capacidades para evitar los errores de los programadores, otros se han convertido al equivalente de los bloquecitos de madera de los niños, y otros por el contrario se han convertido en monstruos ininteligibles
Aun diré más. La abstracción con la máquina debería ser mínima. Un programador medio debería ser capaz de programar en ensamblador eficientemente en al menos una arquitectura. Pero lo que estamos haciendo es normalizar la pereza, el descuido y la ignorancia.
#15 Aunque estoy de acuerdo contigo en que el auténtico problema de la gestión de memoria en C está en los despistes del programador, no es menos cierto que al final las rutinas eran muy tediosas de programar: reservar memoria, hacer algo con las variables de tamaño variable, liberar memoria; cuando de eso puede encargarse automáticamente otro algoritmo que hace siempre lo mismo. Pierdes el potencial de gestionar tú mismo la memoria de un modo sencillo (aunque si quieres hacerlo, los lenguajes de alto nivel siempre te proporcionan algún modo de hacerlo), pero a cambio obtienes fiabilidad y menor número de líneas de código para hacer lo mismo. Las ventajas superan tanto los inconvenientes que actualmente es rarísimo de ver un lenguaje que no se comporte así por defecto.
#22 A mí personalmente me parece como comprarse un superdeportivo y limitar la aceleración..
#27 Más bien como hacerte tus propias tuberías o comprarlas pre montadas del leroi merlín. Con las tuyas tienes las medidas exactas, pero tienes que soldarlo todo, un codo mal soldado y tenemos una inundación. Con las de leroy no hay fugas, pero dependes de medidas standard y te tienes que adaptar a lo que leroy tiene.
#27 Casi todos los deportivos nuevos, tienen control de traccion, ABS y ESP y alguno menos Launch control. Ademas tiene corte de inyeccion cuanto te pasas de rpm y los automaticos cambian de marcha solo si te pasas de revoluciones aunque estes en modo manual.
En seguridad hay muchs resctriciones alguna no perjudican nada porque evitan ir por donde no necesitas ir. Algunas son mas intrusivas, pero o en muchos sistemas se procura que si falla una sistema de seguridad haya otro detras o varios e impedir que factor humano pueda crear un problema,.
#22 Ese "eran" de la primera frase se me ha clavao en el alma.
Tienes razón, todos tenéis razón, ya se trata de gustos y filosofías. Yo prefiero tener callos en los dedos de liberar memoria y tener el control, porque de darte cabezazos acabas teniendo un conocimiento avanzado del sistema. Con el otro sistema creamos juniors y seniors, pero no expertos.
#15 Amén. Palabra del senor.
#15 No, lo que estamos haciendo no es normalizar la pereza y el descuido. Lo que estamos haciendo es ser más productivos.
Hace décadas lo caro eran los ordenadores y lo barato los programadores los cuales tenían que afinar sus programas porque los ordenadores no daban más de sí. Ahí un Ensamblador o un C era la apuesta necesaria.
Hoy en día sucede a la inversa, lo barato son los ordenadores y lo caro son los programadores. Como además los ordenadores son órdenes de magnitud más potentes puedes poner capa sobre capa de seguridad para que los ordenadores controlen lo que se está ejecutando liberando tiempo a los programadores para que éstos se centren en lo que deben: funcionalidades y reglas de negocio, no en si se me ha ido un puntero y la he cagado.
Sí estoy deacuerdo contigo en que todo programador debería saber cómo funciona un procesador por dentro, el mítico Motorola 68000 por ejemplo y cómo programarlo con ensamblador para saber qué ocurre por debajo. Pero eso no quita que debamos añadir más capas por encima por seguridad y para aumentar la productividad.
Como curiosidad, hay compañías aéreas cuyos mainframes se programan, todavía hoy, en ensamblador. He visto cosas que no creeríais
#26 Evidentemente estamos cambiando habilidad por potencia y libertad por vigilancia, y el coste es desgraciadamente un factor muy importante. Pero me gustaba la humanidad cuando la habilidad, el esfuerzo y la inteligencia contaban más.
#29 Cuando los hombres eran hombres y se programaban sus propios drivers.
#26 no estoy seguro de que sea un tema solo de productividad, sino de que hay muchos programadores que no saben informática. Saben programar solamente; pero no tienen ni idea ni de lo que es la memoria de intercambio, por poner un ejemplo.
No creo que un buen programador (que sabe de informática) sea mucho más ineficiente en C que en un lenguaje de estos. El problema a veces es que hay programadores que vienen del mundo de los scripts o de las páginas web y cuando ven un puntero les da un síncope.
#36 Ese es otro tema y tienes razón, para que alguien pueda denominarse "desarrollador" o "programador" debería tener conocimiento desde cómo funciona un procesador con sus registros y sus cosas y de ahí hacia arriba en todas las capas, comunicaciones, hilos, sistema operativo. Luego puedes centrarte en una parte pero debes saber que hay un bosque alrededor de tu árbol.
#15 C no es superpoderoso porque C no gestiona la memoria.
Los superpoderosos son los programadores que tienen que lidiar con esas tareas. Y el software desarrollado, que es obviamente rápido.
Los lenguajes son herramientas para desarrollar productos vendibles, usables y seguros. Las mejores herramientas son las que te permiten hacer más trabajo con mayor seguridad en mejor tiempo. Por lo tanto, los lenguajes han ido claramente a mejor.
Lo que tú comentas es más programar por afición. Como quien se construye un coche en un garaje.
#35 C es SUPERpoderoso, porque el programador decide como gestionar la memoria. Otra cosa es que sepa como hacerlo eficientemente...
#46 Hoy en dia se suple tiempo de programacion con hardware mas potente. Se pierde menos tiempo en optimizar y usando L de alto nivel. Es mas barato el hardware que la hora de programador.
Tambien es un problema por supone mas gasto energetico.
http://cppcms.com/wikipp/en/page/rationale
#80 no en proyectos como el kernel de linux, o embebidos, donde la optimización del código se realiza de forma rutinaria, o en gestión de servidores.
Pero el problema de verdad es que se está perdiendo el contacto con el paradigma. Imagina que seguimos por este camino, y decidimos que no hace falta optimización a bajo nivel. Estaremos siendo ineficientes por diseño, y por tanto dejaremos , eventualmente, proyectos imposibles de Mantener.
Por eso es mejor dejar en cada capa de abstracción, un lenguaje que pueda acceder a todos los recursos de la máquina.
Y por lo menos en la próxima década, la base seguirá siendo Binario>assembly>C. A partir de ahí, ya puede poner el azúcar que quieras, pero de C hacia abajo, es todavía el imperio de las matemáticas y de las estructuras de datos 😉
#15 this.
C es difícilmente substituible, mayormente porque los sistemas operativos se hacen en C y ensamblador.
Requiere mucha madurez y un profundo conocimiento de la arquitectura de un sistema. Te obliga a saber de estructuras de datos, y en definitiva, a entender como piensa una CPU.
Rust tiene mucho camino por delante, y recomiendo aprender a escribir código en el , porque obliga al programador a usar prácticas seguras, pero hoy por hoy, C va a seguir siendo los cimientos de la computación.
Recuerdo que hace años, se quejaban de que con el lenguaje de moda se podía hacer todo, entonces no tenía sentido aprender un lenguaje anticuado llamado C. Eran los 90, lenguaje era Delphi. El profesor profetizo : en 20 años, nadie usará Delphi, pero seguirán existiendo las listas enlazadas, y se seguirá enseñando C.
Se ha cumplido casi por completo.
#15 C no tiene ningún problema claro, por eso llevamos décadas viendo fallos de segmentación, desbordamientos de buffer y de pila, deadlocks y data races, etc. que con suerte te cuelgan el programa, y sin suerte causan corrupción de datos o fallos de seguridad.
C ya era un lenguaje obsoleto cuando nació, la única razón por la que triunfó fue por la disponibilidad de compiladores gratuitos. A estas alturas merece morir y ser reemplazado por un lenguaje mejor.
Aun diré más. La abstracción con la máquina debería ser mínima. Un programador medio debería ser capaz de programar en ensamblador eficientemente en al menos una arquitectura. Pero lo que estamos haciendo es normalizar la pereza, el descuido y la ignorancia.
Claro que sí guapi. Yo aún diría más, un verdadero programador debería programar sus algoritmos en VHDL y sintetizarlos en una FPGA.
#43 "Yo aún diría más, un verdadero programador debería programar sus algoritmos en VHDL y sintetizarlos en una FPGA."
¿No se hace un ejercicio de eso en la carrera?
#45 Sí, claro que se hace. Yo tuve que implementar un micro RISC de 16 bits.
Que sepas hacerlo no significa que tenga sentido hacerlo, excepto en campos muy concretos. Es como pedirle a cualquier ingeniero que se ponga a resolver un modelo de elementos finitos a mano. Pues no, para eso tenemos software que te lo resuelve mejor que cualquier humano.
#15 En realidad lo has entendido mal. En Rust, estrictamente hablando, no hay gestión de memoria automática, lo que hay es, durante la compilación, una comprobación de que no estás haciendo cosas mal. Todo se hace con un analizador estático de memoria.
Un ejemplo: por defecto, cuando creas un bloque de memoria, ese bloque pertenece a la función que lo creó, y eso significa que si sales de la función, tienes que liberarlo. Pues bien: el analizador estático de Rust, durante la compilación, mira todas las posibles vías de ejecución, y si en alguna te olvidaste de llamar a free(), da un error de compilación. Por supuesto, es legal devolver un bloque de memoria, pero eso sólo mueve la responsabilidad a la función llamante: en ese caso, Rust nunca permitirá que llames a una función que devuelve un bloque de memoria sin asignar dicho bloque a un puntero; y, además, se asegurará de que antes de que la función termine, hayas liberado (o devuelto como valor de retorno) ese bloque. Si no lo haces, error de compilación.
Por supuesto puede ocurrir que pases un puntero a ese bloque de memoria como parámetro de una función: en ese caso la propiedad del bloque pasa a esa función, y ella tiene que, o devolver el bloque al final, o liberarlo ella. Y además, como la función ya no tiene la propiedad del bloque, cualquier uso de ese puntero DESPUÉS de la llamada (que no sea asignar un nuevo bloque, claro) también provocará un error de compilación, porque se supone que la función que recibió ese puntero liberó el bloque. Por supuesto, si la llamada está dentro de un IF, el bloque sólo se liberará si se ejecuta el IF, y eso el compilador lo tiene en cuenta y sigue todas las posibilidades, y sólo si en todos los casos haces lo correcto (liberar la memoria si no se ejecutó el IF, y no tocar el puntero si sí se ejecutó), no dará error de compilación.
Y como este último detalle puede ser un engorro en algunos casos, es posible "prestar" un bloque de memoria a una función; en ese caso la función llamante retiene la propiedad y sigue siendo responsable de liberarlo siempre, por lo que el compilador de Rust lo que se asegurará es que la función que recibe el bloque prestado jamás lo liberará, ni llamará con él a una función que lo libere (esto es, una función que espere recibir la propiedad de un bloque, en lugar de un préstamo).
Si te fijas, son exactamente las reglas que, se supone, hay que seguir en C, pero con la diferencia de que le das la suficiente información al compilador para que él pueda comprobar que las sigues. Es cierto que hay cosas que no provocarían fugas de memoria pero que este esquema no dejaría pasar (por ejemplo, si una función libera un bloque en función de un parámetro externo, y la función llamante lo libera en el caso opuesto), pero precisamente esos casos son los que se deben evitar, pues es fácil que un cambio posterior del código hecho por otra persona que no conoce completamente los entresijos de las funciones haga que surja una fuga de memoria o un dangler pointer (ahora no recuerdo como traducirlo, y no me apetece buscarlo).
Yo hice hace un par de años un proyecto en C y definí, de manera "manual", este mismo esquema: toda función que recibiese un bloque de memoria era responsable de liberarlo. El problema es cuando tienes una función compleja, con muchas posibilidades de bifurcación, y se te pasa liberarlo en una de ellas: por mucho que conozcas la regla, si tienes un error de ese tipo es fácil que ocurra un despiste, y luego ponte a buscar en el código de sopotocientos miles de líneas donde está.
Yo acabé usando un analizador estático para encontrarlo, porque no había manera. Y estaba escondido, estaba...
#54 Muchas gracias por la explicación y el trabajo que te has tomado. No conozco Rust mas allá de un par de tutoriales por curiosidad (y algunas cosas de la sintaxis ya me han dejado aturdido)
Evidentemente, estos lenguajes se desarrollan con el fin de mejorar la calidad del código y aumentar la estabilidad, y sobre todo, la ciberseguridad. La mayoría de las comprobaciones que indicas ya las hace el compilador de C. Las más profundas, como dices, se pueden hacer con un poco de orden y disciplina. Me citas una experiencia puntual. Igual para lo que serviría es para mejorar el procedimiento.
Lo que quiero decir es que no hace falta reinventar la rueda. Evidentemente, las macroempresas como Google o Amazon fomentan lenguajes que aumentan la productividad, porque la pela es la pela. Yo prefiero fomentar la excelencia.
En cualquier caso me refería a la crítica a la gestión de memoria del C, con la que justifican la existencia del lenguaje, no del lenguaje en sí.
#64 Perdona, pero nada de lo que he dicho lo hace el compilador de C en ningún momento: si yo hago un malloc en una función asignando el valor a un puntero, y no hago un free en ninguna parte, el compilador no dice ni mu. Como mucho, te suelta un warning si no asignas un valor devuelto a una variable (y, si no recuerdo mal, sólo con -Wall), pero en ningún momento analiza nada de lo que sí analiza Rust.
#15 Amen
#15 Un warning no siempre te va a cantar un memory leak, para ello va siempre bien tener herramientas de análisis de código estático. Por lo demás de acuerdo.
#63 Valgrind rules
#67 Cierto, y Klocwork.
Dentro de 50 años todavía existirá C y la base de casi todo seguirá estando escrita en C. Ya veremos entonces qué ha pasado con Rust...
#1 Tú espera 50 años a aprender Rust a ver que tal le va a tu carrera
#3 en el mejor de los casos,se ha sacado un grado superior(FP II para los abuelos) y de aquí a 50 años estará jubilado.
#5 Jubilación? Iluso, eso ni exisitirá
#5 ¿FP II no era el grado medio?
#7 Eso era FP I
#10 #12 pues estaba yo confundido, gracias.
#7 #10 #12 http://www.todofp.es/que-como-y-donde-estudiar/que-estudiar/ciclos.html
#19 Pues no conocía los cambios pero en esencia sigue siendo cierto lo que hemos dicho.
Con la novedad de que ahora FP es lo nuevo y Ciclo Formativo de Grado (Medio/Superior) es lo viejo, y han añadido FP básica para dar salida rápida a chavales de corta edad y alguna especialización.
#7 FP es grado medio, y FPII grado superior
#7 la FP de hoy en día no tiene nada que ver absolutamente con la de hace años. Ahora es cómo hacer un curso de CCC, dura menos, tiene muchas menos asignaturas y más enfocado a la práctica, puedes acumular varios si te sobra tiempo aunque aprendes más con cualquier tutorial de internet pero claro eso de grado superior suena como si fueras ingeniero y claro vende más, también es cierto que la FP antiguamente era una masacre, demasiadas asignaturas, demasiada teoría, demasiado larga, y caía demasiada gente por el camino..
#5 Si tienes un móvil con Android llevas código mío en tu bolsillo.
PD: Estudié filosofía, soy programador autodidacta.
#17 Por curiosidad, ¿qué es lo que has desarrollado?
#59 Llevo desde 2001 colaborando en el desarrollo del kernel de Linux.
#3 a nivel profesional en España, de momento no ha tenido mucha acogida.
Es verdad que hay factores como que es un lenguaje relativamente moderno, y que salvo en startups el resto del mercado suele ser bastante conservador.
#9 ¿vas a esperar a que se haga popular para aprender?
#13 ¿tu te aprendes todos los lenguajes nuevos que salen? Supongo que dormirás solo 1 hora al día.
#21 No sólo los que están en stackoverflow como los más valorados durante años consecutivos.
#72 Ahá. Yo valoro Scratch (es un decir), pero la realidad es que no está demandado ¿y dónde está Rust?
Top 5 most wanted languages:
Python: 25.7%
JavaScript: 17.8%
Go: 15.0%
TypeScript: 14.6%
Kotlin: 11.1%
The top most wanted languages are nearly identical to last year’s report.
(#21)
#13 Hay gente que no aprende nada de lo que paso con Ruby.
#28 Pues ahora me ha picado la curiosidad... ¿Qué pasó con Ruby? (no es una pregunta retórica)
#51 Hace ya unos cuantos años,llego ruby on rails,la hostia decían,había trabajo super bien pagado,mucha oferta y tal.
A día de hoy el trabajo que existe es muy poco,sigue con un salario decente,pero se paga mejor lo de siempre.
#53 es que ruby es un lenguaje de script más con un framework resultón (lo siento por los de ruby, que solo un poco menos susceptibles que los de python) que sirve para hacer páginas web de tamaño regularcillo, porque si quieres hacer algo grande usas un lenguaje grande para el backend y el frontend en lo que puedas, que sera lo mismo que el backend por simplicidad y para aprovechar gente.
Yo creo que Rust tiene mejor pinta porque es un C que no se enfada si olvidas el free, o sea, un C para torpes, y eso siempre gusta al que paga porque puede contratar a gente más torpe (ergo barata).
#56 ¿Te refieres a usar JavaScript en front-end y back-end o hay alguna otra opción y que realmente funcione bien?
Ruby es muy útil para hacer prototipos muy rápidamente, ése es uno de sus puntos fuertes. Por ese motivo aún se sigue usando en muchos contextos: puede ser más rentable para una empresa ir desplegando características nuevas cada semana que ir creando la aplicación perfecta durante meses para luego descubrir que lo que han hecho no interesa.
Tu argumento no me parece válido. ¿Has usado Rust? El tema de ownership y demás no es tan simple para los iniciados, incluso aquellos que llevan años programando en C y C++ tarda un tiempo en acostumbrarse.
Aún me sorprende que haya tanta gente que opine que proveer de mejores herramientas a los programadores implica que éstos sean peores. Especialmente cuando lo que se quiere es evitar errores que todos los programadores han cometido alguna vez en su vida.
#76 Aún me sorprende que haya tanta gente que opine que proveer de mejores herramientas a los programadores implica que éstos sean peores. Especialmente cuando lo que se quiere es evitar errores que todos los programadores han cometido alguna vez en su vida.
A mi me gustan esas caracteristicas para los que aprendemos, porque quita muchos vicios y te hace mas organizado. Tambien te hace ver pronto posibles problemas, justo cuando loas escrito y no cuando no te acuerdas ni lo que escribiste.
#75 Ups, era para #53
#51 ¿Qué es lo de siempre? En desarrollo web hay gente que te dirá que PHP. Si te refieres a consultoras supongo que seguirán con Java y demás.
Desde mi punto de vista, Node.js ha llegado a un punto en que está viéndose como la opción más rentable frente a las plataformas tradicionales (Ruby on Rails, Django, PHP, etc.) por la facilidad de trabajar sólo con 1 lenguaje y por las mejoras que se han ido añadiendo en las últimas versiones de JavaScript.
Eso sí, la productividad que permite Ruby como lenguaje creo que todavía está a otro nivel, al igual que la elegancia que se puede conseguir con poco esfuerzo.
#13 nope, de hecho en su día ya estuve mirandolo y haciendo pruebas.
Pero no cambia el hecho de que o te haces proyectos completos por tu cuenta, o trabajas con ello para adquirir la experiencia adecuada. El mirar un lenguaje un par de dias y no usarlo solo te vale para hablar en el desayuno.
Lo de preguntar a la gente que si van a esperar para aprender tecnologías con bastante hype, se asemeja a preguntar si vas a esperar a aprender suomi.
#9 Así nos va....
Comparando con otros países en este mismo sector. Nuestro sector profesional es mayoritariamente bodyshoping y consultoras que contratan otras consultoras. Entiendo que ahí no haga falta modernizarse y usar herramientas cada vez más expresivas.
#9 Como en todo el mundo.
Las empresas que ya funcionan con una tecnología les cuesta muchísimo esfuerzo cambiar a otra, los beneficios deben estar realmente claros.
En general, no está costando mucho pasar de Java a Kotlin porque es interoperable. No es el caso.
Pasar de C a Rust, se me ocurre que
1) Te obliga a reciclar a tus programadores C altamente cualificados. Algunos no habrán programado en nada más en muchos años. Todos cobrarán muy bien porque un novato no te sirve para sacar cosillas adelante, vienen viciados.
2) Te obliga a rehacer tu software desde cero. Con la inversión económica y pérdida de oportunidad laboral que eso conlleva.
Todo esto son suposiciones, por supuesto. Pero, en general, nadie va a cambiar de tecnología con sus productos en el mercado si no es interoperable o las mejoras son gigantescas. Es más sencillo utilizarlo para nuevos proyectos, nuevas empresas.
#32 En realidad, parece ser (ojo, hablo de oídas) que C y Rust es bastante interoperable. La gente de Gtk está escribiendo cosas con Rust, especialmente Federico Mena, y explican cosas como que es posible portar una biblioteca de C a Rust haciéndolo "función a función", y compilando entre medias para probar que todo vaya bien. Vamos, que parece que puedes reemplazar cachos de código en C por cachos en Rust sin demasiada complicación...
Lo que no quita, por supuesto, que el cambio de sintaxis y de concepto es lo suficientemente grande como para que no se pueda aprender en una tarde...
#1
Salvo lo que sigue escrito en COBOL
#8 Eso estaba pensando... ¿todavía siguen anunciando la muerte de cobol o ya se cansaron?
#20
No hace mucho en mi empresa anunciaron como tema innovador (no nos dedicamos al SW propiamente dicho) el paso de un sistema COBOL de una operadora a algo más modelno.
Y en banca, debe ser la leche.
#20 Es que los que anunciaban la muerte de COBOL murieron
#1 Año 1973, un friki cualquiera en la cafetería de Informática (la superior, la de 5 años, no la de peritos) de Berkeley, California:
- "Dentro de 50 años todavía existirá ASM y la base de casi todo seguirá estando escrita en ASM. Ya veremos entonces qué ha pasado con C... "
#14 En el 73 cambiar de modelos y lenguajes era sencillo y barato. Había cuatro gatos programando haciendo 4 programas.
Ahora mismo, el cambio se cobra bastantes réditos.
#55 Cambiar sí es caro. Mover todo el código de, por ejemplo, el kernel Darwin de C a Rust costaría un pastizalamen en developers y una pechá de tiempo en años de curro.
Desarrollar cualquier cosa nueva usando Rust, más seguro y más moderno y más sencillo, en lugar de usando C no sólo no tiene repercusión alguna en el coste inicial, sino que a la larga sale más barato.
Y todas las nuevas generaciones de programadores que lleguen usarán Rust en lugar de C, exactamente igual que otras generaciones usaron C en lugar de ensamblador para programar sistemas y Python en lugar de Java para programar aplicaciones web.
Así que sí, habrá cambio. Es sólo que por supuesto no habrá cambio total mañana a las 8am UTC con todo el planeta migrando a Rust, pero cambio habrá. Ya lo creo que lo habrá. Básicamente porque Rust es la evolución lógica de C que lo mejora y no hay motivo para no empezar tu nuevo proyecto en Rust en lugar de en C.
#61 Peino canas. He escuchado este discurso antes. Con C, con Cobol, con PL1...
De aquí a 15 años te lo recuerdo.
#61 ¿Qué te hace estar tan seguro con el cambio hacia Rust? ¿Los gurús hablan bien de él? ¿Aumento de la demanda de programadores en Rust? ¿Tienes una Palantir?
#71 Ojo con las palantir. No sabes quien más puede estar mirando...
Me gustaba más en videojuego.
La idea de que los objetos tengan atributos relacionados con el uso del objeto en memoria reducirá el tipo de descuidos que convierten en vulnerables a muchos programas.
#2 same un ejemplo!
No verán nuestros ojos la caída del lenguaje C.
Relacionada:
Microsoft está valorando usar Rust
Este es el año de Rust en el escritorio
#47 Sí, estoy de acuerdo. Nunca me ha gustado la sintaxis de C y C++. Pero es lo que todos copian.
Yo hablo de la sintaxis porque es un escollo para la conversión del código ya existente. Si vas a hacer un lenguaje similar a C, pues hazlo lo más parecido posible para facilitar la migración. De lo contrario haz algo diferente como python.
A ver... Rust es bastante similar a C. OK. A demás cambia algunas cosas para evitar los problemas de C con el acceso a memoria. Bien. Pero...
Una función en rust es así:
fn main() ">
Mientras que en C es así:
void main() ">
Un diría ¿y qué? Un cambio que en principio parece que no hace daño...
¿Cuál es el problema? Que yo hubiera hecho hecho Rust lo más parecido posible a C e incluso habría trabajado en un convertidor automático de C y preferentemente también de C++ a Rust.
Eso habría permitido demostrar la utilidad de Rust portando miles de programas existentes. Imagina todo un linux convertido a Rust. Podrían anunciarlo como que es mucho más seguro. La gente lo probaría y su funciona como mínimo igual que antes, el lenguaje se adoptaría rápidamente. Muchos proyectos pensarían en convertir el lenguaje y sus siguientes versiones dirctamente trabajarlas en Rust. Pero así... dudo que avance muy rápido...
#38 Si quieres atraer a los usuarios de C, lo último que deberías incluir es características de Cpp.
La gente de C, normalmente aborrece al primo pijo.
#41 Supuestamente Rust busca reemplazar a C y a C++. Así que yo habría hecho que se pudiera convertir automáticamente ambos lenguajes.
Esto es parecido a lo que pasa con Android: Si Huawei quiere sacar un sistema que reemplace a Android, tiene que poder ejecutar aplicaciones Android de forma transparente. Ya después, y si tiene éxito de verdad reemplaza a Android, puede que los desarrolladores se vuelquen a hacer aplicaciones nativas para ese sistema.
Con cualquier lenguaje que pretenta reemplazar a C y C++ lo que se necesita es que el reemplazo tenga una dificultad mínima para seguir usando el mismo software de antes. Si tiene éxito los programadores se volarán a utilizarlo directamente y aprenderán sus ventajas.
#41 Una guerra cada vez, por favor
#38 No por favor, la enésima discusión sobre sintaxis no... Es un bikeshedding de manual: https://es.wikipedia.org/wiki/Ley_de_Parkinson_de_la_trivialidad
La sintaxis de C y C++ son un coñazo, escribir un parser es bastante difícil (gramática sensible al contexto, macros, includes, etc.) y algunas declaraciones son absurdamente complejas (intenta declarar un array de punteros a funciones y llora). La sintaxis de Rust, sin ser la más legible del mundo, es mucho más clara.
#38 Edit