This (half)month in Python: Get to know the world of data science tools beyond usual suspects like NumPy and Pandas. Also: Take the hiccups out of setting up Python, learn why Python, Java, and JavaScript are so popular, and check out the new IDE just for Python and R users.

Top picks for Python readers on InfoWorld

5 newer data science tools you should be using with Python
NumPy and Pandas not enough? Here are some lesser-known but top-shelf data tools.

Maker of RStudio launches new R and Python IDE
Positron puts R and Python side-by-side in a VS Code-like workspace.

How to install Python the smart way
Don’t get tangled in a snake’s nest of setup directions. Here’s a guide to successful Python-ing on all the major operating systems.

Why enterprises rely on JavaScript, Python, and Java
Simplicity, power, and longevity are key—and harder to replace than some might think.

More good reads and Python updates elsewhere

LPython, experimental ahead-of-time compiler for Python, hits version 0.22
A new challenger arises in the struggle to make Python faster and easier to deploy.

Rye: A Hassle-Free Python Experience
Try out Rye; see if it makes your Py management issues go bye-bye.

All PyCon US 2024 sessions are now online at YouTube
Did you miss something? Stream the sessions and get caught up.

All Set! Looking Under the Hood of Python’s Set Data Structure
Find out why Python’s set datatype is more than just a dictionary with no keys.

Management was optimistic when XYZ, Inc., embarked on a journey to migrate its extensive legacy systems to the cloud using cutting-edge generative AI tools. Partnering with a leading AI solutions vendor promised efficiency and reduced costs. However, the generative AI tools needed help to handle the complexity and specificity of XYZ’s systems, which led to frequent manual interventions. Timelines were constantly revised, and the project ran over budget six months into the migration. What was supposed to be a streamlined process turned into a tangled web of unexpected expenses and delays. How could this happen?  

XYZ’s experience contradicts McKinsey’s claim that “the use of generative AI is cutting down cloud migration efforts by 30% to 50% when done correctly.” Smash cut to my inbox, where enterprises that want to do cloud migrations on the cheap keep asking about generative AI-powered migration tools that shorten this process.   

Of course, there are legitimate benefits to using AI for migration, such as developing net-new applications and application refactoring. However, the overall tone of this article and others often reinforce the hope that generative AI will save us from talent shortages and compressed migration schedules.  

Spoiler alert: This is wishful thinking at its best. 

The promise and perils 

At first glance, using large language models (LLMs) for cloud migration sounds like a silver bullet. These models can theoretically understand a system’s infrastructure and produce the necessary scripts to facilitate migration. However, the assumption that generative AI can homogenize the diverse and intricate landscapes of enterprise IT is an idea that needs to be revisited. Here’s why: 

• Each cloud migration project is unique. Its intricacies demand specific tools and processes tailored to particular problem domains. Generative AI rarely accounts for the bespoke nature of these requirements, which leads to half-baked solutions that require substantial human intervention to correct. 
• Many enterprises operate with legacy systems. Workflows are often nuanced and undocumented. LLMs may need help to accurately interpret these complexities, leading to gaps in the migration process. These gaps can necessitate costly rewrites and intense debugging sessions, defeating the purpose of using AI in the first place. 
• Enterprises in regulated industries face stringent compliance requirements. Although generative AI can help identify potential compliance issues, the final validation often requires human oversight to ensure that AI-driven recommendations meet regulatory standards can add complexity and cost. 

No simple solution 

The allure of generative AI lies in its promise of automation and efficiency. If cloud migration was a one-size-fits-all scenario, that would work. But each enterprise faces unique challenges based on its technological stack, business requirements, and regulatory environment. Expecting a generative AI model to handle all migration tasks seamlessly is unrealistic. 

I suspect that by the time you set up an AI migration toolchain to assist in the migration, the time delay and the cost of that toolchain would erase any potential benefit. If you think about it, you can find other examples in the IT industry where some technology removes a value instead of adding one—about half the time, in my experience. 

Successful cloud migrations rely on specialized tools and human expertise. For instance, customized tools address specific issues encountered during migration. Real-time synthetic testing and infrastructure-as-code frameworks are indispensable in handling the minutiae of migration tasks. 

Also, human oversight is still needed. Skilled professionals bring critical insights that AI cannot replicate. Their expertise is essential in navigating unforeseen challenges and ensuring the integrity of the migration process. 

The real cost of generative AI 

Beyond the initial investment in AI tools, the hidden costs of generative AI for cloud migration add up quickly.  For instance, running generative AI models often requires substantial computational resources, which can be expensive. Also, keeping generative AI models updated and secure demands robust API management and cybersecurity measures. Finally, AI models need continual refinement and retraining to stay relevant, incurring ongoing costs. 

These factors often lead to a situation very similar to our fictional XYZ Inc. Generative AI, while valuable in certain aspects, is yet to be the panacea for cloud migration complexities. 

I know what a few of you are saying. “There goes Linthicum again, raining on the generative AI parade and killing the excitement of using AI as a force multiplier for the people doing cloud migrations.” Successful business strategy is about what works well and what needs to be improved. We all understand that AI is a powerful tool and has been for decades, but it needs to be considered carefully—once you’ve identified the specific problem you’re looking to solve.    

Cloud migration is a complex, multifaceted process that demands solutions tailored to unique enterprise needs. While generative AI holds promise, over-reliance on it can lead to increased costs and complexities rather than simplification. The key to successful migration lies in a balanced approach, leveraging AI where it excels while relying on specialized tools and human expertise to navigate the thorny landscape of cloud transition. 

By understanding the limitations and realistic applications of generative AI, enterprises can better plan their migration strategies, avoid the pitfalls of overautomation, and ensure a smoother, more cost-effective transition to the cloud. 

When it comes to AI and hiring, 73% of HR professionals surveyed said they trust AI to recommend whom to hire, according to a newly released report from HireVue, provider of a hiring platform that leverages AI. However, the same survey indicated that workers are not sold on the use of AI for hiring.

Released July 11, HireVue’s 2024 Global Guide to AI in Hiring is downloadable from HireVue’s website. It includes data from a survey of 3,100 workers and 1,000 HR professionals across the USA, UK, and Australia. The report states that 73% of HR professionals say they trust AI to make candidate recommendations and that 70% currently use or plan to use AI in some capacity in the next year. Also, 66% of HR professionals have a more positive attitude toward the use of AI in the workplace compared to a year ago. By contrast, 75% of workers surveyed said they were opposed to AI making final hiring decisions, and 79% said they would like to know if an employer is using AI in the hiring process when they apply for a job. Still, 49% of workers believe AI could help the issue of bias and unfair treatment in hiring.

Both HR professionals and workers seem equally comfortable with AI’s role in minor, tedious tasks, such as automated responses for hiring leaders and résumé writing for job seekers. While HR professionals are largely in favor of gaining efficiencies throughout the hiring process, workers have concerns about AI’s role as they progress toward final hiring decisions, the HireVue report found.

More than two-thirds of the HR professionals surveyed said they are excited about using AI at work. HR professionals are comfortable using AI for tasks such as writing emails and editing content. The top three ways AI is being used in hiring by the HR professionals surveyed:

• 31% use AI for candidate communications.
• 27% use AI for résumé screening.
• 27% use AI for assessments.

Nearly three in four workers acknowledge that AI in the workplace will have a major impact on them in the next 20 years. But two in three believe AI does a worse job than humans at figuring out which applicants would work well with co-workers, while 50% said AI does a worse job than humans at seeing potential job applicants who may not perfectly fit the job description.

Reasons abound for Rust’s growing popularity: it’s fast, memory-safe without needing garbage collection, and outfitted with world-class tooling. Rust also allows experienced programmers to selectively toggle off some—although not all—of its safeties for the sake of speed or direct low-level memory manipulation.

“Unsafe” Rust is the general term for any Rust code that is contained in a block delineated by the unsafe keyword. Inside an unsafe block, you can bend (but not break) some (but not all) of Rust’s safety rules.

If you’ve come from C or another low-level systems language, you may be tempted to reach for unsafe whenever you want to use some familiar pattern for manipulating things in a low-level way. In some cases, you may be right: there are a few things you can’t do in Rust except through unsafe code. But in many cases you don’t actually need unsafe. Rust already has you covered if you know where to look.

In this article, we’ll explore what unsafe Rust is actually for, what it can and can’t do, and how to use it sensibly.

What you can do with ‘unsafe’ Rust

The unsafe keyword in Rust lets you delineate a block of code, or function, to enable a specific subset of features in the language. Let’s look at the features you can access inside Rust’s unsafe blocks.

Raw pointers

Rust’s raw pointers can refer to mutable or immutable values and are closer to C’s idea of a pointer than Rust’s references. With them, you can ignore some of the rules for how borrowing works:

• Raw pointers can be null values.
• Multiple raw mutable pointers can point to the same space in memory.
• You can also use both immutable and mutable pointers to refer to the same memory.
• You don’t need to guarantee that a raw pointer points to a valid region of memory.

Raw pointers are useful if you need to do things like access hardware directly (e.g., for a device driver), or talk to an application written in another language by way of a raw region of memory.

External function calls

Another common use of unsafe is to make calls through a foreign function interface, or FFI. There’s no guarantee that what we get back from such a call will follow Rust’s rules, and there’s also a chance we will need to supply things that don’t conform to those rules (such as a raw pointer).

Consider this example (from Rust’s documentation):

extern "C" {
    fn abs(input: i32) -> i32;
}

fn main() {
    unsafe {
        println!("Absolute value of -3 according to C: {}", abs(-3));
    }
}

Any calls made to the functions exposed via the extern "C" block must be wrapped in unsafe, the better to ensure you take proper responsibility for what you send to it and get back from it.

Altering mutable static variables

Global or static variables in Rust can be set to mutable, since they occupy a fixed memory address. However, it’s only possible to modify a mutable static variable inside an unsafe block.

Data races are the biggest reason you need unsafe to alter mutable static variables. You’d get unpredictable results if you allowed the same mutable static variable to be modified from different threads. So, while you can use unsafe to make such changes, any data race issues would be your responsibility, not Rust’s. In general, Rust cannot entirely prevent data races, but you need to be doubly cautious about that in unsafe blocks.

Creating unsafe methods and traits

Methods (functions) can be made unsafe with the declaration unsafe fn (). You’d use this to ensure that any call to such a method must also be performed inside an unsafe block.

For instance, if you had a function that required a raw pointer as an argument, you’d want to ensure the caller did their due diligence for how the call was performed in the first place. Any safeties don’t begin and end at the function-call boundary.

You can also declare traits unsafe, along with their implementations, using a similar syntax: unsafe trait for the trait, and unsafe impl for the implementation.

Unlike an unsafe method, though, an unsafe trait implementation does not have to be called inside an unsafe block. The burden of safety is on the one writing the implementation, not the one calling it.

Unions

Unions in Rust are essentially the same as unions in C: a struct that has multiple possible type definitions for its contents. This kind of loosey-goosey behavior is acceptable in C, but Rust’s sterner promises of correctness and safety don’t allow it by default.

