Oberon VS aws-lambda-rust-runtime

> Sure there's a small overhead to smart pointers

Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.

> Garbage collection has an overhead too of course

The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.

Great, thanks!

There are books online for free, e.g.

https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf

and https://ssw.jku.at/Research/Books/Oberon2.pdf

Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity.

Feel free to comment here or e.g. in https://github.com/rochus-keller/Oberon/discussions/45.

> Does anyone know why Wirth never modernized his style?

Readability. It's easier to read the source code with uppercase keywords. (I think Wirth once said that code is written once but read many times). See this source code - https://raw.githubusercontent.com/rochus-keller/OberonSystem... - to get an idea of this (the uppercase keywords allow you to easily scan the blocks of code). Ofcourse, one can claim that the same can be achieved better today with colour-coded keywords.

If I remember right, the Oberon+ IDE - https://github.com/rochus-keller/Oberon - gives you an option to disable this and use lowercase keywords.

> gain a deep understanding of it .. generate smaller subsets of the system

You can use the OberonViewer for this purpose with the original source code, or the Oberon IDE with a version of the Project Oberon System which runs with SDL on all platforms, see https://github.com/rochus-keller/oberon/#binary-versions and https://github.com/rochus-keller/OberonSystem/tree/FFI

> Regardless, which one is more likely to be ported to a different architecture in the future?

Not sure I understand the question. I'm talking about CPU architectures. The current implementation is in x86 assembler. So if you want to run it on AMD64 or ARM, then you have to replace all assembler files, in the present case probable the full source code.

> what are the comparative performance benchmarks of the low-level language versus the high-level language?

I don't have any measurements. But consider that many operating systems are implemented in C (e.g. Linux) with only isolated parts in assembler, so it is easier to port to other architectures. Linux apparently is fast enough and available for nearly every CPU. Oberon in contrast to C is garbage collected, which also affects performance. I have measurements comparing the same benchmark suite implemented in C++ and in Oberon, where the former is about 22% faster (see https://github.com/rochus-keller/Oberon/blob/master/testcase...).

I actually had a similar problem some years ago and finally moved away from LLVM because of complexity, continuous research effort and performance. My current Oberon+ implementation works like this: the CIL code generator together with Mono is used during development, integrated with the IDE, using the debugging features integrated in Mono; to deploy the application and to gain another factor 2 of performance C99 instead of CIL can be generated and compiled with any compatible toolchain. Here are some performance measurements: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf. Compiling to CIL is very fast and the time Mono needs to compile and run is barely noticable.

> annoying aspects was requiring the .NET runtime ... OpenJDK is a blessed implementation in a way that Mono never was

Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.

I've been writing more and more about the benefits of Rust and Lambda quite a bit lately and I plan to take advantage of them in this customizer. Additionally, I've leveraged the Lambda Runtime project that includes data structures for the Lambda Events that I'll encounter while working with these payloads.

The Lambda Rust Runtime project bridges that gap between SDK support and enhanced developer experience. Now this code IS flagged as experimental as it is subject to change. Didn't I just say above that I don't like experimental software in production? For something like a critical SDK into AWS, yes. But for something that is mostly data structures and working with different Lambda events, I don't have an issue. I'm comfortable with recommending builders look into this repository. I've also been fortunate to contribute to it and believe that the libraries included will make builder's lives easier. End of the day, if the experimental piece is a hold-up, a Lambda with Rust will be fine without it.

If you are building Rust applications that are deployed in Lambdas, it's well worth your time to check out this AWS project. And nestled inside that repository is a Lambda Events crate that helps with the serde/deserde of different payloads to be encountered when running Lambdas.

Feel free to take look at the GitHub repo and ask any questions you have there, we're always happy to help in what we can: https://github.com/awslabs/aws-lambda-rust-runtime

Rust on Lambda's using containers as the deployment artifact are also very good, i'd say a perfect match. Low artifact size, low cpu+memory usage, fast execution. I think AWS must be using increasingly using Rust on Lambda internally from the talks I've seen them publish and the work gone in to https://github.com/awslabs/aws-lambda-rust-runtime.

For simple REST API's there's not much extra effort in using Rust once you are familiar.

Check out the official AWS Lambda Rust project https://github.com/awslabs/aws-lambda-rust-runtime. It has a bunch of examples and we’ll designed. I got up and running knowing minimal Rust very quickly.

The official https://github.com/awslabs/aws-lambda-rust-runtime seems well architected.

Hi, maybe check out https://github.com/awslabs/aws-lambda-rust-runtime there's some examples in there.. But essentially you can build a Lambda function and deploy to your AWS account with this toolset.

use aws_lambda_events::apigw::{ ApiGatewayCustomAuthorizerRequestTypeRequest, ApiGatewayCustomAuthorizerResponse, ApiGatewayCustomAuthorizerPolicy, IamPolicyStatement, }; use lambda_runtime::{run, service_fn, Error, LambdaEvent}; use serde_json::json; #[tokio::main] async fn main() -> Result<(), Error> { tracing_subscriber::fmt() .with_ansi(false) .without_time() .with_max_level(tracing_subscriber::filter::LevelFilter::INFO) .init(); run(service_fn(function_handler)).await } pub async fn function_handler(event: LambdaEvent) -> Result { // do something with the event payload let method_arn = event.payload.method_arn.unwrap(); // for example we could use the authorization header if let Some(token) = event.payload.headers.get("authorization") { // do something with the token // my custom logic return Ok(custom_authorizer_response( "ALLOW", "some_principal", &method_arn, )); } Ok(custom_authorizer_response( &"DENY".to_string(), "", &method_arn)) } pub fn custom_authorizer_response(effect: &str, principal: &str, method_arn: &str) -> ApiGatewayCustomAuthorizerResponse { let stmt = IamPolicyStatement { action: vec!["execute-api:Invoke".to_string()], resource: vec![method_arn.to_owned()], effect: Some(effect.to_owned()), }; let policy = ApiGatewayCustomAuthorizerPolicy { version: Some("2012-10-17".to_string()), statement: vec![stmt], }; ApiGatewayCustomAuthorizerResponse { principal_id: Some(principal.to_owned()), policy_document: policy, context: json!({ "email": principal }), // https://github.com/awslabs/aws-lambda-rust-runtime/discussions/548 usage_identifier_key: None, } }

FYI, there’s an offical rust “runtime” in the works: https://github.com/awslabs/aws-lambda-rust-runtime