Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Ada: a C Developer's Perspective

#131

Post by bitwize »

eutectic wrote: post #104
bitwize wrote: post #94

Puppy 1: And so, in conclusion, we have determined that Ada provides sufficient safety guarantees and features for our embedded system needs. Any questions? Puppy 2: Yes, I have a question. Why didn't you use Rust? Puppy 1: That's a good question. While Rust looks promising, we felt it was too immature for our needs and decided to go with the time-tested, standardized semantics and extensive tooling available with Ad…

Don't you find it's so much easier to argue against yourself? None of those pesky unpredictable arguments to worry about.

You do realize that that wasn't intended to be a serious argument about the points of Ada vs. Rust... right? Have you seen "MongoDB is web scale" (https://youtu.be/b2F-DItXtZs)?

Re: Ada: a C Developer's Perspective

#132

Post by e12e »

reacweb wrote: post #18
reacweb wrote: post #17

"Code should be easy to write, easy to read, easy to maintain, and most importantly, it should be reliable". Ada is not easy to write. Perl is easy to write (but not easy to read or maintain). When I was student, Ada was the main language at my school. It was used the first year to teach algorithms and the second year to teach parallelism. During the first year, I have also learned C by myself for curiosity. After th…

As a disclaimer, I love Ada (and Perl) and I regularly despise C++.

How would you rate your young self on the "hello-my-name-is-scale", as I like of to think of Stroustrup's notes in his short article from 1999[1] -- in C and Ada at the time? Would your C code "blow up" differently from your Ada code, do you think?

I'm not much of a fan of C++ myself, but I often find myself looking back at that short note, as a pretty valid criticism of how C tend to mix some parts that appear simple with some very complex actual behavior (eg: printing strings, reading in strings and integers).

[1] http://www.stroustrup.com/new_learning.pdf "Learning Standard C++ as a New Language"

Re: Ada: a C Developer's Perspective

#133

Post by e12e »

Raphael_Amiard wrote: post #64
evacchi wrote: post #5

It's such a pity these days there is no modern tool chain/workflow for Ada (or C++ for that matter). I mean, a package manager, a build tool with integrated dependencies. As far as I know, there is very little open source software for Ada. It's a shame, because I feel like the language would become more mainstream, if only better tooling was easily available.

There are a few people at AdaCore working on this, we're trying to bootstrap it and involve the community, more about that soon we hope :) The build tool, GPRBuild is already a step above makefiles, and personally I find it very convenient to work with.

I'm sure I'm not the only one that would appreciate an up-to-date, real-world best-practices "How I start"[1]-article for Ada - from people that actually write non-trivial Ada code and have a stake in project setup, packaging etc.

[1] http://howistart.org/

Re: Ada: a C Developer's Perspective

#134

Post by hdhzy »

Manishearth wrote: post #87
fghvbnvbnfe wrote: post #33

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

I don't really understand the "Rust is obsessed with memory safety" meme. When pitching Rust to others of course memory safety and thread safety get hyped a lot; because it's talking about something that most languages just can't do -- safety without compromise. But actually ... memory safety is a small part of the reasons why I like Rust, and there are plenty of other cool bits in the language. It stands out a bit b…

>... and there are plenty of other cool bits in the language.

Could you elaborate what you think is cool there ("other cool bits")? Serious question, I'd like to hear a personal opinion.

Re: Ada: a C Developer's Perspective

#135

Post by snovv_crash »

pathsjs wrote: post #19
pavlov wrote: post #10

Earlier quoted context omitted.

For C++, I'm reasonably happy with CMake and the Jetbrains CLion IDE. CMake makes it relatively painless to wrap multi-platform dependencies without having to explicitly know whether they come from a Unix package manager or from Windows DLLs.

The problem is that it does not manage and version dependencies for you. Say I start a new C++ project where I want - say - use ZeroMQ and also Folly to parse JSON. Where do I start? Should I install ZeroMQ and its headers globally? What if the version changes? Will it conflict with other system libraries? Well, better start using Docker. What if the version I need is not in the Ubuntu repositories yet? I need to add…

You can do this with http://Conan.io and CMake. It is quite young still, but at this point is fairly feature complete and doesn't have any breaking changes anymore.

Re: Ada: a C Developer's Perspective

#136

Post by sctb »

breeze_em_out wrote: post #11
yoz-y wrote: post #3

