Live data from Hacker News

Writing Linux Modules in Ada (2016)

nihamkin.com

41–50 of 87 posts

Re: Writing Linux Modules in Ada (2016)

#41
post #11

Earlier quoted context omitted.

It's unclear exactly what you mean by your remark that Ada's syntax hasn't aged well, let alone what a 21st-century overhaul would look like. Is there any chance you'd expand on that? I'm curious to know your thoughts.

They probably mean that they can’t get past the fact that it looks more like Algol or Pascal than C. Which is, frankly, a pretty silly argument. I’ve heard this exact argument about VHDL versus Verilog, with the former being explicitly based on Ada’s syntax and the latter being explicitly based on C’s. (Turns out though that VHDL is also strictly better than at least traditional Verilog, as it requires separate inter…

I like your use of "Ada: The Next Generation". I replied to your comment in GP. I'm not really too hung up on the Pascal-ish syntax. I don't think these things matter too much. If I had to design the syntax myself, I'd probably go in a different direction. That's just my own opinion though.

Re: Writing Linux Modules in Ada (2016)

#42
post #26

Hah, my perfect niche! I think that an ada-like language could make a real resurgence in embedded programming. Ada gets all the things about bare-metal right that C got wrong. However, it's held up by legacy tooling, clunky syntax, and obtuse compiler errors. Adacore has gone a long way towards alleviating those issues over the last few years, with alire and the ada_language_server. Time will see where this language…

> Ada gets all the things about bare-metal right that C got wrong I'm curious, never had a look at Ada, can you elaborate?

I personally think that its 'representation clauses' are a really awesome feature for bare-metal programming. It's a shame other languages haven't borrowed this idea.

Re: Writing Linux Modules in Ada (2016)

#43
I’ve always been attracted to the idea of Ada (particularly SPARK) as a “really safe C-like”. I guess my main concern versus C is portability and ease of integrating libraries or exporting a usable C API, and secondarily the quality of the optimizer.

Re: Writing Linux Modules in Ada (2016)

#44
post #26

Earlier quoted context omitted.

> Ada gets all the things about bare-metal right that C got wrong I'm curious, never had a look at Ada, can you elaborate?

I think it mostly refers to the build in functions in Ada for Bit fiddeling. You can represent registers and bitmaps in Ada data structures and use relatively simple to understand functions on them instead. https://learn.adacore.com/courses/intro-to-embedded-sys-prog...

There are a lot of aspects where Ada is better than C. Just a few things that came to mind:

General lack of dumb C stuff like switch fallthrough, null terminated strings (Arrays in Ada are passed with fat pointers), undefined behavior, no need for memcpy, no preprocessor bullshit etc.

Ada is more like C++ in functionality so it has Generics, Tasks (Threads), Exceptions, Packages, Strong types, Design by contract etc (All much much saner than C++ stuff)

Despite all of the features it's very embedded friendly. Language allows you to disable features you dont wont with Restrictions Pragma (Very long list of restrictions you can apply: https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/s...). You can also fairly easily change runtimes: https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ug....

Re: Writing Linux Modules in Ada (2016)

#45

I’ve always been attracted to the idea of Ada (particularly SPARK) as a “really safe C-like”. I guess my main concern versus C is portability and ease of integrating libraries or exporting a usable C API, and secondarily the quality of the optimizer.

>> I guess my main concern versus C is portability and ease of integrating libraries or exporting a usable C API, and secondarily the quality of the optimizer.

Interfacing with C APIs / libraries is really easy and portable across Ada implementations:

https://learn.adacore.com/courses/intro-to-ada/chapters/inte...

http://www.ada-auth.org/standards/22rm/html/RM-B-3.html

The quality of the optimizer depends on the Ada implementation.

GNAT, the free software Ada implementation, uses the GCC backend so it is pretty good:

https://www.getadanow.com/

https://www.adacore.com/gnatpro

Re: Writing Linux Modules in Ada (2016)

#46
I want to like Ada, but the lack of support for Mac OS on anything Apple Silicon related is a huge reason to skip it and do something else (for me).

One thing I still haven't wrapped my head around is how "dynamic" memory allocation and cleanup works in Ada. It doesn't seem as important to mention that early in any documentation anywhere. And, maybe it's the C/C++ programmer in me, but that strikes me as a bit odd. Or, perhaps I just can't see past the tip of my nose and it's there.

I kind of need to know how dynamic memory works in any programming language before I plan to invest deeply in learning it. And it needs to work on my hardware.

Re: Writing Linux Modules in Ada (2016)

#47

I want to like Ada, but the lack of support for Mac OS on anything Apple Silicon related is a huge reason to skip it and do something else (for me). One thing I still haven't wrapped my head around is how "dynamic" memory allocation and cleanup works in Ada. It doesn't seem as important to mention that early in any documentation anywhere. And, maybe it's the C/C++ programmer in me, but that strikes me as a bit odd. O…

There’s a GNAT release for M1 now. The FSF Ada compiler is based on GCC so it has worked for RISC-V and other ARM CPUs for a little while now as well.

Ada’s dynamic memory principles are definitely unique. For heap allocation its based around memory pools, at least in GNAT. For the most part it’s RTTI but you can do manual new/free style too (though discouraged).

Ada uses a secondary stack as well for variable-length function returns, so in practice you don’t need to do heap allocation very much.

There are also equivalents of some STL containers like vector that can handle heap allocations for you safely.

Re: Writing Linux Modules in Ada (2016)

#48
post #17

Earlier quoted context omitted.

Only true for those stuck in Ada83. People keep repeating this nonsense without updating themselves beforehand. EDIT: To simply education on Ada, Yes there was an optional GC, no one ever implemented it, so in Ada2012 got removed from the standard. Almost everything can be allocated on the stack, so a strategy is to catch exceptions of not enough stack space and retry the same function with a smaller size for the dat…

>Ada95 introduced controlled types, which is basically Ada's version of RAII, no need to call Unchecked_Deallocation outside implementation details. Hardly any different from Rust code that uses unsafe underneath. This is basically like C++ destructors, but the problem is there are no move semantics in Ada, so you can't implement something like unique_ptr. It's hardly comparable with Rust.

Yeah, that is what happens when one doesn't understand contracts and formal proofs are used, my dear newly created account to advocate for Rust.

Re: Writing Linux Modules in Ada (2016)

#49
post #42
post #26

Earlier quoted context omitted.

> Ada gets all the things about bare-metal right that C got wrong I'm curious, never had a look at Ada, can you elaborate?

I personally think that its 'representation clauses' are a really awesome feature for bare-metal programming. It's a shame other languages haven't borrowed this idea.

Representation clauses are by far the biggest feature for embedded programming:

https://learn.adacore.com/courses/advanced-ada/parts/data_ty...

http://www.ada-auth.org/standards/22rm/html/RM-13-1.html

Wouldn't it be nice in C to be able to define how a struct is laid out in the machine representation? In Ada, you can and it is part of the standard, so it is portable:

https://learn.adacore.com/courses/advanced-ada/parts/data_ty...

Re: Writing Linux Modules in Ada (2016)

#50

I’ve always been attracted to the idea of Ada (particularly SPARK) as a “really safe C-like”. I guess my main concern versus C is portability and ease of integrating libraries or exporting a usable C API, and secondarily the quality of the optimizer.

>> I guess my main concern versus C is portability and ease of integrating libraries or exporting a usable C API, and secondarily the quality of the optimizer. Interfacing with C APIs / libraries is really easy and portable across Ada implementations: https://learn.adacore.com/courses/intro-to-ada/chapters/inte... http://www.ada-auth.org/standards/22rm/html/RM-B-3.html The quality of the optimizer depends on the Ada…

>GNAT, the free software Ada implementation, uses the GCC backend so it is pretty good:

GNAT also has LLVM Backend: https://github.com/AdaCore/gnat-llvm It's stable and Adacore plans to ship it in GNAT Pro 24, i.e. next release. Note that it's the same front-end, so you get best of both worlds basically.

Post reply on HN