However, sometimes you need to create a Rust structure that maps to a C union, such as when you call into a C library to work with a union. To do this, you need to use unsafe to access one particular field definition at a time.

Here’s an example from the Comprehensive Rust guide:

#[repr(C)]
union MyUnion {
    i: u8,
    b: bool,
}

fn main() {
    let u = MyUnion { i: 42 };
    println!("int: {}", unsafe { u.i });
    println!("bool: {}", unsafe { u.b }); // Undefined behavior!
}

For each access to the union, you have to use unsafe. The borrow checker also requires borrowing all the fields of a union even if you just want to access one of them at a time.

Note that writing to a union does not have the same restrictions: in Rust’s eyes you’re not writing to anything that needs tracking. That’s why you don’t need unsafe when defining the contents of the union with the let statement.

What you cannot do with Rust ‘unsafe’

Outside of the four big points listed above, unsafe doesn’t give you any other special powers.

The single biggest thing you can’t do is use unsafe to circumvent the borrow checker. Borrows are still enforced on values in unsafe, same as anyplace else. One of Rust’s truly immutable principles is how borrowing and references work, and unsafe does not alter those rules.

For a good example of this, look at the way borrowing is still enforced in unions, as described in the previous section. See Steve Klabnik’s blog post for a more detailed discussion on this topic. It’s better to think of unsafe as a superset of Rust—something that adds a few new features without taking away existing ones.

Best practices with unsafe code

unsafe is like any other language feature: it has its uses and limitations, so use it judiciously and with care. Here are some pointers.

Wrap as little code as possible in ‘unsafe’

The smaller an unsafe block is, the better. In many cases, you don’t need to make unsafe blocks more than a couple of lines. It’s worth thinking about how much of the code actually needs to be unsafe, and how to enforce boundaries and interfaces around that code. It’s best to have safe interfaces to code that’s not safe.

Sometimes the interfaces themselves have to be unsafe. I mentioned earlier that you can declare an entire function as unsafe—for example, unsafe fn (). If an argument to a function requires unsafe, any calls to such a function also must be unsafe.

On the whole, though, it’s best to start with individual unsafe blocks, and promote them to functions only if needed.

Be mindful of undefined behaviors

Undefined behaviors exist in Rust, and so they also exist in unsafe Rust. For instance, Rust’s basic safeties don’t guard against data races, or reading from uninitialized memory. Be extra careful of how you might be introducing undefined behavior in your unsafe blocks.

For examples of what to avoid, the Rust Reference has a long but not exhaustive list of undefined behavior.

Document why ‘unsafe’ is needed

It’s been said that we comment code not to say what is being done, but why. That idea absolutely applies to unsafe blocks.

Whenever possible, document exactly why unsafe is needed at any given point. This gives others some idea of the rationale behind the use of unsafe, and—potentially—future insight into how the code could be rewritten to not need unsafe.

Read the Rustonomicon

Rust’s documentation is second to none. That includes the Rustonomicon, an entire book-length document created to thoroughly document “all the awful details that you need to understand when writing Unsafe Rust programs.” Don’t open it until you are comfortable with Rust generally, as it delves into great detail about how “unsafe” and “regular” Rust interoperate.

If you’re coming in from the C side of things, another useful document is Learn Rust The Dangerous Way. This collection of articles talks about Rust in a way that people used to low-level C programming can wrap their heads around, including best practices for using Rust’s unsafe feature.

Userware has released OpenSilver 3.0, and update to the free and open-source UI framework for .NET that introduces a drag-and-drop UI designer. The release also previews a generative AI-powered UI designer.

Introduced July 9, OpenSilver 3.0 integrates AI functionality into the designer that allows users to generate complex UIs and make modifications using natural language commands, Userware said. Developers can describe desired changes and the XAML code will be automatically updated. Developers also can upload images or a mockup, and the AI will generate an approximation.

Known as a replacement for Microsoft’s Silverlight rich Internet application framework, OpenSilver can be downloaded from forms.opensilver.net. Developers can use it to build .NET web applications in C# and XAML.

OpenSilver 3.0 also features a drag-and-drop UI designer with more than 100 built-in controls and support for Microsoft’s Visual Studio Code editor in addition to already supporting the Microsoft Visual Studio IDE. These moves extend the OpenSilver development environment to Windows, Mac, and Linux systems, Userware said.

OpenSilver 3.0 also introduces XAML.io, an online XAML designer that allows developers to build an app directly in the web browser, with no installation required. Developers then can transition to Visual Studio for further development. XAML.io was built using OpenSilver.

OpenSilver 3.0 also improves the ability to load XAML dynamically from a string at runtime, revamps how resources are packaged into compiled assemblies, and moves TypeScript definitions to a separate NuGet package (OpenSilver.TypeScriptDefinitionsToCSharp). Further, as part of the 3.0 release, Userware is expanding professional services to help businesses leverage .NET and AI.

Upcoming plans for OpenSilver include .NET MAUI hybrid support, allowing developers to deploy native applications across iOS, Windows, Android, and MacOS, and seamless integration of Blazor and JavaScript components within C# and XAML code.

More developer news:

• FTC’s non-compete ban almost certainly dead, based on a Texas federal court decision
• Microsoft moves forward with C# 13, offering overload resolution
• Amazon Bedrock updated with contextual grounding, RAG connectors
• Google, Udacity offer free course on Gemini API
• Judge dismisses lawsuit over GitHub Copilot AI coding assistant

FastEndpoints is a free and open-source REST API development framework for .NET Core that can be used to build lightweight and fast APIs. In this article, we’ll examine this library and learn how to use it to build lightweight APIs in ASP.NET Core applications.

ASP.NET Core supports two built-in approaches to building APIs, traditional controllers and minimal APIs. Traditional controllers (i.e., MVC and API controllers in ASP.NET Core) are feature-rich, but they require writing a lot of boilerplate code and they don’t match minimal APIs in performance. Minimal APIs are lightweight and fast, but they support only a minimal set of features.

A third option is to use a third-party library for building APIs such as FastEndpoints, which combines benefits of both controllers and minimal APIs. While minimal APIs are slightly faster than FastEndpoints, FastEndpoints provides several features that are not supported by minimal APIs including model binding, rate limiting, and caching. Moreover, if you use FastEndpoints in lieu of minimal APIs, you can take advantage of Swagger or OpenAPI to document your APIs.

Introducing FastEndpoints

An implementation of the REPR (Request-Endpoint-Response) design pattern, FastEndpoints is a developer-friendly, minimalist alternative to minimal APIs and traditional MVC and API controllers. The REPR design pattern simplifies API development by organizing your APIs around endpoints instead of controllers. It provides distinct separation between the input request, the logic at the endpoint, and the output response.

In the sections that follow, we’ll examine how we can use FastEndpoints to build fast and lean APIs in ASP.NET Core. Our implementation will include an endpoint class, a request DTO (Data Transfer Object) class, and a response DTO class.

Create an ASP.NET Core Web API project in Visual Studio 2022

To create an ASP.NET Core Web API project in Visual Studio 2022, follow the steps outlined below.

1. Launch the Visual Studio 2022 IDE.
2. Click on “Create new project.”
3. In the “Create new project” window, select “ASP.NET Core Web API” from the list of templates displayed.
4. Click Next.
5. In the “Configure your new project” window, specify the name and location for the new project. Optionally check the “Place solution and project in the same directory” check box, depending on your preferences.
6. Click Next.
7. In the “Additional Information” window shown next, select “.NET 8.0 (Long Term Support)” as the framework version and uncheck the check box that says “Use controllers,” as we’ll be using minimal APIs in this project.
8. Elsewhere in the “Additional Information” window, leave the “Authentication Type” set to “None” (the default) and make sure the check boxes “Enable OpenAPI Support,” “Configure for HTTPS,” and “Enable Docker” remain unchecked. We won’t be using any of those features here.
9. Click Create.

We’ll use this ASP.NET Core Web API minimal API project to work with the code examples given in the sections below.

Install the FastEndpoints NuGet package

To work with FastEndpoints library, we’ll need to install the FastEndpoints NuGet package in the project. To do this, select the project in the Solution Explorer window, then right-click and select “Manage NuGet Packages.”

In the NuGet Package Manager window, search for the FastEndpoints package and install it. Alternatively, you can install the packages via the NuGet Package Manager console by entering the command shown below.

PM> Install-Package FastEndpoints

Register the FastEndpoints library

To add FastEndpoint services to the ASP.NET Core request processing pipeline, enter the following line of code in the Program.cs file.

builder.Services.AddFastEndpoints();

Note that at runtime, the FastEndpoints library excludes endpoints that are located in any of the assembly names that are part of the exclusion list. You can take a look at how that has been implemented here.

If your endpoint is located in any of those assembly names, the FastEndpoints library will throw an exception at runtime during its registration process. To avoid this exception, rename your project to a name that is not on the exclusion list or specify an assembly name manually as shown in the following code snippet.

builder.Services.AddFastEndpoints(
    o => o.Assemblies = new[]
    {
        typeof(FastEndpoints_Demo.MyFirstRequest).Assembly,
        typeof(FastEndpoints_Demo.MyFirstResponse).Assembly
    });

Next we’ll create our first endpoint using the FastEndpoints library. This endpoint will handle a HTTP POST request and send the response back to the client.

Create a request class

To create a request DTO, create a new C# class named MyFirstRequest and replace the generated code with the following code snippet.

namespace FastEndpoints_Demo
{
    public class MyFirstRequest
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }
}

Create a response class

To create a response DTO, create a new C# class named MyFirstResponse and replace the generated code with the following code.

namespace FastEndpoints_Demo
{
    public class MyFirstResponse
    {
        public string Message { get; set; }
    }
}

Create an endpoint class

An endpoint class can be created by extending the Endpoint base class. Your custom endpoint class should use the request and response DTOs to store data. Let’s now create a new C# class named MyFirstEndpoint and give it the following code.

using FastEndpoints;
namespace FastEndpoints_Demo.Endpoints
{
    public class MyFirstEndpoint : Endpoint
    {
        public override void Configure()
        {
            Post("/api/author/create");
            AllowAnonymous();
        }
        public override async Task HandleAsync(MyFirstRequest request, CancellationToken token)
        {
            await SendAsync(new()
            {
                Message = $"The author name is: {request.FirstName} {request.LastName}"
            });
        }
    }
}

As you can see in the preceding code listing, the custom endpoint class should override the Configure and HandleAsync methods. Configure is used to configure how your custom endpoint should listen to incoming requests. HandleAsync contains the necessary logic for processing the request and sending back the response.

Complete Program.cs file

The following is the complete source code of the Program.cs file for your reference.

using FastEndpoints;
var builder = WebApplication.CreateBuilder();
builder.Services.AddFastEndpoints(
    o => o.Assemblies = new[]
    {
        typeof(FastEndpoints_Demo.MyFirstRequest).Assembly,
        typeof(FastEndpoints_Demo.MyFirstResponse).Assembly
    });
var app = builder.Build();
app.UseFastEndpoints();
app.Run();

