141–150 of 260 posts
Earlier quoted context omitted.
So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?
SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/
I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…
> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…
Earlier quoted context omitted.
As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…
Second the Ada note. That language is so well constructed and thought out on many levels. ...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.) It's a shame because - Ada generic packages are exactly what C++ templates should have been - Derived types and record extension is inheritance that m…
Earlier quoted context omitted.
> I would normally define 'correctness' to include rigorous mathematical proofs. Do you have an example of a language that does what you're looking for? On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. > Go works wonderfully Go does work wonderfully, you should definitely use what you like. For me personally, though,…
> On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. Unit testing can only proof one instance of the input domain, e.g. the function square() returns 4 under the input 2. Languages like Coq allow you to proof that the function square returns the squared input for every possible input.
I see way more future in one's ability to write proofs of correctness in the comments before the function definition in any language; rather than preferring any specific language for the sake of proof.
I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…
> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…
I don't know about "might be worth it" part, and I don't think Go is success is because of it's concurrency model. Instead, I think Go wins because it can get thing done quickly, in one stop.
The concurrency model has been designed to help achieve that, and the huge battery pack came with the language is also for help achieve that.
I'm not discouraging you from design your language, though. In fact, I could be very happy to see a new language which can give me all the benefits that Go gives me and at same time just ... simply be a better language.
My ideal language (in my opinion) is a combination of Go and Rust: Big standard battery (Help me get things done and encourage to it's ecosystem)(&BTW, it don't have to be in the standard library), and fearless programming (Help me avoid mistakes).
Sadly Rust don't want to have a big battery for some reason :(
Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…
- We are directing material resources (as in, hours of paid work) to improving compiler performance. We consider this a serious problem, and "the compiler performance is always improving" is not an accurate gloss of the amount of work people are putting into solving it. - We would love to have a REPL but there are nontrivial technical challenges, and it has not been a major requested feature by our users. - I have ne…
I'm not currently using rust, and lack of a repl is a big strike against it. Not as much of a strike as the lack of a good stable async story, but still.
Earlier quoted context omitted.
Why does GC make it harder to call libraries in other languages?
When you're working in a GCed language you assume your language's GC is responsible for freeing memory. When you interoperate with a language where owners are responsible for freeing memory, you have to have a way to "disown" structures you've created but passed into the ownership language (e.g. a callback you've passed to a library function) so that your GC doesn't free them, and a way to "own" structures you've rec…
Using GC languages doesn't mean doing 100% memory allocation via GC.
Earlier quoted context omitted.
> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…
> I'm a little bit tempted to make a simple compile-to-go language. I'd get lynched at Go meetups for fragmenting the ecosystem, but it might be worth it. I don't know about "might be worth it" part, and I don't think Go is success is because of it's concurrency model. Instead, I think Go wins because it can get thing done quickly, in one stop. The concurrency model has been designed to help achieve that, and the hug…
Rust is against pulling it in the standard library because that forces them to make additional stability guarantees. When you do that, you end up like python's `urllib`/`urllib2` situation.
Earlier quoted context omitted.
SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/
SDCC is also full of bugs and the compiled code is not well optimized. For a low level CPU like that, you have to write assembly at some point.
could someone point to the article explaining how Rust compiler reasons about the program, how different kinds of objects and pointers are represented in runtime - in a word, something that would help me grasp what is really going on when I compile and run the program. The tutorials I saw are written in assumption that you don't need to know that. Which makes me feel like a total idiot