231–240 of 294 posts
Earlier quoted context omitted.
>Yeah, everyone wants to be a Rust programmer I understand why you might have got that impression, but that's a far cry from the reality
It really puzzles me why smart people want to spend their time satisfying the borrow checker rather than inventing new and useful things.
Earlier quoted context omitted.
I don't remember the 'satisfying the borrow checker' phase lasting more than a few weeks. Once you internalize the rules the borrow checker gets out of your way and it's more of a sanity check. I think part of the issue is that it wasn't very well explained in the book at the time I started learning rust. This might have improved since.
The entire way of coding in Rust revolves around satisfying the borrow checker. At some point it may become second nature, but you are still jumping through Rust's hoops, which will make your code full of compromises that would otherwise not exist.
Startups are about cost, time to market, and a high level of efficiency to deliver on a promises ( product ) to sell or get to market. A language selection should consider two things, talent pool and maturity of the tools. When you go hire developers, I want a strong pool to be able to be selective in finding attitude with the right aptitude, and I want them to be productive ASAP, so that means that we might bring in…
Exactly, I did startup before, and my take is: Rust is absolutely the worst choice for startups. to survive startup, you need a large pool of talents, mature and verified and boring stack, easy to find tutorials, etc. The least thing you want is to spend cycles on fancy new bleeding unstable languages to build your earth shaking product.
Where does a language magically go from "new bleeding unstable" to something you think is suitable to use at a startup ? Rust 1.0 was in 2015, seven years ago.
Do you think a startup should also avoid the "fancy new" ES6 with "let" and arrow functions ?
Earlier quoted context omitted.
In cases when I have a working visual debugger, I agree, it's fun. Without one, it's not fun.
when do you not have one ? as soon as you have a mere hint of gdb / gdbserver possible you can debug in a GUI such as Qt Creator's
Sometimes you can end up in a pickle because the embedded system you’re working with just doesn’t have a good debugger available, or it may be cumbersome to set up.
Sometimes the segfault happens in a production environment and you just can’t hook up a visual debugger to the ten different instances of the server you’re running.
I agree that a segfault is a fun error to try and diagnose because it really exercises your gray matter. But it’s not my job to diagnose segfaults, it’s my job to keep the service running up to some certain standard, and if I find myself diagnosing lots of segfaults, there is usually something else I could be doing involving instrumentation or testing to address those defects which is more boring but more productive :-)
Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be t…
Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be t…
I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be fun…
Rust is not a great choice for startups! In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language. Rust just may be t…
I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be fun…
Earlier quoted context omitted.
I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be fun…
Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)