Execute the application

Finally, run the application and browse the endpoint using Postman with the following request body.

{
    "FirstName": "Joydip",
    "LastName": "Kanjilal"
}

Figure 1 shows the output you should see upon invoking the endpoint.

FastEndpoints is a free third-party alternative to ASP.NET Core’s built-in legacy controllers and minimal APIs. FastEndpoints combines performance on a par with minimal APIs and a structured approach to handling HTTP requests and responses. I’ll demonstrate how we can implement security, versioning, validation, dependency injection, caching, and rate limiting with FastEndpoints in future posts here.

Just a handful of years ago we couldn’t stop talking about serverless computing. Then it seemed to disappear, overtaken first by Kubernetes and then by generative AI. But of course, like most technologies, it’s still there, delivering the on-demand compute that’s part of most modern cloud-native design.

Microsoft’s Azure Functions has continued to evolve, supporting updated APIs and languages, as well as becoming part of the Azure recommended patterns and practices, supporting everything from AI to Internet of Things. What remains key to Azure Functions is its ability to deliver on-demand capacity on a “pay for what you use” basis. With serverless tools there’s no need to provision infrastructure; instead you write stateless code that responds to events.

This event-driven model is key to the importance of serverless computing, as it allows you to process and use data as it arrives. As a result, you can consider serverless a key component of modern message-based applications, taking advantage of publish-and-subscribe technologies like Azure Event Grid and the open standards-based CloudEvents messaging format.

Build 2024 saw Microsoft deliver a set of major updates to Azure Functions to align it more closely with current development trends, including the ability to run in managed Kubernetes environments and to support on-demand AI applications built around Azure OpenAI.

Running Azure Container Functions in Azure Container Apps

Microsoft’s Azure Container Apps is a managed Kubernetes environment, where all you’re concerned with is your application containers and basic scaling rules. There’s no need to work with the underlying Kubernetes platform, as much of its functionality has been automated. If Azure Functions is serverless, Azure Container Apps (ACA) is perhaps best thought of as platformless.

One key Azure Functions feature is its portability, with the option of building Functions apps and a basic runtime in containers for deployment and testing. It’s a useful option, and Microsoft used Build to announce that ACA now supports Functions containers as part of a mix of container-hosted services. With support for event-driven scaling, ACA is an ideal host for your Functions, launching containers on demand.

The container hosts the same runtime that’s used elsewhere in Azure, so you can continue to use your existing toolchain with the same integrations as a standard Azure Function. That includes the same bindings, with ACA handling scaling for you, using Kubernetes-based event-driven autoscaling (KEDA). One important difference is instead of being billed as an Azure Function, your ACA-hosted Functions will be billed as part of your ACA plan, using either a serverless Consumption model or the more complex Dedicated plan. If you’re using a Dedicated plan, your Functions can access GPU resources, which can help accelerate local AI models.

The containers that host Functions are Linux-based, with different base images for each language option. The Functions command-line development tool will create the correct image for you when you use the –docker option as part of creating a new Functions project. You will need to keep this image up to date to ensure you have the latest security patches, which will require redeploying your image on a roughly monthly cadence, as new images are released regularly.

Using Azure Functions with Azure OpenAI

Build 2024 was very much led by Microsoft’s AI investments. Azure Functions may not have its own Copilot (yet), but it’s now part of Microsoft’s AI programming toolchain, with a set of APIs that lets you use Functions to drive generative AI operations, as well as to respond to triggers from Azure OpenAI.

Triggering Functions from Azure OpenAI goes some way to delivering a serverless agent. Prompts call known Functions, and Function outputs are themselves used as prompts that can deliver natural language outputs. Other tools let you update and read from vector search indexes, allowing you to use Functions to maintain your local semantic store.

Microsoft is previewing a Functions extension that ships for all the supported languages. Depending on your choice of development tools, start by installing the extension package into your Function. For example, if you’re using C#, you use NuGet to install the package from the .NET CLI. You’ll need to install packages for the vector database you’re using, like Azure AI Search or Cosmos DB’s new DiskANN-based vector search.

One useful option is the ability to build a function that acts as an assistant in an Azure OpenAI workflow, using it as a skill in a Prompt Flow operation. When a chatbot detects a request that needs to be passed to your function, based on the function description, it passes the data as a string. Your function can then process that string, for example, adding it to another application’s database.

If you prefer, you can use a function to create a chatbot (or at least a generative AI interaction) based on an external trigger. This allows you to dynamically generate prompts, using a function to gatekeep your AI, providing filters and avoiding known prompt injection attacks. A simple interaction sends a request to an Azure OpenAI endpoint and gets a response that can be forwarded to another function.

There’s a lot that can be done using serverless computing techniques with Azure OpenAI. Azure Functions work well as plug-ins and skills for tools like Prompt Flow or Semantic Kernel, going beyond basic chatbots and using Azure OpenAI as the basis of an AI-powered agent, with no direct interaction between the large language model and your users. It’s worth thinking about how you can use the combined capabilities of an LLM and Azure Functions, as a retrieval-augmented generation (RAG)-grounded application or as a natural language interface for more complex applications.

Flex Consumption billing supports new application models

Alongside new application development features, Azure Functions gets a new billing option. The Flex Consumption plan is an extension of the existing Consumption plan, adding more flexibility around the underlying infrastructure. Instances are built on top of Linux servers, with support for familiar Functions programming environments, including C# .NET 8 code and Node.js.

Although much of the value in serverless computing is the ability to ignore infrastructure and simply run with available resources, there’s still a need for some fixed options that control how your function deploys and what resources it can use. These include using private networking, choosing the memory size for your host instances, and supporting different scale-out models.

You can think of this plan as a premium option, one that adds features focused on large implementations that require rapid responses. Scaling is still event-driven, but you can now have up to 1,000 instances rather than a maximum of 200. At the same time, new instances support fast deployments, as well as a set number of instances that are ready to run at all times. This approach reduces application latency, spinning up additional always-ready instances as soon as your current set becomes active. Larger memory instances get access to more network bandwidth and more CPU.

As well as the default 2048MB memory option, Flex Consumption plans allow larger instances, supporting 4096MB. This can help with applications that need larger memory or more compute, for example, running vector searches for event-driven RAG applications. Support for private virtual networks is another important option for enterprise serverless computing, as it ensures links to other Azure services and to storage remaining inside your own secure network.

Serverless technologies such as Azure Functions remain an important tool for building modern, cloud-based applications. They provide a framework for rapid scaling and help keep costs to a minimum, only being billed when running. As they respond to events and messages, they’re a useful companion to Kubernetes and modern AI platforms, providing an effective way to rapidly add new functions and services to your Azure applications.

Microsoft, in its latest informational update on the planned C# 13 language release, is emphasizing capabilities such as overload resolution, with developers able to supply multiple params overloads when authoring a method, and partial properties, similar to partial methods.

The company published its latest blog on C# 13 on July 9. C# 13 is likely to be finalized in November, along with the latest update to the  planned .NET 9 software development platform. In detailing overload resolution, Microsoft said that when authoring a method, developers can supply multiple params overloads. This can reduce allocations, which can improve performance. Multiple overloads can both boost performance and add convenience. Library authors are advised to give all overloads the same semantics so callers do not need to be concerned about which overload is used. Partial properties, meanwhile, are described as being like partial method counterparts. It will be easier for source generator designers to create APIs with a natural feel.

Also in C# 13, the release refines the rules for determining the natural type to consider candidates by scope and to prune candidates with no chance of succeeding. Updating these rules means fewer compiler errors when working with method groups. The release, with allows ref struct, also adds a new way to specify capabilities for generic type parameters. By default, parameters cannot be ref struct. C# 13 lets developers specify the type can be a ref struct, and applies appropriate rules. When other generic constraints limit the set of types that can be used as a type parameter, the new specification expands the allowed types. This removes rather than adds a restriction.

In another improvement in C# 13, async methods can declare ref local variables or local variables of a ref struct type. These variables cannot be preserved across an await boundary or a yield return boundary. In this fashion, C# 13 allows the unsafe context in iterator methods.

C# 13 also extends params, a feature previously cited by Microsoft. With C# 13, params will be extended to work with any type that can be constructed via a collection expression. This adds flexibility whether developers are writing a method or calling it. Beginning with C# 13, params parameters can be of any type that is supported for collection expressions. Elsewhere in C# 13, the language makes it easy to use a new System.Threading.Lock type featured in .NET 9. This type is for mutual exclusion, which can be more efficient than locking on an arbitrary System.Object instance. C# 13 also introduces a new escape sequence for the ESCAPE or ESC character. The new sequence is especially convenient when interacting with terminals with the VT100/ANSI escape codes to System.Console.

Amazon Web Services (AWS) has updated its generative AI development service, Amazon Bedrock, with a new contextual grounding feature, connectors for retrieval augmented generation (RAG), and additional large language models (LLMs).

These updates, according to Amazon’s vice president of generative AI Vasi Philomin, are expected to ease the development of generative AI-based applications for enterprises.

Contextual grounding, an addition to Guardrails for Amazon Bedrock, aims to further reduce the chances of receiving unwarranted or hallucinatory responses from an application underpinned by a LLM, Philomin said.

Contextual grounding uses RAG and summarization applications to detect hallucinations in model responses, checks if the LLM response is based on the right enterprise data, and is aligned to the user’s query or instruction, the vice president explained.

Other major cloud service providers, such as Google and Microsoft Azure, also have a system in place to evaluate the reliability of RAG applications, including the mapping of response generation metrics.

While Microsoft uses the Groundedness Detection API to check whether the text responses of LLMs are grounded in the source materials provided by users, Google recently updated its grounding options inside Vertex AI with features such as dynamic retrieval and high-fidelity mode.

AWS also offers RAG evaluation and observability features in Amazon Bedrock that use metrics such as faithfulness, answer relevance, and answer semantic similarity to benchmark a query response. AWS said that it will offer Guardrails for Amazon Bedrock as a separate API to be used with LLMs outside of Bedrock.

“The standalone Guardrails API is being released after we received a lot of requests from enterprise customers who want to use it on models outside of Bedrock,” Philomin said.

AWS’s move is reminiscent of IBM’s strategy to make its watsonx.governance product available via a toolkit this May. While the IBM toolkit is not exactly comparable to the Guardrails API, it can be used to create a repository for logging details throughout a model’s life cycle. Such information can be helpful in evaluating the rationale behind a certain model choice or determining which stakeholder had what involvement in the model’s life cycle.

New RAG connectors and large language models

As part of the updates to its generative AI service, AWS has added new RAG connectors to Amazon Bedrock to allow developers to ground models across a larger variety of data sources.

In addition to Amazon S3, developers can now use connectors for Salesforce, Confluence, and SharePoint for RAG, Philomin said. He said the SharePoint connector was currently in preview.

AWS also announced that it was adding the ability to fine-tune Anthropic’s Claude 3 Haiku inside Bedrock. The ability to fine-tune Claude 3 Haiku, which is in preview, according to Philomin, is not available with any other cloud services provider yet and is heavily sought by enterprise customers.

