4 ms·

> At least the above part of your comment makes it sound like you don't understand what languages like Rust and Haskell bring to the table. > Was that your int

> At least the above part of your comment makes it sound like you don't understand what languages like Rust and Haskell bring to the table. > Was that your intention? The arrogance in your post is over the top. > "leave me alone, I want to introduce more buffer overflows and integer overflows in peace". Truth is, C programmers are not as infallible as many of them believe One of the two possibly, but certainly not both. Or, "leave me alone, I just want to get my program done, and have it do the right thing, with appropriate performance, quick to build, good modularity, few dependencies, and not having to rewrite it next year. Security is important but does not override all of these other things." Many find these practical properties and the fun of forming something with their bare hands that works more desirable than burning out while waiting for a build to complete or doing the required maintenance when upgrading dependencies. It seems that you don't?

geofft 5y ago
At the top of this thread, I set out a number of reasons why a) you are not "fighting a language" by using Rust or Go or Haskell or whatever - in fact you are more able to focus on the problem you want to solve b) there are many reasons to use such a language, not just security, and all the things you mention - correctness, performance, development velocity, modularity, good design, and robustness to new requirements - are aided by features in newer languages 'pdimitar is making a reasonable argument and your dismissal of it as arrogance is uncalled for. I would encourage you to reread both of those comments carefully.
- jstimpfle 5y ago
  > 'pdimitar is making a reasonable argument and your dismissal of it as arrogance is uncalled for. I would encourage you to reread both of those comments carefully. ... No? It was clearly bordering into personal attack territory, suggesting lack of experience or intelligence as a reason for supposedly not seeing something obvious. > there are many reasons to use such a language, not just security, and all the things you mention - correctness, performance, development velocity, modularity, good design, and robustness to new requirements - are aided by features in newer languages Just... no? For example, more features => less orthogonal features => less interopability, worse modularity. You can see this easily for example when C++ programmers construct 5 versions of trivial APIs (like function/method signatures). As you wrap everything in more and more complicated types - types that do more than just hold data, like allocating memory, constructing, moving ownership, thread synchronization, being optional, offering various implementations for various traits, and so on... stuff is simply less interoperable. Also, many programming languages, like C++, Swift, Rust, Haskell... are not exactly known for their build speeds. Haskell for example in my case, I've tried really hard to like it for quite some time, but never felt productive in it except for end-in-itself kind of mind games trying to (unsuccessfully) boost my ego. One of the last things I remember trying with it is building a plain OpenGL Program (like, Tetris level) and I can remember the build for this single file program taking 10 (or was it 40?) seconds, on each and every incremental change in a program that was a couple hundred lines. Rust I've never touched, except one stint where I unsuccessfully tried to build a high-profile project, finding in the end that it was mostly snakeoil (after literally compiling 500 dependent packages). Just some real world examples...
pdimitar 5y ago
> "leave me alone, I just want to get my program done, and have it do the right thing, with appropriate performance, quick to build, good modularity, few dependencies, and not having to rewrite it next year. Security is important but does not override all of these other things." Virtually all of these are debatable, not necessarily factual and definitely not at all monopolized by C -- that's the overarching discussion in this entire HN comment section. ...So writing stuff in Rust means the program has to be rewritten in the next year? Factually not true. What does twisting and misrepresenting things win you here? That's not arguing in good faith. Also, "doing the right thing" is rich coming from practitioners of a language with a ton of undefined behaviour and zero memory ownership checks. I'm sure you have the best of intentions but there's only so much you can do when the language and the compiler itself are willing to pull part of the rug from beneath your feet. That's why I abandoned C a long time ago. History is not on your side either, with all the yet-another-buffer-overflow submissions here on HN for the last 2-3 years. Even today we had another part of OpenSSL crapping the bed through a buffer overflow, yet again. So can Rust programmers make mistakes beyond the memory ownership? Of course! Nobody says the language is immune to bugs in general. What a lot of people say -- and it gets grossly misrepresented at every chance that biased people get! -- is that Rust is immune to a class of bugs. Nothing else. (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in computers, we all step on decades old legacy and nothing is truly built by us alone.)
- jstimpfle 5y ago
  > (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in computers, we all step on decades old legacy and nothing is truly built by us alone.) I mean something like this for example [0], which I just built for experimentation. It's a little GUI basically without dependencies (apart from the actual GUI code it's only some Win32 junk to paint colored rectangles and some text... this stuff is easy to replace with SDL or whatever backend works). The GUI has moveable / resizable windows, buttons, sliders, a simple layout method... The logic is super easy to extend, not the typical message handling mess that is seen in traditional GUI toolkits. Each widget is basically a 0-1 structs and 0-2 functions. This approach does have value. Not only does it make me happy - it gives me performance, flexibility, portability, modularity, build speed, control - each and every pixel coded on my own ... so much good stuff. As for the rest, consider belittlery as a hobby. [0] https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934fc2f34 https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934...

