Portada
mis comunidades
otras secciones
#25:
#20 La diferencia entre un minero de uranio, que lo hace para sobrevivir (y que no tiene otras opciones), y alguien que gana 150k/año reside precisamente en que el segundo no necesita ese puesto de trabajo para vivir bien (no cobro 150k, pero sigo cobrando de puta madre); podría estar haciendo muchas otras cosas... y sin embargo decide participar en una actividad dañina a todas luces por una ganancia personal marginal.
No, no es solo un puesto de programador.
No, no es solo un puesto de programador.
#17:
#12 Te parecerá una postura de privilegiado, pero sí, es un problema moral de los gordos. Una tras otra, casi todas las empresas metidas en el ajo acaban cerrando, o metidas en follones legales por multitud de causas: lavado de dinero, evasión de impuestos, insider trading, robo, estafa, vulneración de protección de datos, etc.
Y eso sin contar con que han desestabilizado por completo el mercado de producción de chips, procesadores y tarjetas gráficas; o que han aumentado los niveles de contaminación de forma alarmante.
Yo mismo estuve en una hace años, cuando era algo más inocente, y a la que el negocio empezó a ir mal, el jefe ya estaba maquinando... ninguna de sus ideas era legal ni ética, pero no le importaba lo más mínimo (dimitimos todos en bloque al ver el percal).
Y eso sin contar con que han desestabilizado por completo el mercado de producción de chips, procesadores y tarjetas gráficas; o que han aumentado los niveles de contaminación de forma alarmante.
Yo mismo estuve en una hace años, cuando era algo más inocente, y a la que el negocio empezó a ir mal, el jefe ya estaba maquinando... ninguna de sus ideas era legal ni ética, pero no le importaba lo más mínimo (dimitimos todos en bloque al ver el percal).
#16:
Mucha c-nilidad (léase con acento americano) veo aquí. Mucho me temo que este es el futuro: a partir de ahora, el software de sistema tenderá a escribirse cada vez más en lenguajes con seguridad de memoria.
Venir en pleno 2022 con que el problema son los malos programadores es no tener ni puta idea de cómo andan las cosas en el mundo en materia de seguridad. Antes estaba la excusa de que no había elección que arriesgarse si querías usar un lenguaje sin recolector de memoria. Pero tras la aparición de Rust eso cambia, y la tendencia va a ser arrolladora: o el lenguaje garantiza la seguridad de memoria, o se irá quedando al margen de los desarrollos más modernos.
Venir en pleno 2022 con que el problema son los malos programadores es no tener ni puta idea de cómo andan las cosas en el mundo en materia de seguridad. Antes estaba la excusa de que no había elección que arriesgarse si querías usar un lenguaje sin recolector de memoria. Pero tras la aparición de Rust eso cambia, y la tendencia va a ser arrolladora: o el lenguaje garantiza la seguridad de memoria, o se irá quedando al margen de los desarrollos más modernos.
#1:
Si lo dice Microsoft, habrá que olvidar el Rust y volver al C
#21:
#1 #2 Recordemos que en unas pocas semanas se acabará de integrar la primera pieza de código escrito en Rust dentro del kernel Linux (para la versión 6.1, o la 6.2 si hubiera algún problema de última hora).
Esto no viene de Microsoft, de hecho ellos van a remolque. El lenguaje nació en Mozilla, y ya se está usando en muchas otras grandes empresas: Amazon, Facebook, Google, Discord, obviamente Microsoft, RedHat...
Esto no viene de Microsoft, de hecho ellos van a remolque. El lenguaje nació en Mozilla, y ya se está usando en muchas otras grandes empresas: Amazon, Facebook, Google, Discord, obviamente Microsoft, RedHat...
#28:
#1 No es que lo diga Microsoft. Empiezo a leer y dice "Mark Russinovich...". Este tio no es un cualquiera.
https://learn.microsoft.com/en-us/sysinternals/
https://learn.microsoft.com/en-us/sysinternals/
#78:
#66 No soy precisamente pro-microsoft, pero ya que hablas de cosas malas, tienen cosas buenas, como VSCode, por ejemplo, typescript creo que también está diseñado por Microsoft. El WSL funciona bastante decente, aunque sea peor que un Linux nativo, obviamente.
Hacen cosas mal, como todos, pero ponerlos como que no saben de tecnología...
Hacen cosas mal, como todos, pero ponerlos como que no saben de tecnología...
#117:
#59 porque no se usa en condiciones. Desde C++11 usando smart pointers no tienes una fuga de memoria. 4 años en un equipo con 15 personas programando y no un problema de memoria. Y yo era el último que lo último que conocía era C++03 y flipé con el avance y facilidad en el 11.
Pero mejor usamos Java que si recolector es una maravilla...
#102 tengo interés, de verdad , en saber el sin coste computacional ese cuánto es. Igual sí que es tan maravilloso como lo pintan. Pero en C++ ya tienes tipo auto, iteradores y punteros inteligentes que te salen unos bucles que nada que envidiar a python.
Pero mejor usamos Java que si recolector es una maravilla...
#102 tengo interés, de verdad , en saber el sin coste computacional ese cuánto es. Igual sí que es tan maravilloso como lo pintan. Pero en C++ ya tienes tipo auto, iteradores y punteros inteligentes que te salen unos bucles que nada que envidiar a python.
#43:
#10 perdona si discrepo de tu opinión. C++ y en mayor medida C son lenguajes altamente utilizados y expuesto a la comunidad, lo que los hace altamente testado. Es al utilizarlos mal es cuando empiezan los problemas. O cuando se descubre una vulnerabilidad asociado a una libreria de hace más de 20 años... ¿volvemos al problema del efecto 2000?
Pero puesto a echar mierda, empecemos por Java - y a continuación ponga su lista preferida.
Pero puesto a echar mierda, empecemos por Java - y a continuación ponga su lista preferida.
#81:
#48 La verdad es que sin conocer lo que sabes o desconoces, no sé por dónde empezar, pero te aseguro que no hay absolutamente nada positivo en ese sector, más allá de las buenas intenciones de algún pobre inocente.
Te lo digo habiendo trabajado en ello, habiendo pensado mucho tiempo en ello, tanto en los aspectos tecnológicos, como en los económicos y sociales; y habiendo estado en contacto directo con la industria, conociendo a quienes la integran, y sus intenciones.
Joder, es que da para escribir un libro de los gordos. Estilo "No Logo", pero aun más salvaje.
Te lo digo habiendo trabajado en ello, habiendo pensado mucho tiempo en ello, tanto en los aspectos tecnológicos, como en los económicos y sociales; y habiendo estado en contacto directo con la industria, conociendo a quienes la integran, y sus intenciones.
Joder, es que da para escribir un libro de los gordos. Estilo "No Logo", pero aun más salvaje.
#3:
"el 70% de todos los errores de seguridad graves en la base de código de Chrome eran errores de gestión de memoria y seguridad".
¿Quien co*o ha redactado esto? Es como poner
"La mayoría de los inmigrantes de EE.UU. son centroamericanos e inmigrantes."
¿Quien co*o ha redactado esto? Es como poner
"La mayoría de los inmigrantes de EE.UU. son centroamericanos e inmigrantes."
Comentarios
#20 La diferencia entre un minero de uranio, que lo hace para sobrevivir (y que no tiene otras opciones), y alguien que gana 150k/año reside precisamente en que el segundo no necesita ese puesto de trabajo para vivir bien (no cobro 150k, pero sigo cobrando de puta madre); podría estar haciendo muchas otras cosas... y sin embargo decide participar en una actividad dañina a todas luces por una ganancia personal marginal.
No, no es solo un puesto de programador.
#25 eres camarero o algo así?
#25 Enhorabuena. Y gracias.
#25 Como dijo un famoso filántropo, dedicate a lo que más rentable te salga para ganar dinero, luego ya limpiarás tu conciencia donando una parte.
#40 Lo del "effective altruism" es una forma muy, muy burda de utilitarismo (que no tiene en cuenta aspectos básicos como el típico "factor de descuento" que hay que aplicar a retornos futuros). No me voy a poner a desmontarlo aquí porque es mucho trabajo para mi, que no me dedico a la filosofía; pero no es difícil encontrar muy buenas explicaciones al respecto.
#52 No te molestes en desmontar nada, la gracia de "famoso filántropo" es porque uno de sus mayores impulsores (y captadores de ese tipo de donaciones) es Bill Gates.
#25 danina a todas luces?
Muchos la consideramos beneficiosa para la humanidad, aunque con aspectos negativos, como todo.
Sí, tu trabajo también tiene aspectos negativos.
#48 La verdad es que sin conocer lo que sabes o desconoces, no sé por dónde empezar, pero te aseguro que no hay absolutamente nada positivo en ese sector, más allá de las buenas intenciones de algún pobre inocente.
Te lo digo habiendo trabajado en ello, habiendo pensado mucho tiempo en ello, tanto en los aspectos tecnológicos, como en los económicos y sociales; y habiendo estado en contacto directo con la industria, conociendo a quienes la integran, y sus intenciones.
Joder, es que da para escribir un libro de los gordos. Estilo "No Logo", pero aun más salvaje.
#81 pues sin entrar en detalles, conozco bastante el sector y sí le encuentro cosas positivas.
Tampoco creo que lo conocía absolutamente todo como para afirmar que no ha nada bueno. Un poquito más de humildad.
Pero bueno, así en abstracto tampoco vamos a llegar mucho más lejos.
Si lo dice Microsoft, habrá que olvidar el Rust y volver al C
#1 Ostia, venia a decir lo mismo
#2 Microsoft es esa gran empresa que bien entrados los años 90 seguía sin verle las ventajas al protocolo TCP/IP y nos daba la turra con lo bueno que era el NetBIOS. Están para dar muchas lecciones.
#4 Sin mencionar las maravillas del .NET...
#6 El .NET como lenguaje no es tan malo. Es un competidor de Java y es muy portable, así que tiene sus ventajas. Dicho esto, donde esté el código nativo. . .
#7 .NET no es un lenguaje, es un runtime + "ecosistema". Pero dejando eso de lado (asumiré que simplificabas), tiene muchos otros problemas, como que su "fundación" no es realmente independiente de Microsoft, y cada dos por tres traicionan a sus desarrolladores, tomando decisiones que los fuerzan a usar las herramientas de Microsoft, en detrimento de otras opciones abiertas y compatibles.
https://isdotnetopen.com/
#11 Me refería al argumento técnico. Comparado con otros sistemas del estilo, no está tan mal. Yo por lo menos lo prefiero por encima de Java.
#11 hoy en día se puede desarrollar en .NET en Linux o Mac sin problemas. Te lo digo yo que lo hago.
#39 En ningún momento he negado eso.
#46 podrías ser más concreto con esto, entonces?
tomando decisiones que los fuerzan a usar las herramientas de Microsoft,
#c-53" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3726785/order/53">#53 He enlazado una página bastante interesante, más arriba en el hilo, donde se exponen casos bastante salvajes de actos deshonestos por parte de la .Net Foundation. Esa página no es ni mucho menos exhaustiva.
Admito que no toco C# más allá de 4 chorradas cuando cacharreo con Godot para mis experimentos personales, pero uno de mis motivaciones para evitarlo ha sido su historia llena de baches a la hora de soportar sistemas como Linux (primero con Mono, que siempre iba por detrás y luego fue absorbido), o las dificultades para acceder a buenas herramientas de debugging que fueran libres (de hecho uno de los casos que más me escandalizó estaba relacionado precisamente con esto último).
#67 ya, bueno, estoy de acuerdo, el . NET antiguo no lo hubiera tocado ni con un palo.
Pero llevan muchos años ya dando pasos de gigante en dirección al openness (como se diría esto en castellano?) y, sinceramente, no veo eso de que te fuercen a usar herramientas de Microsoft.
Es todo lo contrario, ahora puedes usar hasta docker fácilmente.
#71 así es, además ahora están lanzando MAUI para correr apps de escritorio en Windows, android y Mac. Eso sí, para Linux no lo han sacado pero la comunidad ya está dándole para que lo he hecho con Maui corra en Linux
#67 desde hace dos años, con el lanzamiento de .net 5 la cosa ha cambiado.
Ahora está .net 6 y en nov sale .net 7, desde el .net 5 alucinas con lo fácil que es lanzar una web corriendo sobre un docker con alpine linux (con menos de 150mb tienes el docker de SO + .net6 corriendo asp.net)
#39 Con Mono?
#11 "foundation" significa base, no fundación
#98 Es polisémico. Estoy todo el día hablando inglés con americanos, británicos e irlandeses, y llevo años leyendo cientos de libros y miles de artículos en inglés, lo tengo bastante claro.
#98 cimientos, mas que base (en este contexto)
#7 si competidor significa copia con mil añadidos que lo hacen peor
#4 tienes un ejemplo de este milenio?
#55 Windows Vista. Windows 8. Zune. Toda la cosa de móviles. Cortana. Algunos ya citan el Win11 (en esto no estoy de acuerdo. . . porque es que es lo mismo que 10).
#58 Su nube va mayormente con Linux. Obvio. Hasta tienen su propia distro para usar en Azure.
#66 ¿esos son ejemplos de qué, cosas que no funcionaron? Todas las empresas tienen montones. No sé a donde quieres llegar.
#66 No soy precisamente pro-microsoft, pero ya que hablas de cosas malas, tienen cosas buenas, como VSCode, por ejemplo, typescript creo que también está diseñado por Microsoft. El WSL funciona bastante decente, aunque sea peor que un Linux nativo, obviamente.
Hacen cosas mal, como todos, pero ponerlos como que no saben de tecnología...
#78 Desde que se fue Steve Balmer (developers, developers...) y llegó el indio, M$ ha cambiando mucho. Ahora es una empresa muuucho más seria que cuando estaban como CEOs Gates o Balmer. Tienen una de las tres nubes públicas más grandes, están metidos en IA (colaboran con OpenAI), tienen buenos ingenieros como Russinovich que saben de lo que hablan con lo de Rust, etc...
#4 si profundizas un poco más, Microsoft sabe bien lo que se hace. Creo que han aprendido de los errores del pasado. Ahora, no sé si es algo bueno o malo...
#4 antes era MS quien estaba outdated... Ahora MS está en la ola, y en cambio vosotros estáis outdated... Qué irónica es la vida.
#4 A ver, en este caso, y viendo que muchos proyectos libres están refactorizando en Rust, y que el propio kernel de linux que desde su nacimiento no ha admitido más lenguajes de programación en la próxima release se espera compatibilidad con Rust, igual no van desencaminados. Aunque sea Microsoft.
Hasta un reloj parado da la hora correcta dos veces al día.
Y hay que tener en cuenta que el lenguaje lo creó Mozilla, y ahora está en manos de su propia fundación (Rust Foundation).
#1 #2 Recordemos que en unas pocas semanas se acabará de integrar la primera pieza de código escrito en Rust dentro del kernel Linux (para la versión 6.1, o la 6.2 si hubiera algún problema de última hora).
Esto no viene de Microsoft, de hecho ellos van a remolque. El lenguaje nació en Mozilla, y ya se está usando en muchas otras grandes empresas: Amazon, Facebook, Google, Discord, obviamente Microsoft, RedHat...
#21 Tengo la sana costumbre de desconfiar de Microsoft, llámame loco
#22 Hombre, de otras cosas tiene todo el sentido del mundo, tampoco les tengo cariño; pero decir que "Rust caca" porque MS lo promueve es como decir que ahora hay que contaminar porque los de Iberdrola hacen anuncios de molinos de viento.
#1 Estos de Microsoft culpando al lenguaje de sus chapuzas. No se podía esperar más de ellos.
#5 No sé si te dedicarás a esto, pero me huelo que no. Esto no lo dice sólo Microsoft, de hecho son de los últimos en apuntarse al carro. Que C y C++ son un nido infecto de agujeros de seguridad llevamos sabiéndolo desde hace 20 años, o más.
#10 Lo que no sé por qué los ponen juntos, supongo que será porque son los mas usados en sistemas operativos, porque C y C++ son dos mundos diferentes con distinta gente detrás.
#30 porque son los más usados ahora mismo
#30 Son muy distintos, pero tienen conexiones históricas, y los dos se usan para hacer software de "alto rendimiento". Además de que muchas herramientas están diseñadas para trabajar con los dos a la vez.
#54 y ya que estás, tienes enamorado a medio meneame por tu sueldo y trabajo, deberías hacer un preguntame o algo similar cuando tengas tiempo para cotillear como has llegado ahí y contarnos que problemas éticos y morales te has encontrado por el camino.
#61 Supongo que podría responder preguntas, pero sin ser famosillo ni haber expuesto qué hago en realidad, no sé si la gente tiene material suficiente como para poder hacer demasiadas preguntas.
Ojo, se gana bien, pero no es el paraíso, o no para todos.
Disclaimer: lo que sigue es una simplificación MUY burda, no se me juzgue por ella; que esto no es un artículo académico.
Es un oficio algo extraño, igual que pasa con el futbol o algunos deportes, tenemos una cierta "élite" (3 grupos: "académicos", "industria", "influencers"), y "clase media", y luego toneladas de gente que pringa más de lo debido. En ese esquema, yo he sido un pringuis durante mucho tiempo, y ahora estoy en esa "clase media acomodada".
#61 #76 me he quedado con la duda, que trabajo?
#30 Porque ambos comparten el mismo problema. La gestión de la memoria. Que justamente es de lo que se queja MS, los de Chrome y todo el mundo
#59 porque no se usa en condiciones. Desde C++11 usando smart pointers no tienes una fuga de memoria. 4 años en un equipo con 15 personas programando y no un problema de memoria. Y yo era el último que lo último que conocía era C++03 y flipé con el avance y facilidad en el 11.
Pero mejor usamos Java que si recolector es una maravilla...
#102 tengo interés, de verdad , en saber el sin coste computacional ese cuánto es. Igual sí que es tan maravilloso como lo pintan. Pero en C++ ya tienes tipo auto, iteradores y punteros inteligentes que te salen unos bucles que nada que envidiar a python.
#10 ¡ Y los cuchillos cortan !
#10 perdona si discrepo de tu opinión. C++ y en mayor medida C son lenguajes altamente utilizados y expuesto a la comunidad, lo que los hace altamente testado. Es al utilizarlos mal es cuando empiezan los problemas. O cuando se descubre una vulnerabilidad asociado a una libreria de hace más de 20 años... ¿volvemos al problema del efecto 2000?
Pero puesto a echar mierda, empecemos por Java - y a continuación ponga su lista preferida.
#43 muy bien explicado.
#57 ¿Bien explicado? Pero si no sabe ni hacer hacer coincidir el género de un sustativo y un adjetivo varias veces en su escrito, faltan signos de puntuación y está muy mal redactado. Además, ¿qué tiene que ver el efecto 2000 en todo esto? Este ha escuchado tiros pero no sabe por donde...
#43 Perdona si desconfío de tus conocimientos en programación de sistemas a bajo nivel, o de seguridad en sistemas críticos.
#65 no , a ver.. si te entiendo, hablar de ax o mov es un coñazo. Por no hablar de hacerlo en lenguaje máquina... Sobre los sistemas críticos, pues depende si hablamos de sistemas de vigilancia o de sistemas de gestión para el control de la señalización.. ahí me pillas algo frio.
#43 Nadie se acuerda de Fortran?
#10 sera un nido infecto el código realizado en esos lenguajes. Que son los más usados desde hace 50 años y por eso obviamente se decubren más agujeros de seguridad en C que en ADA que no lo usa ni Perry. Además programar en C o C++ requiere una disciplina mayor que en otros lenguajes, donde se facilitan algunas cosas.
#49 No hablo (ni yo ni el resto de proponentes de Rust, o críticos de C/C++) de cantidades absolutas, sino de proporciones. Proporcionalmente, el código en C y C++ contiene muchos más errores graves que el código escrito en Ada, o Haskell, o Rust (y lo mismo pasa si comparamos JavaScript con TypeScript, precisamente porque TS aplica reglas más estrictas).
No se trata sólo de tener "mal código" o "malos programadores". Es demasiado fácil cometer errores sutiles (pero graves) en C y C++. Esto no es tampoco una opinión de 4 academicistas, ni de puristas. Se ha demostrado por activa y por pasiva que había que encontrar mejores soluciones que lo que C y C++ nos ofrecían.
Y son los más usados por motivos históricos, no porque fueran especialmente mejores que otras opciones, el concepto de "accidente histórico" existe por algo. En el caso de las tecnologías también tenemos el concepto de evolución dependiente del camino "path dependent" (es decir, que ciertas decisiones no se tomaron por ser las "mejores", sino por los pasos dados previamente).
#64 Gran parte de los errores que se cometen en C son debidos a que es un lenguaje más antiguo que otros no a que sea un mal lenguaje.
Descargar la tarea de gestión de memoria en el programador ahora es un riesgo pero el peor rendimiento de lenguajes más modernos al respecto como Java no era posible con los procesadores de hace 30 años.
Y lo digo con conocimiento de causa que empecé a programar en Java en 1998.
#84 Ya en la época de C había lenguajes con mejores propiedades (como mejores sistemas de tipos, sin irnos a rollos academicistas como Haskell), y que ofrecían rendimientos similares. Lo que lo hizo ganar terreno sobre todos los demás fueron 3 factores:
- que se usó en UNIX
- que se usó para crear las "libc" que a día de hoy aglutinan toneladas de funcionalidades básicas para interactuar con los sistemas operativos.
- era fácil de implementar compiladores de C, se podían hacer compiladores "de una sola pasada", que son más simples que los compiladores de múltiples pasadas.
C no es malo sólo por la gestión manual de memoria, lo es también por su sistema débil de tipos, por sus macros horrendas, por sus ficheros de cabecera, por su ecosistema de herramientas, por las decisiones incomprensibles tomadas por el comité ISO...
Ejemplo: Tenemos Zig, que también necesita que el programador gestione la memoria, y sin embargo es mucho más limpio como lenguaje.
#89 tener un sistema débil de tipos no es malo per sé. Como no lo es delegar en el programador la gestión de memoria, peor es a veces un colector de basura, sino mirad los problemas que da el de java.
#89 Es que C no tiene sistemas debil de tipos... es que no tiene... esas ... ... no se como describirlas, que nos haciamos hace anios con C en plan usar punteros a cosas que no tenias que usar y castings en plan enfermizos... era ... era magnifico y te creias el puto amo, pero era una series de niapas de cojones que ni en Fortran.
#82 La filosofia de rust es hacer abstracciones sin coste computacional. Por ejemplo, hacer los bucle for al estilo de los iteratores de Python, en lugar de un for tipo C con su indice y demas. Hay cosas que se pueden simplificar sin que aumente el coste computacional.
El rendimiento o eficiencia es muy similar a C, sin sus riesgos.
Hay cosas que son dificil de corregir en tecnologias ya hechas porque son intrinsecas. Tdos conocemos caso que es mejor empezar de 0 que arreglar lo fallido.
En esta pagina pormenoriza los fallos de diseño de Xmpp y explica que algunos son dificiles de cambiar y se podria usar en un protocolo nuevo como Protocol for SYnchronous Conferencing
https://about.psyc.eu/XMPP#Why_don.27t_you_help_XMPP_getting_better_instead_of_spending_so_much_time_documenting_its_weaknesses.3F
#64 #16 En Aviacion hay mucho mecanismo pensando en que siempre hay fallos humanos o tecnicos y como pararlos antes de que creen algo grave.
En la industria y otros campos hay mecanismos de simpleza asombrosa, que evitan fallo que pueden ser graves o no. Por ejemplo, que una pieza que no debe ponerse en otra posicion se diseñe para que no se pueda poner en otra posicion.
https://es.m.wikipedia.org/wiki/Poka_yoke
En los coches, tambien se estan poniendo sistemas para que el coche frene si no lo hace el conductor. Aunque un conductor no debe distraerse nunca.
Hay cosas en las que los humanos son proclives a fallos y las maquinas hacen mejor que los humanos. Ejemplo, mantener una velocidad, rumbo y altura.
#64 Esta claro que en ADA simplemente por tener una sintaxis más estricta, ya es más dificil cometer errores y más facil trazarlos, pero oye aprendes en ADA y luego programa en C como si programaras en ADA, se reduciran mucho los errores.
C se usaba mucho por historia, de acuerdo, lo he dicho yo también.
En cuanto a ser mejor solución que otros... pues depende que vayas hacer o programar C para mí es un lenguaje de nivel medio, para integrar cosas a bajo nivel es normal que se use, por lo tanto para desarrolar un SO, su kerneel, también me parece lógica su elección, si RUST supone un avance adelante con él. Pero C y C++ cumplieron durante muchos años y mierdas se han hecho en todos los lenguajes, dudo que el porcentaje de errores graves de código realizado por programadores expertos sea mucho mayor en C que en otros lenguajes.
Un saludo.
#1 Microsoft es probablemente la empresa con más experiencia en software de sistema, así que sabe de lo que habla.
#14 Pues si. La han cagado tantas veces que tienen un montón de experiencia.
#15 La han cagado como empresa, pero eso no significa que todos sus desarrolladores destacados sean culpables de ello.
#18 Las decisiones en una empresa de estas las toman habitualmente los directivos, como el aquí mentado. Nadie ha responsabilizado a los desarrolladores.
#19 Pero justo dices:
> La han cagado tantas veces que tienen un montón de experiencia.
refiriendote a su experiencia en "software de sistema" (del comentario anterior), no soy yo quien omite el contexto.
#23 La "experiencia" son las decisiones directivas acumuladas. El apostar por cosas que luego no han funcionado. Los desarrolladores harán lo que les manden, no son los que deciden el rumbo.
#24 estás bastante equivocado. Microsoft tiene bastantes desarrolladores "cracks" (para eso les pagan pastizales) con poder suficiente para tomar decisiones de este tipo.
Por ejemplo, vscode está hecho en TS/nodejs porque les salió del nardo.
#15 Pues hora lo estan petando en el cloud no?
#58 En cloud y en un montón de cosas. Desde que se fue Ballmer la empresa va como un tiro.
#1 No es que lo diga Microsoft. Empiezo a leer y dice "Mark Russinovich...". Este tio no es un cualquiera.
https://learn.microsoft.com/en-us/sysinternals/
#28 venía a decir esto, es el CTO y como desarrollador fue el que descubrió el rootkit de Sony que fue todo un escándalo en su momento. En ese momento tenía su propia empresa donde había creado multitud de herramientas para facilitar el mantenimiento de Windows y es considerado un programador talentoso... en C y C++.
Su empresa fue adquirida por MS y él ha escalado hasta ser CTO de MS.
#28 Si es que él mismo lo dice en el propio artículo, que se inclina por Rust pero que aun queda mucha vida a C y C++. Aquí muchos asesinando lenguajes y empresas, extremando posturas, y esto no es una cuestión de elegir y defenestrar nada, sino de complementar y evolucionar.
Un par de días después de esta declaración, Russinovich volvió a sacar el tema en su Twitter. Recordó que "hay una enorme cantidad de C/C++ que se mantendrá y evolucionará durante décadas (o más). Anoche codifiqué una función para Handle, que se suma a las aproximadamente 85.000 líneas de código C/C++ de Sysinternals que he escrito". Pero tambiñen añadió que "me inclinaré por Rust para las nuevas herramientas".
Como recuerda #34, Sysinternals era un pozo de sabiduría y herramientas para sistemas Microsoft.
#34 Vaya tortazo que se pegó Sony. Meten un virus y van a infectar el PC del bueno de Mark. Hace falta tener mala suerte. Los dejó a caldo. Intervino el congreso de USA, pero nadie fué a la cárcel.
#1 Visual Rust
#1 Ahi ahi... a hacer sangre.
#12 Te parecerá una postura de privilegiado, pero sí, es un problema moral de los gordos. Una tras otra, casi todas las empresas metidas en el ajo acaban cerrando, o metidas en follones legales por multitud de causas: lavado de dinero, evasión de impuestos, insider trading, robo, estafa, vulneración de protección de datos, etc.
Y eso sin contar con que han desestabilizado por completo el mercado de producción de chips, procesadores y tarjetas gráficas; o que han aumentado los niveles de contaminación de forma alarmante.
Yo mismo estuve en una hace años, cuando era algo más inocente, y a la que el negocio empezó a ir mal, el jefe ya estaba maquinando... ninguna de sus ideas era legal ni ética, pero no le importaba lo más mínimo (dimitimos todos en bloque al ver el percal).
#17 chico, que solo es un puesto de programador. Tecleas, cobras y te tomas unas copas. Dudo que el minero que se dedica a sacar uranio piense que se usan para hacer bombas. Tiene otros usos
Mucha c-nilidad (léase con acento americano) veo aquí. Mucho me temo que este es el futuro: a partir de ahora, el software de sistema tenderá a escribirse cada vez más en lenguajes con seguridad de memoria.
Venir en pleno 2022 con que el problema son los malos programadores es no tener ni puta idea de cómo andan las cosas en el mundo en materia de seguridad. Antes estaba la excusa de que no había elección que arriesgarse si querías usar un lenguaje sin recolector de memoria. Pero tras la aparición de Rust eso cambia, y la tendencia va a ser arrolladora: o el lenguaje garantiza la seguridad de memoria, o se irá quedando al margen de los desarrollos más modernos.
#16 No entiendo nada pero te voto positivo porque me da la sensación de que tienes razón.
#16 Y luego la competencia te saca un producto en C++ que va 3 veces mas rápido requiriendo 10 veces menos de RAM.
#92 Nop:
https://aws.amazon.com/es/blogs/opensource/sustainability-with-rust/
#92 ¿Tienes idea de lo que estás comparando? Es la primera vez que oigo a alguien sugerir que C++ es tres veces más rápido y consume 10 veces menos RAM que Rust. Rust no es un lenguaje interpretado, ni tiene tipado dinámico, ni recolector de memoria. Es perfectamente competitivo con C++ y a la vez proporciona seguridad de memoria (y de multihilo)...
#16 estoy de acuerdo, pero veo 2 handicaps aquí.
La base de código en C que tenemos a día de hoy no va a desaparecer de la noche a la mañana y reescribir cosas como el kernel de Linux o ffmpeg no es trivial en absoluto.
Y segundo y más importante, la curva de aprendizaje de Rust es realmente dura para recién iniciados y bastante dura para programadores con experiencia. Eso provoca que, si vas a iniciar un nuevo proyecto, elijas C, que es extremadamente simple en comparación.
Todavía nos quedan al menos 20 o 30 años más de ver C por todas partes.
#94 En mi opinión como programador de C, Rust es más fácil de aprender.
C no es simple. Sólo se lo parece a quienes no conocen de verdad el lenguaje.
#94 20 o 30? si todavía se pegan por programadores de COBOL porque nadie estudia ese lenguaje obsoleto que tiene tantísimas líneas de código en producción!
#16 Pero si precisamente C++ tiene smart pointers para evitar memory leaks.
#16 yo me repito si RUST es una mejora, coño hagasé, hay que evolucionar, además ya esta aquí para quedarse.
Pero C o C++ aún vigentes, han sido herramientas utiles, echarlos por tierra por que supuestamente se hacen mierdas en ellos... si se hace una mierda en C, C++ o RUST, no es culpa del lenguaje, no jodamos.
"el 70% de todos los errores de seguridad graves en la base de código de Chrome eran errores de gestión de memoria y seguridad".
¿Quien co*o ha redactado esto? Es como poner
"La mayoría de los inmigrantes de EE.UU. son centroamericanos e inmigrantes."
#3 Genbeta forma parte de una agrupación de blogs.
Probablemente estén obligados a escribir un numero de artículos diarios.
La calidad de los artículos no es una prioridad, solo la cantidad.
Es una peste que afecta a cada vez más blogs y webs de noticias.
#3 errores en la gestión de seguridad! =errores de seguridad
#3 Es una traducción automática aparentemente sin revisar, han traducido "weighed in", un phrasal verb que significa dar tu opinión o versión, como "el equipo de Chrome de Google pesó". Es lamentable.
C prevalecerá. Como siempre.
¿Y no sería mejor corregir los fallos de C o habilitarlo para poder programar de forma segura, en vez de inventar lenguajes nuevos?
#47 Pues si, esto parece ya la Torre de Babel.
#73: Es que es siempre lo mismo:
"Eh, mirad, he inventado aún otro lenguaje nuevo que soluciona los problemas que yo notaba en otros, pero que deja otros problemas pendientes de arreglar para que otros puedan inventar un lenguaje más"
Al final se atomiza todo y es peor. Si el problema de C es que puedes salirte del vector, implementa una función de comprobación y úsala SIEMPRE, incluso podría haber una biblioteca estándar para eso. Si el problema es la conversión de tipos, que implementen una función en el compilador que obligue a usarla siempre y si no coinciden, que de error, aunque la conversión sea
tribaltrivial.#75 Realmente no alcanzáis a comprender el salto cualitativo que ha dado Rust, no son cambios pequeños lo que proponen. Se trata de un salto radical en la programación de sistemas.
El rollo de no adoptar Rust para "no fragmentar" da para reír un rato. Sabes cuantos dialectos hay de C? o de C++? Y bibliotecas libc?
Por otro lado, viendo las "soluciones" que propones, tengo claro que no entiendes qué problemas resuelve Rust, y que no has trabajado en este espacio para entender los dolores de cabeza que nos evita.
Pero es que es lo de siempre, llevamos años viendo a peña defender C y C++ a capa y espada con argumentos rocambolescos, solo porque parece ser el lenguaje de los machotes, de los que "saben programar". También vimos lo mismo con ensamblador, o con Perl. También hubo defensores del GOTO cuando Dijkstra explicó por qué era problemático.
#75 Que tiene de malo un lenguaje nuevo? Tampoco es como aprender un idioma. Cuesta dos días acostumbrarte a su sintaxis. Cuesta lo mismo aprender un lenguaje nuevo que a usar una nueva librería.
#47 Posiblemente habría que cambiarlo tanto que sería como hacer un lenguaje nuevo.
#80: Depende de lo que se quiera hacer, si son tantos cambios como para hacerlo un lenguaje tan lento como Python... quizás sea mejor usar ese lenguaje o alguno similar para ciertas funciones y dejar C para otras.
#82 La conveniencia de seguir usando C no tiene nada que ver con el rendimiento a día de hoy, el problema es que hay muchos desarrolladores expertos en él que aún no han aprendido otros lenguajes como Rust, y que hay que mantener la compatibilidad con desarrollos que ya existen y han costado cientos de millones. No se puede reemplazar tanto código de la noche a la mañana, ni la gente puede estar aprendiendo nuevas tecnologías cada dos por tres, más aún si ya están al final de sus carreras profesionales y se lo quieren tomar con calma.
#47 "habilitarlo para poder programar de forma segura" Eso limitaría su potencia, que es la gracia de esos lenguajes. Lo que hay que hacer es contratar gente que sepa lo que hace.
El año de Rust en el escritorio. Oh, wait!
#79: Si es de metal, derramas el café y no lo limpias...
Visual basic 4. Chupito!!! (Y comentario 100 POLEEEEE)
Para nuevos proyectos se puede usar C++11 en adelante, que ya tiene punteros inteligentes y no hay que andar alocando y liberando memoria cada 2x3.
El palillero de Mocosoft no se entera de nada, como si los errores de "seguridad" fueran un problema del lenguaje; será del pardillo que lo ha hecho, que no tendrá ni idea de nada.
#36 el palillero dice...
Ese muchacho te da mil vueltas en todo. Mira su currículum.
Por otro lado, lo de los punteros inteligentes está muy buen, pero yo quiero un lenguaje donde se lean procesos de negocio al mirar el código, no que tipo de puntero se usa en cada línea.
#50 Y para eso teneis visual basic.
#c-90" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3726785/order/90">#90 visual basic, java, JavaScript, python, c#, php, rust y otros 50 más.
#36 ¿no te parece útil que sea el compilador el que te garantice que el código está libre de bugs de las clases más peligrosas?
#36 Alocando dice el palillero.
#36 Vuelta con lo mismo. Programadores 100 veces mejores que todos los que hay aquí han cometido esos errores porque el lenguaje lo permite. Mira un poco hacia adelante, ya es hora.
Y así, para evitar errores, en vez de contratar programadores listos, mejor usar un lenguaje para programadores junior. Sale mas económico y el resultado ya tal...
#87 ¿Insinúas que es lo que hicieron cuando contrataron programadores en C para no tener que hacerlo en ensamblador?
#95 Si... ya oí ese argumento muchas veces de usuarios de Visual Basic.
#87 contratar programadores listos dice el andoba. Date una vuelta por el bugzilla de cualquier proyecto tocho.
Con el C++ empece yo a programar en serio, decían que algunos bucles podían llegar a quemar el procesador... Leyenda urbana, de ser cierto yo hubiera quemado varias maquinas
Lo he estado viendo y está muy interesante...
¿cual es el mejor libro para aprender rust?
#51 rust book, que es gratis.
La documentación de rust es excelente.
Cuanto dice que paga por programar con Rust?
#8 Mucho, a mi me llegan ofertas cada semana por encima de 150.000$/año. El problema: el 80% de ellas están relacionadas con Blockchain.
#9 que problema moral... Con mucho que no me echarán en dos meses serían unos 24k menos impuestos
Aprovecho el hilo. ¿Hay algun libro bien actualizado sobre Rust?
#29 este tutorial de youtube es buenísimo
#32 #33
https://doc.rust-lang.org/book/
Los autores publican el libro en tapa blanda.
#29 +1, interesa. No sé hasta qué punto rust está evolucionando muy rápido ahora mismo como para que un libro se quede desfasado rápido, pero es que prefiero el papel, la verdad.
#33 Rust tiene cambios constantes.