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.
Si lo dice Microsoft, habrá que olvidar el Rust y volver al C
#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.
#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).
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.
#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/
#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...
#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.
"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."
#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...
#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.
#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.
#29 este tutorial de youtube es buenísimo
#21 Tengo la sana costumbre de desconfiar de Microsoft, llámame loco
#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. . .
#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.
#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/
#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.
#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.
#4 tienes un ejemplo de este milenio?
#16 Y luego la competencia te saca un producto en C++ que va 3 veces mas rápido requiriendo 10 veces menos de RAM.
#1 Ostia, venia a decir lo mismo
#16 No entiendo nada pero te voto positivo porque me da la sensación de que tienes razón.
#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.
C prevalecerá. Como siempre.
#11 hoy en día se puede desarrollar en .NET en Linux o Mac sin problemas. Te lo digo yo que lo hago.
#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.
#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.
¿Y no sería mejor corregir los fallos de C o habilitarlo para poder programar de forma segura, en vez de inventar lenguajes nuevos?
#4 Sin mencionar las maravillas del .NET...
#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).
#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.
#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.
#1 Visual Rust
#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.
#25 Enhorabuena. Y gracias.
#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.
#36 Alocando dice el palillero.
#14 Pues si. La han cagado tantas veces que tienen un montón de experiencia.
#58 En cloud y en un montón de cosas. Desde que se fue Ballmer la empresa va como un tiro.
#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.
#1 Microsoft es probablemente la empresa con más experiencia en software de sistema, así que sabe de lo que habla.
#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.
#1 Estos de Microsoft culpando al lenguaje de sus chapuzas. No se podía esperar más de ellos.
#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.
#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).
El año de Rust en el escritorio. Oh, wait!
#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.
#152 Era mayormente curiosidad, sospechaba que sería en algún proyecto de software libre conocido. Yo estoy trabajando desde hace unos cinco años en EEUU, de Senior Engineer en Amazon. Trabajo en el equipo de OpenJDK.
No comento salarios porque EEUU es básicamente un mundo completamente distinto, no tiene sentido comparar. Pero es una buena opción para ahorrar un tiempo y luego volver.
Estoy totalmente de acuerdo contigo en el tema de la palabra Senior. Básicamente a nada de empezar a trabajar en una empresa pequeña, me pusieron el titulo de Senior. Luego, me costo bastantes años estando en Microsoft/Amazon volver a poner el Senior en el titulo. Cuando pienso en el conocimiento que tenía cuando me dieron el titulo de senior por primera vez, me rio a carcajadas.
Sobre el ingles, estoy totalmente de acuerdo. Hace un poco de falta de desparpajo y querer hacerte entender. Y si, al principio igual no suenas bien, pero sin la practica no
#10 ¡ Y los cuchillos cortan !
#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...
#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.
Visual basic 4. Chupito!!! (Y comentario 100 POLEEEEE)
#66 ¿esos son ejemplos de qué, cosas que no funcionaron? Todas las empresas tienen montones. No sé a donde quieres llegar.
#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.
#7 si competidor significa copia con mil añadidos que lo hacen peor
#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.#150 Soy ingeniero de software senior (en la rama de "individual contributor" (en contraposición a management) tengo dos rangos por encima, "staff engineer", y "principal engineer"), en una multinacional irlandesa que dedica una parte importante de su trabajo a mejorar proyectos de código libre (como NodeJS). Cuando digo "senior" lo digo en su sentido estricto, en España solemos colgar ese título a los 6 meses de empezar, o a mediors, solo por antigüedad.
Cobro 80k brutos (tengo conocidos ganando bastante más que yo por el "mismo" trabajo, aunque no en esta empresa), además de 1k anuales en formación, 2k cada dos años en renovación de mi equipo de trabajo, y 5 días que puedo optar por estudiar en vez de trabajar.
El hecho que marca el primer salto notable en nivel salarial es el hablar inglés "fluidamente" (eso no significa tener un acento exquisito, sino entender absolutamente todo lo que te dicen, y saberte hacer entender sin depender del lenguaje corporal, por eso entrecomillo), para poder mantener bien lejos a los empresaurios españoles que te quieren exprimir. Par ser manager sí que hay que hablarlo fluidamente, sin entrecomillado.
Algo que suele ayudar es huir del país, al menos por una temporada, si no caes en lo de relacionarte solo dentro de guetos de españoles, el nivel de inglés mejora muy rápidamente, y también da mucha capacidad de negociación que el potencial empleador sepa que te has movido por el mundo (por lo que sabes qué es lo que se paga ahí fuera por tu trabajo).
#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.
#18 Las decisiones en una empresa de estas las toman habitualmente los directivos, como el aquí mentado. Nadie ha responsabilizado a los desarrolladores.
#47 Pues si, esto parece ya la Torre de Babel.
#131: Es que no es solo un lenguaje nuevo... son cientos.
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 ¿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?
#51 rust book, que es gratis.
La documentación de rust es excelente.
#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".
#87 ¿Insinúas que es lo que hicieron cuando contrataron programadores en C para no tener que hacerlo en ensamblador?
#87 contratar programadores listos dice el andoba. Date una vuelta por el bugzilla de cualquier proyecto tocho.
#32 #33
https://doc.rust-lang.org/book/
Los autores publican el libro en tapa blanda.
Estando en Google hace casi 15 años tuve la suerte de tener de compañero de cubículo durante un tiempo a uno de los que está o estaba en el comité de estandarización de C++. Creo que tenían C++11 entre manos por aquel entonces. Aprendí muchísimo de él. Se puede programar bien en C++ con un poco de cuidado.
Una de las cosas que descubrí con él y que para mí son el principal problema del lenguaje, muy por encima de tener que gestionar la memoria, es la ingente cantidad de "undefined behaviour" que tiene el estándar. Eso genera una clase de errores extremadamente difíciles de encontrar y que además pueden aparecer o no dependiendo del compilador o de la versión del mismo.
#43 Nadie se acuerda de Fortran?
#43 Perdona si desconfío de tus conocimientos en programación de sistemas a bajo nivel, o de seguridad en sistemas críticos.
#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.
#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)...
#111 Pues vale. Lo que tu digas. Rust no necesita colector de basura, y tampoco delega la gestión de memoria en el programador.
Y con lo de los tipos, estoy harto de ver bugs que un sistema de tipos decente sería capaz de prevenir, en bastantes lenguajes: C, Python, JS, PHP en sus años de pubertad... Por supuesto que los sistemas débiles de tipo son un problema monumental.
No se ha querido reconocer durante años, pero al final lenguajes como Python han tenido que dar su brazo a torcer (introduciendo sus anotaciones light), JS trajo consigo la aparición de TypeScript (y tienen un RFC en marcha para incorporar algunas anotaciones de tipos directamente en JS), PHP mejoró muchísimo su sistema de tipos (dentro de lo posible, para no reventar por los aires la compatibilidad hacia atrás...).
Que Python, JS, PHP (y otros) hayan migrado poco a poco a sistemas más fuertemente tipados no es ninguna casualidad, ni cuestión de opinión. Se ha hecho porque permiten el mantenimiento de cantidades enormes de código a menor coste, y con menores tasas de errores.
#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.
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...
#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.
#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.
#146 Russinovich es un crack. He tenido la oportunidad de asistir a sus charlas un par de veces y es toda una experiencia
#43 muy bien explicado.
#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
#118 Y luego está C++, que no lo conoce de verdad nadie.
#3 errores en la gestión de seguridad! =errores de seguridad
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
#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.
#132 La riqueza de las distintas modalidades lingüísticas de España es un patrimonio cultural que será objeto de especial respeto y protección.
Si lo hacemos con las lenguas humanas, ¿por qué no podemos hacerlo también con los lenguajes de programación?
#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).
#16 Pero si precisamente C++ tiene smart pointers para evitar memory leaks.
#124 Eso no hace que se resuelvan todos los problemas
#127 Los memory leaks, que es de lo que va tu comentario, sí.
#129 Rust garantiza la seguridad en la gestión de memoria, eso va mucho más allá de las pérdidas (de hecho, Rust permite las pérdidas de memoria, porque técnicamente no es inseguro)
#137 Rust puede garantizar la seguridad del manejo de memoria, puedes tener un programador absolutamente mediocre y aún así el lenguaje te garantiza seguridad. Puedes utilizar cualquier código de terceros y tener seguridad. Eso no te lo garantiza C ni C++, por mucha historia que tengan
#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...
#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.
#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.
#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.
#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.
#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.
#79: Si es de metal, derramas el café y no lo limpias...