Other updates include the general availability of vector search for Amazon MemoryDB and new capabilities to Agents for Bedrock.

“Now agents can retain memory across multiple interactions to remember where you last left off and provide better recommendations based on prior interactions,” Philomin said. He noted that Agents can now interpret code to tackle complex data-driven use cases, such as data analysis, data visualization, text processing, solving equations, and optimization problems.

Amazon App Studio to help develop apps in natural language

AWS on Wednesday also showcased AWS App Studio, a generative AI-based managed service that allows any enterprise user to build and deploy applications using natural language prompts.

“With App Studio, a user simply describes the application they want, what they want it to do, and the data sources they want to integrate with, and App Studio builds an application in minutes that could have taken a professional developer days to build a similar application from scratch,” AWS said in a statement. App Studio’s generative AI assistant eliminates the need for learning any low-code tools, the company said.

Amazon App Studio is likely to compete with rival offerings such as Google’s Vertex AI Studio and Microsoft’s Copilot Studio.

AWS also announced the general availability of Amazon Q Apps, a feature inside Amazon Q Business that was showcased at AWS re:Invent last year.

“With Amazon Q Apps enterprise users can go from conversation to generative AI-powered app based on their company data in seconds. Users simply describe the application they want in a prompt and Amazon Q instantly generates it,” AWS said. The company added that Amazon Q allows users to generate an app from an existing conversation.

More AI news:

• OpenSilver 3.0 previews AI-powered UI designer for .NET
• Researchers reveal flaws in AI agent benchmarking
• Judge dismisses lawsuit over GitHub Copilot AI coding assistant

Cyber defense safeguards information systems, networks, and data from cyber threats through proactive security measures. It involves deploying strategies and technologies to protect against evolving threats that may cause harm to business continuity and reputation. These strategies include risk assessment and management, threat detection and incident response planning, and disaster recovery.

Threat Intelligence (TI) plays a crucial role in cyber defense by providing valuable insights from analyzing indicators of compromise (IoCs) such as domain names, IP addresses, and file hash values related to potential and active security threats. These IoCs enable organizations to identify threat actors’ tactics, techniques, and procedures, enhancing their ability to defend against potential attack vectors.

Benefits of threat intelligence

Threat intelligence helps security teams turn raw data into actionable insights, providing a deeper understanding of cyberattacks and enabling them to stay ahead of new threats. Some benefits of utilizing threat intelligence in an organization include:

• More effective security: Threat Intelligence helps organizations prioritize security by understanding the most prevalent threats and their impact on their IT environments. This allows for effective resource allocation of personnel, technology, and budget.
• Improved security posture: By understanding the evolving threat landscape, organizations can identify and address vulnerabilities in their systems before attackers can exploit them. This approach ensures continuous monitoring of current threats while anticipating and preparing for future threats.
• Enhanced incident response: Threat intelligence provides valuable context about potential threats, allowing security teams to respond faster and more effectively. This helps organizations minimize downtime and possible damage to their digital assets.
• Cost efficiency: Organizations can save money by preventing cyberattacks and data breaches through threat intelligence. A data breach can result in significant costs, such as repairing system damage, reduced productivity, and fines due to regulatory violations.

Wazuh integration with threat intelligence solutions

Wazuh is a free, open source security solution that offers unified SIEM and XDR protection across several platforms. It provides capabilities like threat detection and response, file integrity monitoring, vulnerability detection, security configuration assessment, and others. These capabilities help security teams swiftly detect and respond to threats in their information systems.

Wazuh provides out-of-the-box support for threat intelligence sources like VirusTotal, YARA, Maltiverse, AbuseIPDB, and CDB lists to identify known malicious IP addresses, domains, URLs, and file hashes. By mapping security events to the MITRE ATT&CK framework, Wazuh helps security teams understand how threats align with common attack methods and prioritize and respond to them effectively. Additionally, users can perform custom integrations with other platforms, allowing for a more tailored approach to their threat intelligence program.

The section below shows examples of Wazuh integrations with third-party threat intelligence solutions.

MITRE ATT&CK integration

The MITRE ATT&CK framework, an out-of-the-box integration with Wazuh, is a constantly updated database that categorizes cybercriminals’ tactics, techniques, and procedures (TTPs) throughout an attack lifecycle. Wazuh maps tactics and techniques with rules to prioritize and detect cyber threats. Users can create custom rules and map them to the appropriate MITRE ATT&CK tactics and techniques. When events involving these TTPs occur on monitored endpoints, alerts are triggered on the Wazuh dashboard, enabling security teams to respond swiftly and efficiently. 

Figure 1: MITRE ATT&CK tactics and techniques on the Wazuh dashboard

The out-of-the-box rule below detects when there is an attempt to log in to a server using SSH with a non-existent user.

Where:

• T1110.001 refers to the MITRE ATT&CK tactics of brute forcing or password guessing.
• T1021.004 refers to the MITRE ATT&CK tactics of lateral movement using remote services like SSH

Figure 2: Alerts on the Wazuh dashboard showing MITRE ATT&CK techniques and tactics

YARA integration

YARA is an open source tool for pattern matching and identifying malware signatures. Wazuh integrates with YARA to enhance threat detection by identifying patterns and signatures associated with malicious files. YARA uses the Wazuh FIM module to scan monitored endpoints for malicious files.

The effectiveness of the YARA integration is demonstrated in how Wazuh responds to Kuiper ransomware on an infected Windows endpoint.

Figure 3: Kuiper ransomware detection using Wazuh and YARA integration.

VirusTotal integration

VirusTotal is a security platform for aggregating malware signatures and other threat intelligence artifacts. Wazuh integrates with the VirusTotal API to identify known indicators of compromise, enhancing the speed and accuracy of threat detection.

For example, the Wazuh proof of concept guide shows how to detect and remove malware using VirusTotal integration.

The below block in the Wazuh configuration file /var/ossec/etc/ossec.conf detects changes to files and queries their hashes against the VirusTotal API.

Also, the Wazuh command monitoring configuration in the Wazuh server configuration file /var/ossec/etc/ossec.conf triggers the remove-threat.sh executable to remove the malicious file from the monitored endpoint when there is a positive VirusTotal match.

The figure below shows the detection and response alerts on the Wazuh dashboard.

Figure 3: VirusTotal alert on the Wazuh dashboard

Conclusion

Wazuh is a free and open source SIEM and XDR platform with many out-of-the-box capabilities that provide security across workloads in cloud and on-premises environments. Integrating Wazuh with threat intelligence feeds and platforms such as YARA, VirusTotal, and Maltiverse enhances its threat detection and response capabilities.

Learn more about Wazuh by exploring our documentation and joining our professional community.

Modernization has become table stakes for organizations, but transitioning to the cloud requires a brand new technology stack. More and more, IT leaders are turning to cloud and Kubernetes technologies to help developers and operations teams deploy, manage and scale applications more easily. However, the growing complexity of modern application development poses significant challenges for developers and operations or SRE (site reliability engineering) teams — from keeping pace with rapid technological advancements and integrations to handling the multitude of tools and supporting services essential for building, deploying and managing modern applications. This is further complicated by infrastructure dependencies and manual processes, placing additional strain on the teams. In fact, one in four organizations take three months or longer just to deploy an application.

Enter platform engineering teams, formed to play a pivotal role in centralizing efforts and managing the complexities of modern application development. According to Forrester, more than three-quarters of high-performing organizations are adopting platform teams. Organizations today rely on platform teams to eliminate the complexities of the modern software landscape, thus speeding digital transformation, fostering a culture of innovation and efficiency, and ultimately leading to better, faster, stronger enterprises.

Quarterbacks of innovation

Many organizations now recognize platform teams as the quarterbacks of innovation, suited best to abstract complexity, identify the best path to efficiency, and create a much needed springboard towards cloud and Kubernetes adoption. Platform teams are uniquely equipped to optimize resource allocation because they sit in between developers and the cloud infrastructure and compute that developers need, and are able to maximize the efficiency and effectiveness of software development processes.

With their unique set of skills and expertise, they effectively collaborate with other teams, including developers, data scientists, and operations teams, to accurately understand their needs and pain points. Using a product approach, platform teams remove barriers for developers and operations teams by offering shared services for developer self-service, enabling faster modernization within organizational boundaries and automation to simplify the management of applications and Kubernetes clusters in the cloud.

Fostering a culture of innovation, platform teams play a crucial role in keeping the organization at the forefront of emerging trends and technologies. This enables enterprises to provide innovative solutions that set them apart in the market. How? 

• They operationalize and optimize internal tools and workflows to abstract the complexity of Kubernetes away from developers, reducing the manual steps and cognitive load on developer and application teams. 
• They incorporate best practices and security measures into their workflows, removing the need for developers to be Kubernetes and cloud experts. 
• By continuously refining and optimizing the application development process and cloud infrastructure, platform teams also enable continuous improvement within the organization, driving efficiency gains and cost savings while simultaneously fostering a mindset of agility and adaptability.

Platform team playbook

Platform teams help manage the needs of developers and operations teams to maintain efficient development workflows. Gartner predicts that 80% of software engineering organizations will establish platform teams by 2026 — and that 75% of those will include developer self-service portals. 

Self-service tools provided by platform teams give developers the autonomy to provision and quickly use cloud environments (including Kubernetes clusters) through curated environment and Kubernetes clusters blueprints. By eliminating administrative bottlenecks and complex setup processes, this reduces time-to-market for new applications and allows developers to focus their efforts on innovation and product development rather than infrastructure management. 

Here are five examples of common development challenges enterprises face and how platform teams alleviate these pain points:

• Challenge: Maintaining consistency in cloud environments and Kubernetes clusters is difficult, resulting in increased support needs and costs. This inherent complexity can easily lead to errors, policy violations, regulatory issues, increased downtime, and decreased application reliability.
• Solution: Platform teams set standard configurations for cloud environments and Kubernetes clusters that can be implemented (and enforced) across the entire organization. 
• Challenge: Unauthorized access makes Kubernetes environments vulnerable to security threats. Implementing and maintaining a robust security framework for Kubernetes infrastructure is complex because it requires a deep understanding of Kubernetes’ architecture and security mechanisms. 
• Solution: Platform teams facilitate secure Kubernetes environments by integrating the organization’s Kubernetes clusters with a corporate identity provider. This enables identity-driven, role-based secure access and implements user-level auditing for the entire organization, only granting access to any necessary developers and operations team members.
• Challenge: Kubernetes infrastructure costs can come with surprise bills. Almost all enterprises are overspending in the cloud, and Kubernetes resource consumption can contribute to this if it’s not managed effectively.
• Solution: Platform teams responsible for cost management can establish FinOps processes, providing enterprises with real-time visibility into Kubernetes and cloud spend. They can analyze, allocate and define cost boundaries for each team to stay on budget. Platform teams can also prevent cloud waste by providing application teams the ability to correctly allocate and even resize resources for their applications.
• Challenge: Enabling efficient experimentation with generative AI.
• Solution: Platform teams can help companies efficiently experiment with generative AI by providing scalable infrastructure and robust tooling, enabling quick deployment and iteration of large language models. They can also streamline workflows through automation and integration, ensuring seamless collaboration between data scientists and engineers.
• Challenge: Excessive ticket volumes lead to delays in application deployments and IT bottlenecks. Kubernetes has the power to accelerate innovation, but teams need the autonomy to move fast, safely.
• Solution: With a self-service approach, developers can achieve more without relying on manual intervention. By curating a set of pre-approved environments, platform teams can empower developers with a self-service experience to deploy and manage the application life cycle efficiently and securely. 