I am going to be that guy and say: Poorly compressed JPEG images for text examples?

Every time I see that shit I think, "Man, I'm glad we learned how stupid that is." but then immediately after I realize that people are still doing it all the time, because I think that same thought all the time. People are so STUPID! "Oh my god breeze, you are so rude, just because people programming critical infrastructure systems literally can't copy and paste things doesn't mean they're stupid!" -- Stupid people'…

Would you please stop posting like this and (re-)read the guidelines?

https://news.ycombinator.com/newsguidelines.html

Re: Ada: a C Developer's Perspective

#137

Post by tom_mellior »

tmccrmck wrote: post #124
atilaneves wrote: post #91

Earlier quoted context omitted.

Safety without compromise doesn't exist. Rust does what it does well, but at significant cost in developer time. I'd rather use a garbage collector, it's much much simpler and fine for 99.9% of use cases.

Garbage collection does make things easier, prettier, and simpler. BUT there are many problem domains in which a GC can not be used. A browser being a prime example...

Maybe you can find a better "prime example" than browsers, which nowadays are mostly known as execution engines for JavaScript, a garbage-collected language.

But frankly, I doubt that you can. Others will say "operating system kernels", but people are happily writing OS kernels in OCaml, so .

Yet others will say "safety-critical hard real-time tiny microcontrollers without an MMU" (one of Ada's domains), but on those systems you don't want to do dynamic allocation anyway, so the question of GC or not is kind of moot.

I've said it before, I'll say it again: Rust would be a better language if it had a GC and the possibility of marking certain program parts as GC-free (the way it allows you to mark certain parts as unsafe).

Re: Ada: a C Developer's Perspective

#138

Post by theossuary »

tom_mellior wrote: post #137
tmccrmck wrote: post #124

Earlier quoted context omitted.

Garbage collection does make things easier, prettier, and simpler. BUT there are many problem domains in which a GC can not be used. A browser being a prime example...

Maybe you can find a better "prime example" than browsers, which nowadays are mostly known as execution engines for JavaScript, a garbage-collected language . But frankly, I doubt that you can. Others will say "operating system kernels", but people are happily writing OS kernels in OCaml, so . Yet others will say "safety-critical hard real-time tiny microcontrollers without an MMU" (one of Ada's domains), but on thos…

That's kind of his point, you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in. So in this way writing a Javascript executor in a GC language wouldn't really make sense, you're just adding needless layers of abstraction (at a serious performance cost). So I think a browser is an excellent example of an application which can't really be written in a GC language. Other examples might be Databases and realtime applications.

Re: Ada: a C Developer's Perspective

#139

Post by breeze_em_out »

sctb wrote: post #136
breeze_em_out wrote: post #11

Earlier quoted context omitted.

Every time I see that shit I think, "Man, I'm glad we learned how stupid that is." but then immediately after I realize that people are still doing it all the time, because I think that same thought all the time. People are so STUPID! "Oh my god breeze, you are so rude, just because people programming critical infrastructure systems literally can't copy and paste things doesn't mean they're stupid!" -- Stupid people'…

Would you please stop posting like this and (re-)read the guidelines? https://news.ycombinator.com/newsguidelines.html

I prefer to be censored by dang, is he available? edit: I've also not broken any guidelines, you're just upset that I'm right. I understand.

Re: Ada: a C Developer's Perspective

#140

Post by tom_mellior »

theossuary wrote: post #138
tom_mellior wrote: post #137

Earlier quoted context omitted.

Maybe you can find a better "prime example" than browsers, which nowadays are mostly known as execution engines for JavaScript, a garbage-collected language . But frankly, I doubt that you can. Others will say "operating system kernels", but people are happily writing OS kernels in OCaml, so . Yet others will say "safety-critical hard real-time tiny microcontrollers without an MMU" (one of Ada's domains), but on thos…

That's kind of his point, you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in. So in this way writing a Javascript executor in a GC language wouldn't really make sense, you're just adding needless layers of abstraction (at a serious performance cost). So I think a browser is an excellent example of an application which can't really…

> you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in

Here's PyPy's GC, implemented in Python: https://github.com/tycho/pypy/tree/master/rpython/memory/gc

(I haven't looked at it in detail.)

Anyway, even if you absolutely had to use a non-GC language to implement a GC, that would not preclude writing 99% of the browser in a GC language and only the GC in something else.

Post reply on HN