geofft 5y ago

At the top of this thread, I set out a number of reasons why a) you are not "fighting a language" by using Rust or Go or Haskell or whatever - in fact you are more able to focus on the problem you want to solve b) there are many reasons to use such a language, not just security, and all the things you mention - correctness, performance, development velocity, modularity, good design, and robustness to new requirements - are aided by features in newer languages 'pdimitar is making a reasonable argument and your dismissal of it as arrogance is uncalled for. I would encourage you to reread both of those comments carefully.

jstimpfle 5y ago
> 'pdimitar is making a reasonable argument and your dismissal of it as arrogance is uncalled for. I would encourage you to reread both of those comments carefully. ... No? It was clearly bordering into personal attack territory, suggesting lack of experience or intelligence as a reason for supposedly not seeing something obvious. > there are many reasons to use such a language, not just security, and all the things you mention - correctness, performance, development velocity, modularity, good design, and robustness to new requirements - are aided by features in newer languages Just... no? For example, more features => less orthogonal features => less interopability, worse modularity. You can see this easily for example when C++ programmers construct 5 versions of trivial APIs (like function/method signatures). As you wrap everything in more and more complicated types - types that do more than just hold data, like allocating memory, constructing, moving ownership, thread synchronization, being optional, offering various implementations for various traits, and so on... stuff is simply less interoperable. Also, many programming languages, like C++, Swift, Rust, Haskell... are not exactly known for their build speeds. Haskell for example in my case, I've tried really hard to like it for quite some time, but never felt productive in it except for end-in-itself kind of mind games trying to (unsuccessfully) boost my ego. One of the last things I remember trying with it is building a plain OpenGL Program (like, Tetris level) and I can remember the build for this single file program taking 10 (or was it 40?) seconds, on each and every incremental change in a program that was a couple hundred lines. Rust I've never touched, except one stint where I unsuccessfully tried to build a high-profile project, finding in the end that it was mostly snakeoil (after literally compiling 500 dependent packages). Just some real world examples...

pdimitar 5y ago

> "leave me alone, I just want to get my program done, and have it do the right thing, with appropriate performance, quick to build, good modularity, few dependencies, and not having to rewrite it next year. Security is important but does not override all of these other things." Virtually all of these are debatable, not necessarily factual and definitely not at all monopolized by C -- that's the overarching discussion in this entire HN comment section. ...So writing stuff in Rust means the program has to be rewritten in the next year? Factually not true. What does twisting and misrepresenting things win you here? That's not arguing in good faith. Also, "doing the right thing" is rich coming from practitioners of a language with a ton of undefined behaviour and zero memory ownership checks. I'm sure you have the best of intentions but there's only so much you can do when the language and the compiler itself are willing to pull part of the rug from beneath your feet. That's why I abandoned C a long time ago. History is not on your side either, with all the yet-another-buffer-overflow submissions here on HN for the last 2-3 years. Even today we had another part of OpenSSL crapping the bed through a buffer overflow, yet again. So can Rust programmers make mistakes beyond the memory ownership? Of course! Nobody says the language is immune to bugs in general. What a lot of people say -- and it gets grossly misrepresented at every chance that biased people get! -- is that Rust is immune to a class of bugs. Nothing else. (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in computers, we all step on decades old legacy and nothing is truly built by us alone.)

jstimpfle 5y ago
> (As for "forming something with your own hands", I think you should pick up pottery or carpentry as a hobby. There's nothing about "your own hands" in computers, we all step on decades old legacy and nothing is truly built by us alone.) I mean something like this for example [0], which I just built for experimentation. It's a little GUI basically without dependencies (apart from the actual GUI code it's only some Win32 junk to paint colored rectangles and some text... this stuff is easy to replace with SDL or whatever backend works). The GUI has moveable / resizable windows, buttons, sliders, a simple layout method... The logic is super easy to extend, not the typical message handling mess that is seen in traditional GUI toolkits. Each widget is basically a 0-1 structs and 0-2 functions. This approach does have value. Not only does it make me happy - it gives me performance, flexibility, portability, modularity, build speed, control - each and every pixel coded on my own ... so much good stuff. As for the rest, consider belittlery as a hobby. [0] https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934fc2f34 https://gist.github.com/jstimpfle/b387332fe97ef7059f602dc934...