Platform teams have emerged as critical enablers of innovation and efficiency in modern organizations because of their ability to provide a solid foundation for the development, deployment, and scaling of new technologies. These teams help their organizations bring innovative solutions to market more quickly by providing the framework necessary to handle increased workloads and accommodate business growth. Organizations with established platform teams empower their internal and downstream application teams to leapfrog towards cloud and Kubernetes adoption without the burden of steep learning curves. At the same time, they give developers and data scientists self-service capabilities that allow them to focus on what they do best — rapidly deliver new application capabilities to customers.

Mohan Atreya is chief product officer at Rafay Systems.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com

Progressive web apps (PWAs) are an important concept in web development because they combine the universality of browser deployment with the features of natively installed software. In delivering native-like functionality, being able to run background and offline operations is key.

An especially critical feature of progressive web apps is their ability to deal with situations where a user has submitted something like an email but the network is not available to process it. In this article, you’ll learn how service workers and the Sync API support offline processing in PWAs. You’ll also be introduced to IndexedDB, the browser’s built-in database.

Introduction to service workers

Considerable thinking goes into making a browser-based application behave more like a native one. The service worker is a key part of that process. A service worker is a more constrained variant of a worker thread, one that communicates with the main browser thread only via event messages, and which does not have access to the DOM. A service worker is a kind of environment unto itself, and we’ll get a taste of that here.

Despite their limitations, service workers are quite powerful in that they have their own lifecycle, independent of the main thread, in which a variety of background operations can be performed. In our case, we are interested in the Sync API, which lets a service worker observe the state of the network connection and attempt to retry a network call until it is successful.

The Sync API and sync events

Imagine if you wanted to configure a retry mechanism that said something like this:

• If the network is up, send the request right now.
• If the network is down, wait until the network is available and try again.
• If any retries fail, be smart about trying again with an exponential back-off and give-up settings.

This would require a lot of finagling. Fortunately, service workers include a specialized “sync” event for this very purpose.

Service workers are registered using the navigator.serviceWorker. This object is only available in a secure context, meaning the website must be loaded in HTTPS, not HTTP.

Our application will deal with the creation of a to-do in the tradition of the canonical TODO sample app. We’ll specifically see how we can take the creation of a new to-do and handle it using a service worker’s sync event, giving us the resilient retry mechanism we need. We’ll ignore everything else to focus on service worker syncing for this example.

Setting up a service worker sync

Let’s dive right into the code. We’ll see how to manage the whole lifecycle of a PWA application that has an operation that requires syncing. For that, we need a full-stack setup. In this setup, a request to create a new TODO is made, and if the network is good, it is sent to the server and saved, but if the network is down, the request is retried in the background whenever the network is available. 

We’ll use Node and Express to serve the front end and handle the API request. 

To begin we need Node/npm installed. Assuming that’s set, we can start a new app with: the following call:

$ npm init -y

That call creates the scaffolding for a new application. Next, we add the express dependency:

$ npm install express

Now we can create a simple Express server that will serve some static files. Next, we’ll create a new index.js file in the root directory and put the following in there:

const express = require('express');
const path = require('path');  // Required for serving static files

const app = express();
const port = process.env.PORT || 3000;  // default to 3000

app.use(express.static(path.join(__dirname, 'public')));

// Serve the main HTML file for all unmatched routes (catch-all)
app.get('*', (req, res) => {
  res.sendFile(path.join(__dirname, 'public', 'index.html'));
});

app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

If you run the app, it will serve whatever is in /public. To make it simple to run, open the package.json file the NPM created for us and add a start script like so:

"scripts": {
    "start": "node index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  }

From the command line, you can run the app with:

$ npm run start

This application won’t do anything yet. Add a new index.html file to the /public directory:

  
  
  


  
My To-Do List
  
  Add
  

  

Now, if you visit localhost:3000, you’ll get the basic HTML layout with a title, input box, and button. Notice that the button, when clicked, will grab the value of the new-task input and pass it to the addTask() function. 

The main script

addTask() is provided by script.js. You can paste-in the contents of that file if you are following along:

if ('serviceWorker' in navigator) { // 1
  window.addEventListener('load', () => { // 2
    navigator.serviceWorker.register('sw.js') // 3
      .then(registration => { // 4
        console.log('Service Worker registered', registration); // 5
      })
      .catch(err => console.error('Service Worker registration failed', err)); // 6
  });
}

const taskChannel = new BroadcastChannel('task-channel'); // 7

function addTask(task) { // 8
  taskChannel.postMessage({ type: 'add-task', data: task }); // 9
}

Notice that we are not actually concerned with displaying the to-do’s; we are exclusively following the process of submitting it to the back end.

I’ve put comments with numbers in the code. Let’s walk through them here:

1. Checks for the existence of serviceWorker on navigator. It may not be present if it’s not a secure context.
2. If the serviceWorker is present, add a callback to the load observer so it will react when the page is loaded.
3. Use the register method to request that the sw.js file be loaded as a service worker. (We’ll walk through sw.js next.)
4. After the sw.js file is loaded, we get a callback with the registration object. 
5. The registration object can be used to perform various tasks, but for our needs, we just log the success.
6. We also log any errors using the catch() promise callback.
7. We create a BroadcastChannel named “task-channel”. This is a simple way to communicate events to the service worker that will be running based on the code in sw.js.
8. The addTask() function itself, called by the HTML file.
9. We send a message on the task-channel broadcast, and set the type to “add-task” and the data field to the task itself.

In this example, we are ignoring how the UI itself would handle the task creation. We could use a few different approaches including an optimistic one, wherein we put the task into the UI list and then attempt syncing with the back end. Alternatively, we could attempt the back-end sync and then, once successful, send a message to the UI to add the task. (The BroadcastChannel makes it easy to send messages in either direction, from the main thread to the service worker or vice versa.)

Running on HTTPS

We’ve noted that you have to be running on HTTPS (not HTTP) for serviceWorker to exist on navigator. This is a security constraint. To get an HTTPS connection with the minimum of effort, I used ngrok. This handy command-line tool lets you expose your local environment to the world with no configuration and it includes HTTPS. For example, if you run the sample app ($ npm run start) and then type $ ngrok http 3000, it will spawn a tunnel and display the HTTP and HTTPS endpoints you can put into the browser address bar. For example:

Forwarding                    https://8041-35-223-70-178.ngrok-free.app -> http://localhost:3000

Now you can visit https://8041-35-223-70-178.ngrok-free.app, and the app will be served over HTTPS. 

Interacting with the service worker

The sw.js is used to interact with the actual service worker. Remember, we told the browser to load this file with serviceWorker. 

You’ll notice we are using IndexedDB in this code. The reason is that the browser is free to destroy and create service worker contexts as needed to handle events, so we have no guarantee that the same context will be used to handle the broadcast event and the sync event. So, that eliminates local variables as a reliable medium. LocalStorage is not available in service workers. It might be possible to use CacheStorage (which is available in both main and service threads), but that is really designed for caching request responses.

That leaves IndexedDB, which lives across instances of the service worker. We just use it to push the new task in when the add-task broadcast happens, and then pull it out when the sync event occurs.

Here are the contents of sw.js. We’ll walk through this code after you’ve had a look.

const URL = "https://8014-35-223-70-178.ngrok-free.app/"; // 1
const taskChannel = new BroadcastChannel('task-channel'); // 2
taskChannel.onmessage = event => { // 3
  persistTask(event.data.data); // 4
  registration.sync.register('task-sync'); // 5
};

let db = null; // 6
let request = indexedDB.open("TaskDB", 1); // 7
request.onupgradeneeded = function(event) { // 8
  db = event.target.result; // 9
  if (!db.objectStoreNames.contains("tasks")) { // 10
    let tasksObjectStore = db.createObjectStore("tasks", { autoIncrement: true }); // 11
  }
};
request.onsuccess = function(event) { db = event.target.result; }; // 12
request.onerror = function(event) { console.log("Error in db: " + event); }; // 13

persistTask = function(task){ // 14
  let transaction = db.transaction("tasks", "readwrite");
  let tasksObjectStore = transaction.objectStore("tasks");
  let addRequest = tasksObjectStore.add(task);
  addRequest.onsuccess = function(event){ console.log("Task added to DB"); };
  addRequest.onerror = function(event) { console.log(“Error: “ + event); };
}
self.addEventListener('sync', async function(event) { // 15
  if (event.tag == 'task-sync') {
    event.waitUntil(new Promise((res, rej) => { // 16
      let transaction = db.transaction("tasks", "readwrite");
      let tasksObjectStore = transaction.objectStore("tasks");
      let cursorRequest = tasksObjectStore.openCursor();
      cursorRequest.onsuccess = function(event) { // 17
        let cursor = event.target.result;
        if (cursor) {
          let task = cursor.value; // 18
          fetch(URL + 'todos/add', // a
            { method: 'POST', 
              headers: { 'Content-Type': 'application/json' },
              body: JSON.stringify({ "task" : task }) 
            }).then((serverResponse) => {
              console.log("Task saved to backend.");
              deleteTasks(); // b
              res(); // b
            }).catch((err) => {
              console.log("ERROR: " + err);
              rej(); //c
            })
          }
        } 
    }))
  }
})
async function deleteTasks() { // 19
  const transaction = db.transaction("tasks", "readwrite");
  const tasksObjectStore = transaction.objectStore("tasks");
  tasksObjectStore.clear();
  await transaction.complete;
}

Now let’s talk about what is happening in this code.

1. We need to route our requests through the same secure tunnel we created with ngrok, so we save the URL here.
2. Create the broadcast channel with the same name so we can listen for messages.
3. Here, we are watching for task-channel message events. In responding to these events, we do two things:
4. Call persistTask() to save the new task to IndexedDB.
5. Register a new sync event. This is what invokes the special capability for retrying requests intelligently. The sync handler allows us to specify a promise that it will retry when the network is available, and implements a back off strategy and give-up conditions.
6. With that done, we create a reference for our database object.
7. Obtain a “request” for the handle on our database. Everything on IndexedDB is handled asynchronously. (For an excellent overview of IndexedDB, I recommend this series.)
8. The onupgradeneeded event fires if we are accessing a new or up-versioned database. 
9. Inside onupgradeneeded, we get a handle on the database itself, with our global db object.
10. If the tasks collection is not present, we create the tasks collection.
11. If the database was successfully created, we save it to our db object.
12. Log the error if the database creation failed.
13. The persistTask() function called by the add-task broadcast event (4). This simply puts the new task value in the tasks collection.
14. Our sync event. This is called by the broadcast event (5). We check for the event.tag field being task-sync so we know it’s our task-syncing event.
15. event.waitUntil() allows us to tell the serviceWorker that we are not done until the Promise inside it completes. Because we are in a sync event, this has special meaning. In particular, if our Promise fails, the syncing algorithm will keep trying. Also, remember that if the network is unavailable, it will wait until it becomes available.
    1. We define a new Promise, and within it we begin by opening a connection to the database.
16. Within the database onsuccess callback, we obtain a cursor and use it to grab the task we saved. (We are leveraging our wrapping Promise to deal with nested asynchronous calls.)
17. Now we have a variable with the value of our broadcast task in it. With that in hand:
    1. We issue a new fetch request to our expressJS /todos/add endpoint.
    2. Notice that if the request succeeds, we delete the task from the database and call res() to resolve our outer promise.
    3. If the request fails, we call rej(). This will reject the containing promise, letting the Sync API know the request must be retried.
18. The deleteTasks() helper method deletes all the tasks in the database. (This is a simplified example that assumes one tasks creation at a time.)

Clearly, there is a lot to this, but the reward is being able to effortlessly retry requests in the background whenever our network is spotty. Remember, we are getting this in the browser, across all kinds of devices, mobile and otherwise.

Testing the PWA example

If you run the PWA now and create a to-do, it’ll be sent to the back end and saved. The interesting test is to open devtools (F12) and disable the network. You can find the “Offline” option in the “throttling” menu of the network tab like so:

Now, in offline mode, if you add a task and click Add, nothing will happen. The Sync API is watching the network status.

If you then re-enable the network in the network tab, you will see the request being issued to the back end.

Conclusion

Progressive web applications are not simple, but they deliver something extremely valuable: cross-device, native-like functionality within the browser. In this tutorial, you got hands-on, code-first familiarity with several important components of a PWA: service workers, events, syncing, and IndexedDB.

The code for this example can be found here.

More by Matthew Tyson:

• HTMX for Java with Spring Boot and Thymeleaf
• Stream gatherers: A new way to manipulate Java streams
• Intro to multithreaded JavaScript

Google and online educator Udacity have teamed up to offer a free online course to teach developers and designers how to use the Google AI Studio developer tool and Google’s Gemini API AI model. Participants will be taught how to build generative AI capabilities into applications, websites, products, operations, and services.

Entitled “Gemini API by Google,” the Udacity course was announced July 9 and developed in collaboration with Google and Machine Learning @ Berkeley. The course will take fewer than two hours to complete. Udacity recommends that learners already know basic Python skills. The course agenda includes using the Gemini API effectively and using core components such as making calls, configuring parameters, sending prompts, and receiving results. Students will learn fundamental concepts behind LLMs (large language models) and Gemini models, the differences among common prompting techniques such as zero-shot, few-shot, and chain-of-thought prompting, and how to use Google AI Studio for designing prompts.

Generative AI has become the most sought-after capability across sectors, Udacity CEO Kai Roemmelt said. Using the Gemini API, developers can integrate the largest and most capable AI model from Google into their apps, regardless of interface, platform, or industry, Roemmelt said. This makes acquiring practical knowledge relating to integrating AI into new and existing web and mobile applications with Gemini a highly marketable skill, he said.

A class-action lawsuit that challenged the legality of GitHub’s use of code samples to train its AI-driven coding assistant, Github Copilot, has for the most part been dismissed by a US District Court judge in San Francisco.

The lawsuit, first filed in Nov. 2022, claimed that GitHub’s training of the Copilot AI on public GitHub code repositories violated the rights of the “vast number of creators” who posted code under open-source licenses on GitHub.

The complaint alleged that “Copilot ignores, violates, and removes the Licenses offered by thousands — possibly millions — of software developers, thereby accomplishing software piracy on an unprecedented scale.”

Also named in the suit was GitHub owner Microsoft and OpenAI, the co-developer of Copilot.

The suit was filed by Matthew Butterick, a lawyer and open-source programmer, in conjunction with Joseph Saveri Law Firm. In a document providing background on the case the law firm said it “represents the first major step in the battle against intellectual-property violations in the tech industry arising from artificial intelligence systems,” and went on to argue that, “Despite Microsoft’s protestations to the contrary, it does not have the right to treat source code offered under an open-source license as if it were in the public domain.”

GitHub Copilot is a tool that suggests code snippets and functions in real time, right from the developer’s code editor. It is said to have been trained on billions of lines of code, a claim that, far from inspiring confidence, immediately drew the ire of the Free Software Foundation, which cried foul on Copilot’s use of freely licensed software.

In a decision first announced on June 24, but only unsealed and made public on July 5, California Northern District judge Jon S. Tigar wrote that “In sum, plaintiff’s claims do not support the remedy they seek. Plaintiffs have failed to establish, as a matter of law, that restitution for any unjust enrichment is available as a measure of plaintiffs’ damages for their breach of contract claims.”

Judge Tigar went on to state that “court dismisses plaintiffs’ section 1202(b) claim, this time with prejudice. The Court declines to dismiss plaintiffs’ claim for breach of contract of open-source license violations against all defendants. Finally, the court dismisses plaintiffs’ request for monetary relief in the form of unjust enrichment, as well as plaintiffs’ request for punitive damages.”

Lately, I’ve been covering the overengineering and overprovisioning of resources in support of AI, both in the cloud and not in the cloud. AI architects are putting high-powered processors, such as GPUs, on their AI platform shopping lists, not stopping to consider if they will return business value.

I’ve found myself in more than a few heated disagreements with other IT architects about using these resources for AI. There seem to be two camps forming: First, the camp that believes AI will need all the processing and storage power that we can afford now. They beef up the systems ahead of need. Money and carbon footprint don’t need to be considered.

Second, the camp that’s configuring a minimum viable platform (MVP) that can support the core functions of AI systems. The idea is to keep it as lean as possible and use lower-powered platforms, such as edge and mobile computing.

Who’s right?

The trend to go small

As we trek into the latter half of 2024, it’s clear that a paradigm shift is reshaping the landscape: AI is downsizing its hardware appetite. In an era where digital efficiency reigns supreme, today’s cutting-edge AI technologies are shedding bulky resource dependencies and morphing into lean and agile models.

The traditional narrative for AI development has long been one of high demand. However, the narrative is undergoing a dramatic rewrite, largely thanks to new advancements in AI algorithms and hardware design.

The development of more efficient neural network architectures, such as transformers and lossless compression algorithms, has played a pivotal role. These innovations have downsized the data required for training and inference, thus reducing the computational effort. This trend is significantly lowering the barrier to entry and offering much smaller and more affordable platforms, in or out of the cloud.

More efficient and cost-effective

A critical milestone in this evolution was the advent of specialized AI processors, such as tensor processing units (TPUs) and neural processing units (NPUs). Unlike their generic counterparts, such as GPUs, these processors are optimized for the specific demands of AI workloads. They perform more computations per watt, translating to better performance with lesser energy consumption.

We’re likely to see more efficient and cost-effective processors as the billions of dollars flowing into the processor space create better options than hugely expensive GPUs. More minor processing power and thus device-centered AI is where AI systems are heading. It is not as focused on the major large language models (LLMs) that define the generative AI space.

As I’ve mentioned many times, businesses won’t be building LLMs for their AI implementations; for the next few years, they will be smaller models and tactical use cases. That is where the investments need to be made.

On the software front, frameworks like TensorFlow Lite and ONNX enable developers to build high-efficiency AI models that scale down appropriately for edge devices. The focus around AI systems development seems to be shifting here; businesses are finding more benefits in building lighter-weight AI systems that can provide more business value with less investment.

One must recognize the magic woven by edge computing. This once-futuristic notion is now very much a reality, driving data processing towards the network’s periphery. By harnessing edge devices—ranging from IoT gadgets to smartphones—AI workloads are becoming more distributed and decentralized. This alleviates bandwidth congestion and latency issues and supports a trend towards minimalistic yet powerful processors.

Bigger isn’t always better

Fast forward to 2024, and our reliance on massive data infrastructures is steadily evaporating. Complex AI systems seamlessly run on devices that fit in the palm of your hand. These are not LLMs and don’t pretend to be LLMs, but they can reach out to LLMs when needed and can process 95% of what they need to process on the device. This is the idea behind the yet-to-be-deployed Apple Intelligence features that will be delivered in the next version of IOS. Of course, this may intended to drive iPhone upgrades rather than drive more efficiency to AI.

Consider the breakthrough of embedded intelligence in smartphones. Processors like Apple’s A16 Bionic and Qualcomm’s Snapdragon 8 Gen 2 have integrated AI capabilities, spurring a revolution in mobile computing. These chips have machine learning accelerators that manage tasks like real-time language translation, augmented reality-based gaming, and sophisticated photo processing.

Moreover, AI models can now be “trimmed down” without losing efficacy. Model quantization, pruning, and knowledge distillation allow designers to pare down models and streamline them for deployment in resource-limited environments.

This pushes back on the current narrative. Most larger consulting and technology companies are driving partnerships with processor providers. That will be a bell that is hard to unring. Are we concerned when decisions are based more on business obligations than business requirements, and we keep attempting to stuff expensive and power-hungry GPUs into clouds and data centers? We’re expecting enterprises to create and operate huge AI systems that burn twice as much power and cost twice as much money as they currently do. That is a scary outcome.

This does not mean that we’re going to limit the power that AI needs. We should be concerned with rightsizing our resources and using AI more efficiently. We’re not in a race to see who can build the biggest, most powerful system. It’s about adding business value by taking a minimalist approach to this technology.

As agents using artificial intelligence have wormed their way into the mainstream for everything from customer service to fixing software code, it’s increasingly important to determine which are the best for a given application, and the criteria to consider when selecting an agent besides its functionality. And that’s where benchmarking comes in.

Benchmarks don’t reflect real-world applications

However, a new research paper, AI Agents That Matter, points out that current agent evaluation and benchmarking processes contain a number of shortcomings that hinder their usefulness in real-world applications. The authors, five Princeton University researchers, note that those shortcomings encourage development of agents that do well in benchmarks, but not in practice, and propose ways to address them.

“The North Star of this field is to build assistants like Siri or Alexa and get them to actually work — handle complex tasks, accurately interpret users’ requests, and perform reliably,” said a blog post about the paper by two of its authors, Sayash Kapoor and Arvind Narayanan. “But this is far from a reality, and even the research direction is fairly new.”

This, the paper said, makes it hard to distinguish genuine advances from hype. And agents are sufficiently different from language models that benchmarking practices need to be rethought.

What is an AI agent?

The definition of agent in traditional AI is that of an entity that perceives and acts upon its environment, but in the era of large language models (LLMs), it’s more complex. There, the researchers view it as a spectrum of “agentic” factors rather than a single thing.

They said that three clusters of properties make an AI system agentic:

Environment and goals – in a more complex environment, more AI systems are agentic, as are systems that pursue complex goals without instruction.

User interface and supervision – AI systems that act autonomously or accept natural language input are more agentic, especially those requiring less user supervision

System design – Systems that use tools such as web search, or planning (such as decomposing goals into subgoals), or whose flow control is driven by an LLM are more agentic.

Key findings

Five key findings came out of the research, all supported by case studies:

AI agent evaluations must be cost-controlled – Since calling the models underlying most AI agents repeatedly (at an additional cost per call) can increase accuracy, researchers can be tempted to build extremely expensive agents so they can claim top spot in accuracy. But the paper described three simple baseline agents developed by the authors that outperform many of the complex architectures at much lower cost.

Jointly optimizing accuracy and cost can yield better agent design – Two factors determine the total cost of running an agent: the one-time costs involved in optimizing the agent for a task, and the variable costs incurred each time it is run. The authors show that by spending more on the initial optimization, the variable costs can be reduced while still maintaining accuracy.

Analyst Bill Wong, AI research fellow at Info-Tech Research Group, agrees. “The focus on accuracy is a natural characteristic to draw attention to when comparing LLMs,” he said. “And suggesting that including cost optimization gives a more complete picture of a model’s performance is reasonable, just as TPC-based database benchmarks attempted to provide, which was a performance metric weighted with the resources or costs involved to deliver a given performance metric.”

Model developers and downstream developers have distinct benchmarking needs – Researchers and those who develop models have different benchmarking needs to those downstream developers who are choosing an AI to use their applications. Model developers and researchers don’t usually consider cost during their evaluations, while for downstream developers, cost is a key factor.

“There are several hurdles to cost evaluation,” the paper noted. “Different providers can charge different amounts for the same model, the cost of an API call might change overnight, and cost might vary based on model developer decisions, such as whether bulk API calls are charged differently.”

The authors suggest that making the evaluation results customizable by using mechanisms to adjust the cost of running models, such as providing users the option to adjust the cost of input and output tokens for their provider of choice, will help them recalculate the trade-off between cost and accuracy. For downstream evaluations of agents, there should be input/output token counts in addition to dollar costs, so that anyone looking at the evaluation in the future can recalculate the cost using current prices and decide whether the agent is still a good choice.

Agent benchmarks enable shortcuts – Benchmarks are only useful if they reflect real-world accuracy, the report noted. For example, shortcuts such as overfitting, in which a model is so closely tailored to its training data that it can’t make accurate predictions or conclusions from any data other than the training data, result in benchmarks whose accuracy doesn’t translate to the real world.

“This is a much more serious problem than LLM training data contamination, as knowledge of test samples can be directly programmed into the agent as opposed to merely being exposed to them during training,” the report said.

Agent evaluations lack standardization and reproducibility – The paper pointed out that, without reproducible agent evaluations, it is difficult to tell whether there have been genuine improvements, and this may mislead downstream developers when selecting agents for their applications.

However, as Kapoor and Narayanan noted in their blog, they are cautiously optimistic that reproducibility in AI agent research will improve because there’s more sharing of code and data used in developing published papers. And, they added, “Another reason is that overoptimistic research quickly gets a reality check when products based on misleading evaluations end up flopping.”

The way of the future

Despite the lack of standards, Info-Tech’s Wong said, companies are still looking to use agents in their applications.

“I agree that there are no standards to measure the performance of agent-based AI applications,” he noted. “Despite that, organizations are claiming there are benefits to pursuing agent-based architectures to drive higher accuracy and lower costs and reliance on monolithic LLMs.”

The lack of standards and the focus on cost-based evaluations will likely continue, he said, because many organizations are looking at the value that generative AI-based solutions can bring. However, cost is one of many factors that should be considered. Organizations he has worked with rank factors such as skills required to use, ease of implementation and maintenance, and scalability higher than cost when evaluating solutions.

And, he said, “We are starting to see more organizations across various industries where sustainability has become an essential driver for the AI use cases they pursue.”

That makes agent-based AI the way of the future, because it uses smaller models, reducing energy consumption while preserving or even improving model performance.

More AI news:

• OpenSilver 3.0 previews AI-powered UI designer for .NET
• Amazon Bedrock updated with contextual grounding, RAG connectors
• Judge dismisses lawsuit over GitHub Copilot AI coding assistant

Rust has leaped to its highest position ever in the monthly Tiobe index of language popularity, scaling to the 13^th spot this month, with placement in the top 10 anticipated in an upcoming edition.

Previously, Rust has never gone higher than 17^th place in the Tiobe Programming Index. Tiobe CEO Paul Jansen attributed Rust’s ascent in the just-released July index to a February 2024 US White House report recommending Rust over C/C+, for safety reasons. He also credited the growing community and ecosystem support for the language. “Rust is finally moving up. After the tailwind of the US government, which recently announced to recommend moving from C/C++ to Rust for security reasons, things are going fast for Rust,” Jansen said. “The community is growing, including the number of third-party libraries and tools. In short, Rust is preparing itself for a top 10 position in the Tiobe index.”

Rust is billed as being fast and memory-safe, with no runtime or garbage collector. It can power performance-critical services, run on embedded devices, and integrate with other languages, proponents say. Still, C++ in particular has done well recently in climbing the index, even after the US White House report, rising to second place in June.

Software quality services vendor Tiobe’s monthly index bases ratings on the number of skilled engineers worldwide, courses, and third-party vendors pertaining to languages, examining websites such as Google, Amazon,  Wikipedia, and more than 20 others to determine the monthly numbers. The top 10 programming languages for July 2024 are as follows:

1. Python, with a rating of 16.12%
2. C++, 10.34%
3. C, 9.48%
4. Java, 8.59%
5. C#, 6.72%
6. JavaScript, 3.79%
7. Go (golang), 2.19%
8. Visual Basic, 2.08%
9. Fortran, 2.05%
10. SQL, 2.04%

In the rival Pypl Popularity of Programming Language index, which assesses how often languages are searched on in Google, the top 10 languages for July 2024 are as follows.

1. Python, with a 29.35% share
2. Java, 15.6%
3. JavaScript, 8.49%
4. C#, 6.9%
5. C/C++, 6.37%
6. R, 4.73%
7. PHP, 4.49%
8. TypeScript, 2.96%
9. Swift, 2.78%
10. Rust, 2.55%

More on Rust:

• Safety off: Programming in Rust with `unsafe`
• What’s new in Rust 1.76
• 6 Rust programming mistakes to watch out for

In a highly-anticipated federal ruling on July 3, US District Court Judge Ada Brown determined that the US Federal Trade Commission (FTC) did not have the authority to issue a nationwide ban of non-compete agreements. Although the judge’s decision was preliminary, employment lawyers watching the case agree that the FTC non-compete move is effectively dead.

Brown, of the US District Court for the Northern District of Texas, said that she would issue a final ruling on Aug. 30, the day before the FTC ban was slated to take effect. But based on the strong wording of her preliminary decision, there seemed little doubt that she would ultimately block the ban. 

The case will likely be appealed to the US Supreme Court, but that court’s recent decision setting aside the so-called Chevron deference makes observers doubt that the court won’t support the FTC block.

“Regardless of when the FTC appeals, the Supreme Court’s recent Loper Bright decision handed down on June 28, 2024 is expected to make an FTC appeal or ultimate success on the merits more challenging,” said an analysis of the case posted by the White & Case law firm. “Loper Bright overruled long-standing precedent under which courts afford deference to a federal agency’s interpretation of its own power, known as Chevron deference. Without Chevron deference now, the FTC’s legal arguments in support of its authority to promulgate the rule are on equal footing as the plaintiffs arguing that the FTC overstepped.”

The judge’s ruling elaborated on that.

“States have historically regulated non-competes through caselaw and statute. Texas courts have enforced reasonable covenants not to compete dating back at least to 1899,” Brown wrote. “No federal law broadly addresses the enforceability of non-competes.”

“The Court finds there is a substantial likelihood the rule is arbitrary and capricious because it is unreasonably overbroad without a reasonable explanation. It imposes a one-size-fits-all approach with no end date, which fails to establish a rational connection between the facts found and the choice made,” Brown said. 

“No state has ever enacted a non-compete rule as broad as the FTC’s NonCompete Rule. Further, the FTC’s evidence compares different states’ approaches to enforcing non-competes based on the specific factual situation — completely inapposite from the FTC imposing a categorical ban,” the decision said. “The Commission’s lack of evidence as to why they chose to impose such a sweeping prohibition — that prohibits entering or enforcing virtually all non-competes — instead of targeting specific, harmful non-competes, renders the rule arbitrary and capricious.”

Congress could act, but will it?

The judge stressed that she saw the proper avenue for such a restriction falling to Congress, not a government agency. Lawyers watching the case doubted that such legislation would be likely to happen.

“If congress had the desire to ban non-competes, they could have done so years ago,” said Texas lawyer Omar Ochoa, who specializes in employment law cases involving non-competes.

Another employment lawyer, Tom Spiggle of Alexandria, Virginia, agreed that congressional action is highly unlikely. “I don’t think there’s the political appetite of actually getting something passed. A lot of small businesses like these non-competes,” he said. 

About one in five US workers, or 30 million people, have signed non-compete agreements, according to the FTC. Such agreements typically prevent them from working for a competitor or launching a competing business of their own within a certain area and a certain time after leaving the original employer.

The political dynamics of legislatively dealing with non-competes make it unappealing to members of Congress. The move is favorable to employees — and there are more of them, so those are potential votes. But employers like non-competes and they can spend money via lobbying to help members get elected. In a choice of money versus votes, Capitol Hill favors money.

Other obstacles to non-competes

That said, the death of a federal ban on non-competes is only half of the story. Washington, DC, and about a half-dozen states including California, Rhode Island, and Minnesota have banned non-competes, whereas several other states — including Illinois, Massachusetts and Nevada — have sharply limited when they can be enforced, said Mark Goldstein, a partner in the New York law firm ReedSmith, where he specializes in employment law. 

“It’s a bit of a patchwork depending on where you are in the country,” Goldstein said, adding that states and courts differ on whether those state laws speak to the state where the employee works or where the company is based.

More developer news:

• OpenSilver 3.0 previews AI-powered UI designer for .NET
• Microsoft moves forward with C# 13, offering overload resolution
• Amazon Bedrock updated with contextual grounding, RAG connectors
• Google, Udacity offer free course on Gemini API
• Judge dismisses lawsuit over GitHub Copilot AI coding assistant

In 2007, some of the programmers at Google looked at their options for writing software and didn’t like what they saw. They needed to manage millions of lines of code that would be constantly storing and shipping data for the world wide web. The code would juggle thousands or maybe millions of connections on networks throughout the globe. The data paths were full of challenges from race cases and concurrency.

The existing programming languages weren’t much help. They were built for games or managing desktops, or many of the other common tasks from a world before the web browser. Their rough edges and failure modes drove coders at Google crazy enough to start asking if there might be a better way. Was there something that could handle the I/O chores in just a few lines with all of the safety and security that Google needed?

The answer to that question was no. And so they created Golang, a simple language that is superficially similar to C or Java. The public versions started appearing in 2009 and the first 1.0 version shipped in 2012. Today, Google continues to invest in the language, and the latest stable version as of this writing is 1.22.5.

Inside Google, the Go language powers large blocks of the infrastructure, and it’s also been embraced by many programmers outside of Google. The language recently climbed into the top 10 of the Tiobe index. It is sitting in the eighth position as of this writing.

All of that outrageous fortune has delivered plenty of plaudits—but some slings and arrows, too. In many cases, the same features bring both disparagement and praise. What some developers love about Go, others hate just as much. 

8 reasons developers love or hate the Go language

• It’s easy to learn
• It doesn’t play favorites
• The C-based syntax
• (Too) many rules
• Extra error handling
• The standard library
• The executable size
• Big daddy Google

Go is easy to learn

Go’s designers deliberately created a language that would be quick to learn, because it didn’t have too many complex features or idiosyncrasies. Instead of adding bells and whistles to Go, they chose to strip the language down, close to the bare minimum needed to accomplish their work at Google. That meant saying “no” to good ideas and focusing on an idealized vision of what programmers should need.

Why some love it: A simpler language is easier for new programmers and team members to learn. There are fewer features or constructs to master and that means skilled programmers can pick up the language in a day. Staffing projects is easier because old dogs can be taught Go’s new tricks quickly. Not only that, but the code is often easier to read, if only because there are no strange or arcane structures that appear in odd places.

Why some hate it: Simple isn’t necessarily bad, it’s just what was left out. Would a witch choose an abridged spell book? Would a quarterback choose a playbook with just a few plays? Some coders feel that programming with Go is like coding with one hand tied behind their back. The language lacks all the cleverness other language designers have delivered to the world, and that’s a high price to pay.

Go doesn’t play favorites

The original developers wanted to create a small language, and they did so at the expense of many favorite features found in other languages. Go is a streamlined language. It does what you need but eschews the bells and whistles.

Why some love it: Many developers sing the praises of Go’s simplicity. Go doesn’t require them to gain or maintain expertise in dozens of features to be proficient. If they read through some code, they won’t be discovering constructs they’ve never seen before.

Why some hate it: Everyone has a few favorite features and tricks, but the odds are that Go doesn’t offer them. Developers sometimes complain that they could accomplish the same thing they could do in Go with just one line of COBOL or Java, or some other favorite language.

C-based syntax

Go’s creators have deep roots in the world of Unix, and it shows. The syntax is quite familiar to anyone who’s used C or any of the languages like Java or C# that borrowed from C. Go’s curly brackets and typing will be comfortable for this crew. The design team did remove some of the rough edges from traditional C, and simplify some of the details so it looks and feels more modern, but for the most part, Golang falls squarely in the tradition that began with C.

Why some love it: Programmers who grew up with the C style will intuitively understand much of Go. They’ll be able to learn the syntax very quickly and they can spend their time learning the few ways that Go cleaned up some of the annoying corners of C or Java. What’s not to love?

Why some hate it: In many ways, Python was designed to be the antithesis of C. There are no curly punctuation marks to delineate blocks of code and the typing is deliberately dynamic. Anyone who loves the Python approach will find plenty to dislike about Go. From this perspective, programming with Go feels like a step or three backward.

Go has (too) many rules

From the beginning, Go’s creators wanted to define not just the syntax but also much of the style and usage patterns of the language. They produced, for instance, a standard formatting library to discourage battles over the right way to indent Go code. They’ve curated lists of idioms and encouraged programmers to use the best ones. They’ve also explicitly banned some habits that are merely frowned upon by other languages, like unused variables or cyclic dependencies. Go’s build process is programmed to halt when it discovers these elements in the codebase.

Why some love it: Go’s strongly idiomatic rules ensure code will be easier to grok. Teams will have fewer fights over style because there are fewer options or reasons to evolve their own personal style.

Why some hate it: All these extra rules and conventions feel like a straightjacket. Why is an unused variable a problem? If the compiler can detect it, the compiler can strip it out without bugging me. Is it so bad for programmers to have a bit of freedom in their life?

Go has extra error handling

Much of modern programming includes building in extra paths for code to take when errors appear. The code runs normally until something goes wrong. When an error happens, it must recover. It might just pause a bit, or it could completely give up. Building automated systems requires the introspection to know when things are working or failing.

Go takes a novel approach by encouraging programmers to write two pathways into the same function. Good Go code spells out both the normal approach and what should happen when an error arises. Go programmers like to say that “errors are regular values” because they’re part of the same code. There’s even a separate type system for errors that allows programmers to create more specific forms of errors, then spell out how they should be handled.

Why some love it: The Go approach acknowledges that errors exist and encourages the programmer to make a plan for handling them. This encourages programmers to plan ahead and build in the kind of resilience that makes for better software.

Why some hate it: Unnecessary error handling makes Go functions fatter and harder to understand. Often, every function in a deep chain must include similar code that’s doing more or less the same thing with the same error. Other languages like Java or Python encourage programmers to “throw” the errors up the chain to a specific block that will “catch” them, which can result in cleaner code.

The standard library

It’s not just Go’s syntax that’s designed to be a simple but powerful standard that unites teams. The standard library includes support for many of the major tasks that are common for web-based microservices programming. The input and output routines begin with low-level network packet juggling and handle all the tasks of increasing complexity like handling the HTTPS protocol or decoding JSON data. Setting up a full web server only takes a few lines of code because it’s all included in the “net/http” part of the library.

Why some love it: When many of the standard features are handled by the default library, most code is easier to read because no one is writing their own version or arguing about which package or third-party library is better.

Why some hate it: It’s hard to complain about such a nice pile of code, but curmudgeons like to point out that competition is a good indicator of demand and innovation. The fact that some languages support multiple packages tackling the same task indicates a deep interest and a rich culture.

The executable size

One of the goals for the Go team was to make it easy to deploy Go programs and they accomplished this by bundling together everything into one executable. Everything is ready to run because all of Go’s library routines are included in the standard build.

Over the years, developers who don’t like executables that are dozens or even hundreds of megabytes in size have found ways to strip out the unnecessary parts. It’s a bit more work to set the right flags and include extra steps in the build process, but it can be done.

Why some love it: Disk space is cheap. Deploying code in strange locations can be a nightmare when different versions of libraries are installed. Go developers save us huge amounts of time by just building one executable file.

Why some hate it: How many copies of the Go libraries are on my disk? If I have 100 programs, that means 100 copies. At some point, efficiency is a consideration. Yes, disk space is cheaper than ever, but memory bandwidth and caching continue to be primary issues for execution speed.

Big daddy Google

Golang was developed at Google and the big company continues to be one of its major supporters, shipping the compiler and much of the toolchain. There is some support from outside Google like GopherJS, a transpiler that turns Go into JavaScript. But for the most part, much of the Go development effort comes directly from inside Google.

Why some love it: A great deal of the work today involves writing code for the constellations of servers and clients, the same kind that is such a big part of Google’s workload. If Go is good for Google, it’s also good for those of us who are working in the same way. If Google engineers built something they would love, anyone with similar projects is going to love it just as much. 

Why some hate it: It’s not that people don’t like Google per se, it’s just that programmers distrust centralized authorities. Problems like vendor lockin and lack of control are serious issues for anyone trying to curate a tech stack. All of Google’s generosity still leaves programmers leery, especially when other language choices have large, open source communities built around them.

Well, that didn’t take long. After all the “this time it’s different” comments about artificial intelligence (We see you, John Chambers!), enterprises are coming to grips with reality. AI isn’t going to take your job. It’s not going to write your code. It’s not going to write all your marketing copy (not unless you’re prepared to hire back the humans to fix it). And, no, it’s nowhere near artificial general intelligence (AGI) and won’t be anytime soon. Possibly never.

That’s right: We’ve entered AI’s trough of disillusionment, when we collectively stop believing the singularity is just around the corner and start finding ways AI augments, not replaces, humans. For those new to the industry, and hence new to our collective tendency to overhype pretty much everything—blockchain, web3 (remember that?), serverless—this isn’t cause for alarm. AI will have its place; it simply won’t be every place.

So many foolish hopes

AI, whether generative AI, machine learning, deep learning, or you name it, was never going to be able to sustain the immense expectations we’ve foisted upon it. I suspect part of the reason we’ve let it run so far for so long is that it felt beyond our ability to understand. It was this magical thing, black-box algorithms that ingest prompts and create crazy-realistic images or text that sounds thoughtful and intelligent. And why not? The major large language models (LLMs) have all been trained on gazillions of examples of other people being thoughtful and intelligent, and tools like ChatGPT mimic back what they’ve “learned.”

The problem, however, is that LLMs don’t actually learn anything. They can’t reason. They’re great at pattern matching but not at extrapolating from past training data to future problems, as a recent IEEE study found. Software development has been one of the brightest spots for genAI tools, but perhaps not quite to the extent we’ve hoped. For example, GPT-3.5 lacked training data after 2021. As such, it struggled with easy coding problems on LeetCode that required information that came out after 2021. The study found that its success rate for easy problems plummeted from 89% to 52% and its ability to create code for hard coding problems tanked from 40% to 0.66%.

According to Michelle Hampson, the finding shows that ChatGPT “lacks the critical thinking skills of a human and can only address problems it has previously encountered.” Tim Klapdor less graciously states, “ChatGPT didn’t learn the topic, it did no research, it did no validation, and it contributed no novel thoughts, ideas, or concepts. ChatGPT just colonized all of that data … and now it can copy/paste that information to you in a timely manner because it’s spending $US700K a day on compute.” Ouch.

This doesn’t mean genAI is useless for software development or other areas, but it does mean we need to reset our expectations and approach.

We still haven’t learned

This letdown isn’t just an AI thing. We go through this process of inflated expectations and disillusionment with pretty much every shiny new technology. Even something as settled as cloud keeps getting kicked around. My InfoWorld colleague, David Linthicum, recently ripped into cloud computing, arguing that “the anticipated productivity gains and cost savings have not materialized, for the most part.” I think he’s overstating his case, but it’s hard to fault him, given how much we (myself included) sold cloud as the solution for pretty much every IT problem.

Linthicum has also taken serverless to task. “Serverless technology will continue to fade into the background due to the rise of other cloud computing paradigms, such as edge computing and microclouds,” he says. Why? Because these “introduced more nuanced solutions to the market with tailored approaches that cater to specific business needs rather than the one-size-fits-all of serverless computing.” I once suggested that serverless might displace Kubernetes and containers. I was wrong. Linthicum’s more measured approach feels correct because it follows what always seems to happen with big new trends: They don’t completely crater, they just stop pretending to solve all of our problems and instead get embraced for modest but still important applications.

This is where we’re heading with AI. I’m already seeing companies fail when they treat genAI as the answer to everything, but they are succeeding by using genAI as a complementary solution to some things. It’s not time to dump AI. Far from it. Rather, it’s time to become thoughtful about how and where to use it. Then, like so many trends before (open source, cloud, mobile, etc., etc.,) it will become a critical complement to how we work, rather than the only way we work.