Programming Languages Release Notes

Latest Programming Languages Updates

• Nov 11, 2026

  • Date parsed from source:
    Nov 11, 2026
  • First seen by Releasebot:
    Nov 11, 2026
  

  Scala

  SCALA 3.10.1 IS NOW AVAILABLE!

  Scala releases version 3.10.1 with JDK 28 support, an upgraded Scala CLI, experimental method block end markers, and improvements across compiler warnings, the REPL, and tooling.

  RELEASE

  Scala 3.10.1, the first patch release in the Scala 3.10 series, is now available.

  Release highlights

  JDK 28 support (#27347)

  The compiler now supports JDK 28, including target version 28 for -release and -java-output-version. The target version cannot exceed the JDK version running the compiler. ASM has also been updated to 9.11.1 (#27363), enabling support for JDK 28 class files.

  The compiler now warns when synchronized is called on an instance of a Java value-based class (#27128). JDK 28 rejects such calls. Use a dedicated lock object instead.

  Upgrade to Scala CLI 1.18.0 (#27255)

  The bundled Scala CLI has been upgraded from 1.17.1 to 1.18.0. Highlights include:

  • The JVM launcher no longer starts on JDK 11–16 by downloading JDK 17 and relaunching. Start it on Java 17 or newer. Your code can still be compiled and run on older JVMs, for example with --jvm 8 or --jvm 11.
  • scala fix removes deprecated comma separators from //> using directives.
  • Java snippets, Java source read from standard input, and Java blocks in Markdown now support enums, records, package-private classes, and JEP 512 compact source files.

  See the Scala CLI 1.18.0 release notes for the full list of changes.

  Experimental SIP-77: method block end markers (#24251)

  Method block end markers make it easier to see where nested argument blocks end. Experimental SIP-77 lets you close an argument block introduced by : with a named end marker. The marker must name the method as it is written at the call site, so a mismatched name is an error.

  This feature is experimental and may change or be removed depending on the SIP Committee’s decision. We welcome feedback from users who try it. Enable it with import scala.language.experimental.methodBlockEndMarkers or -language:experimental.methodBlockEndMarkers.

  //> using scala 3.10.1
  //> using options -language:experimental.methodBlockEndMarkers
  
  def test(name: String)(body: => Unit): Unit =
    println(s"Running test: $name")
    body
  
  def repeat(times: Int)(body: => Unit): Unit =
    for _ <- 1 to times do body
  
  test("repeated greeting"):
    repeat(3):
      println("Hello!")
    end repeat
  end test
  

  For an implicit apply call, the end marker uses the name at the call site (Foo: … end Foo). For an explicit apply call, use end apply (Foo.apply: … end apply). See the reference for details on nested calls and invalid end markers.

  Other notable changes

  • -Wunreasonable-catch (also enabled by -Wall) warns when a catch clause catches Throwable, Error, or a subclass of Error, or uses a catch-all pattern such as case _. Catching Exception or NonFatal does not trigger this warning (#26794).
  • @deprecatedName accepts a Symbol as well as a string: @deprecatedName(Symbol("x")) (#27048).
  • @throws is rejected on members that are neither methods nor constructors (#27064).
  • The REPL accepts //> using resource and a :resource command. Adding dependencies with :jar or :dep no longer resets the REPL session (#27073, #27072).
  • Generic signatures for tuples with more than 22 elements are restored (#27120).
  • Under language.experimental.modularity, derives works for type classes with a Self member (#26719).
  • Pattern matching on a sealed Java class no longer fails when a member type cannot be loaded (#27069).

  The release also includes fixes for inlining and macros, the presentation compiler, Scaladoc, and the sbt compiler bridge.

  As always, the full changelog is available in the release notes on GitHub.

  Credits

  This release was made possible by the joint work of EPFL, VirtusLab and the Scala Center, together with the wider Scala community. Thank you to everyone who contributed.

  About VirtusLab

  VirtusLab is a software engineering company and a long-term core contributor to the Scala ecosystem. Its engineers help maintain the Scala 2 and Scala 3 compilers, manage their releases, and build key tools including Scala CLI, the Metals language server and the Open Community Build. Learn more at virtuslab.com/expertise/scala.

  About EPFL and the Scala Center

  Scala was created at EPFL in Lausanne, Switzerland, by Martin Odersky’s research group, LAMP. LAMP still leads much of the language’s design and compiler research. The Scala Center, a not-for-profit centre at EPFL, supports Scala’s open-source ecosystem, tooling and education. Learn more at scala.epfl.ch.

  Original source

  Show more
• Nov 11, 2026

  • Date parsed from source:
    Nov 11, 2026
  • First seen by Releasebot:
    Nov 11, 2026
  

  Go by Google

  Go 1.27.4 and Go 1.26.11

  Go releases minor updates with 12 security fixes, strengthening HTTP server stability and protecting cgo builds from code execution, unsafe linker inputs, and flag injection.

  Hello gophers,

  We have just released Go versions 1.27.4 and 1.26.11, minor point releases.

  These releases include 12 security fixes following the security policy:

  • net/http: HTTP/1 server crash due to MaxBytesReader header race

    For HTTP/1 servers, when MaxBytesReader's limit is exceeded, "Connection: close" header is automatically set without synchronization, which might race with another header being set explicitly in the server handler. As a result, an HTTP/1 server that utilizes MaxBytesReader or MaxBytesHandler can crash due to runtime panic if its handler reads the request body concurrently with writing the response header.

    Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.

    This is CVE-2026-97054 and Go issue https://go.dev/issue/82563.

  • cmd/go: unexpected code execution via --sysroot, -target, -isysroot, -Wl,-syslibroot, and -x cgo flags

    Building a malicious package that uses cgo could cause arbitrary code execution at build time through several compiler and linker flags permitted in "#cgo" directives.

    Specifically, "--sysroot" in GCC and Clang relocates compiler subprograms, spec files, and CRT startup objects to an attacker-controlled directory; "-target" in Clang falls back to executing target helper tools from the current working directory when not found in PATH; "-isysroot" and "-Wl,-syslibroot" can pass a regular file on disk to GNU ld.bfd, which interprets it as a positional linker script; and "-x" permitted specifying arbitrary compiler input languages beyond those supported by cgo.

    "--sysroot" and "-target" are now disallowed in "#cgo" flags, "-isysroot" and "-Wl,-syslibroot" are verified not to point to regular files, and "-x" is restricted to the C, C++, Objective-C, and assembler languages supported by cgo.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97033 and Go issue https://go.dev/issue/82577.

  • cmd/go: arbitrary command execution via GCC spec files in cgo linker search directories

    When using GCC, building a malicious package that uses cgo could cause arbitrary command execution at link time via untrusted GCC spec files ("specs" or "*.spec").

    When linking with "-fopenmp", "-fopenacc", or "-fsanitize=" in "#cgo LDFLAGS", GCC's built-in link spec evaluates "%:include(libgomp.spec)" or "%:include(libsanitizer.spec)" and searches for spec files in "-L" and sysroot directories (including subdirectories and multilib sibling directories such as "../lib64"), as well as the working directory when "-fopenmp" or "-fopenacc" is used or when "-fsanitize=" is combined with "-static" or "-static-lib*".

    The go command now rejects "-L", "-isysroot", and "-Wl,-syslibroot" directories (and the working and package directories when applicable) that contain GCC spec files, and disallows "@" and "-" prefixes in "-fsanitize=" compiler flag values.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97034 and Go issue https://go.dev/issue/82576.

  • cmd/go: unexpected code execution and arbitrary file write via Clang -gen-* and GCC -gnat* flags in cgo

    When using Clang or GCC, building a malicious package that uses cgo could cause unexpected code execution at build time or write files to arbitrary directories via "-gen-" or "-gnat" flags in "#cgo" directives.

    The "-g*" wildcard in the compiler and linker flag allowlists previously matched Clang's two-argument "-gen-cdb-fragment-path " flag and GCC's two-argument "-gnatO " flag, permitting compilation database fragments and sidecar output files to be written to arbitrary directories and desynchronizing flag argument parsing between the go command and the compiler driver so that subsequent arguments could be passed as unvalidated positional inputs to the linker.

    "-gen-" and "-gnat" flags are now disallowed in "#cgo" compiler and linker flags.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97035 and Go issue https://go.dev/issue/82575.

  • cmd/go: arbitrary code execution during build on darwin via "-l to_library" in cgo

    On Darwin, building a malicious package that uses cgo could cause arbitrary code execution when using the Apple linker due to passing "-l to_library " in a "#cgo LDFLAGS" directive.

    The Apple linker recombines the separated arguments "-l" and "to_library" into "-lto_library", which loads an arbitrary LTO plugin dynamic library at link time.

    The go command now disallows "-l" followed by "to_library" in "#cgo LDFLAGS", rejects "-lazy_library", "-lazy_framework", "-load_hidden", "-library", and "-library-path", and checks recombined "-l" arguments against disallowed linker flags and patterns.

    Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/) for reporting this issue.

    This is CVE-2026-97036 and Go issue https://go.dev/issue/82574.

  • cmd/go: linker script injection via split -Wl, flags and Darwin or symbol linker flags in cgo

    Building a malicious package that uses cgo could cause arbitrary code execution at link time by passing linker script files to the host linker via "#cgo LDFLAGS".

    Split "-Wl," flags that consume a following argument (such as "-Wl,-rpath", "-Wl,--just-symbols", and "-Wl,-undefined") previously accepted a bare second argument without a "-Wl," prefix, which the compiler driver passes directly to the linker as a positional input file. Additionally, when using GNU ld.bfd, flags such as "-framework", "-Wl,-framework", "-Wl,-undefined", "-Wl,--just-symbols", "-Wl,-R", "-Wl,-subsystem", and (on non-Darwin platforms) "-Wl,-sectcreate" could cause ld.bfd to interpret their arguments as linker scripts if they named a regular file on disk.

    The go command now requires a "-Wl," prefix on the second token of split "-Wl," flags (except "-Wl,-R"), verifies that these flags do not reference linker script files, and disallows bare "-Wl,--warn-backrefs-exclude".

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97037 and Go issue https://go.dev/issue/82573.

  • cmd/go: arbitrary code execution via crafted .syso files and cgo linker input files

    Building a malicious package containing ".syso" files or cgo linker inputs could inject arbitrary linker flags or execute arbitrary code at link time.

    Linker input files—including ".syso" files, direct object or library inputs in "#cgo LDFLAGS", and libraries in "-L" directories—were passed to the external linker without validating their format or checking for embedded linker options. Across platforms, this allowed executing GNU ld implicit linker scripts disguised as libraries or ".syso" files (or loaded via "-l:" or "-l" containing path separators), injecting unallowlisted linker flags via PE/COFF ".drectve" sections on Windows or Mach-O "LC_LINKER_OPTION" load commands on Darwin, or invoking LTO plugins via GCC or LLVM LTO intermediate representation sections in ELF, PE/COFF, or Mach-O objects.

    The go command now verifies that ".syso" files, direct linker inputs, and libraries in "-L" directories are valid binary objects or archives that do not contain unallowlisted ".drectve" directives, "LC_LINKER_OPTION" load commands, or LTO IR sections, and disallows "-l:" and ":", "=", or path separators in "-l" flags.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97038 and Go issue https://go.dev/issue/82572.

  • cmd/go: flag sanitization bypass via "#cgo pkg-config:" directives

    Building a malicious package that uses "#cgo pkg-config:" directives could load untrusted pkg-config ".pc" files or inject unvalidated compiler and linker flags.

    The pkg-config flag allowlist previously permitted "--with-path=" and "--personality=", allowed "--define-variable=" values beginning with "=" or "$" (which can rewrite paths in system ".pc" files into sysroot-prefixed "-L=" or "-L$SYSROOT" linker search paths), and allowed package arguments ending in ".pc" or containing path separators or "..", which caused pkg-config to load local ".pc" files directly from the package directory. In addition, flags returned by "pkg-config --cflags" in cgoCPPFLAGS were not checked when determining whether internal linking is safe.

    The go command now disallows "--with-path=", "--personality=", leading "=" or "$" characters in "--define-variable=" values, and local ".pc" paths in "#cgo pkg-config:" directives, and inspects cgoCPPFLAGS when checking internal linking compatibility.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97039 and Go issue https://go.dev/issue/82571.

  • cmd/go, cmd/link: cgo directive injection via .syso files disguised as Go object files

    Building a package containing a crafted ".syso" file could bypass cgo flag validation and inject arbitrary linker flags when linking.

    When loading ".syso" entries from a package archive, the linker only checked for recognized host object headers (ELF, Mach-O, PE, and XCOFF) before falling through to Go object parsing. A ".syso" file beginning with a "go object" header was parsed as a Go compiler object, allowing untrusted cgo metadata directives (such as "cgo_ldflag" or "cgo_dynamic_linker") embedded in the ".syso" file to be passed to the external linker without validation. Additionally, ".syso" filenames longer than 16 bytes lost their ".syso" extension when truncated in archive headers, and unrecognized ".syso" formats forced external linking in pure-Go builds.

    The linker now rejects ".syso" files that are not recognized host object formats, and "cmd/go" and "cmd/pack" preserve the ".syso" suffix when truncating long archive member names.

    Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue.

    This is CVE-2026-97040 and Go issue https://go.dev/issue/82570.

  • cmd/compile, cmd/link: host linker flag injection via //go:cgo_* directives

    Building a malicious package containing "//go:cgo_*" compiler directives could inject arbitrary flags into the external linker invocation on ELF platforms.

    The compiler and linker did not reject commas in "//go:cgo_import_dynamic", "//go:cgo_export_dynamic", "//go:cgo_export_static", "//go:cgo_import_static", and "//go:cgo_dynamic_linker" directives, and the linker passed the dynamic linker path using "-Wl,--dynamic-linker,". Furthermore, the two-argument form of "//go:cgo_import_dynamic" (which is permitted in non-cgo Go source files) could overwrite the external symbol name of a symbol already marked for cgo export. A symbol name or dynamic linker path containing a comma or leading "@" could split "-Wl,--export-dynamic-symbol=" or "-Wl,--dynamic-linker," into arbitrary host linker flags or response file arguments.

    The compiler and linker now reject commas in "//go:cgo_*" symbol and dynamic linker directives, the linker passes "-Wl,--dynamic-linker=", and "cgo_import_dynamic" no longer overwrites symbols exported via "cgo_export_dynamic" or "cgo_export_static".

    Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue.

    This is CVE-2026-97041 and Go issue https://go.dev/issue/82569.

  • cmd/cgo, cmd/compile, cmd/link: linker flag injection via cgo_import_dynamic and PE DLL names

    Building a malicious package that uses "//go:cgo_import_dynamic" or links against a crafted PE object on Windows could pass unsafe library arguments to the external linker.

    The compiler only checked the first character of the library name in "//go:cgo_import_dynamic" directives and skipped validation in cgo-generated files. In addition, on Windows, "cmd/cgo" and "cmd/link" did not validate imported DLL names extracted from PE object files before emitting "-l" flags for the external linker, allowing a crafted DLL name containing ".." path traversal or special characters to reference arbitrary files on disk.

    The compiler now validates every character of the library name in "//go:cgo_import_dynamic" directives (including in cgo-generated files on Windows) and rejects ".." path traversal, and "cmd/cgo" and "cmd/link" reject PE imported DLL names containing path separators, "..", ":", or leading "-" or "@".

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97042 and Go issue https://go.dev/issue/82568.

  • cmd/go, cmd/compile: unexpected code execution via escaped quotes in //go:cgo_ldflag

    Building a malicious package that uses cgo could bypass "#cgo LDFLAGS" validation and cause unexpected code execution at build time, or cause the go command to panic, via crafted quoting in "//go:cgo_ldflag" directives.

    When "cmd/cgo" generates "_cgo_gotypes.go", it quotes each "#cgo LDFLAGS" argument with strconv.Quote in a "//go:cgo_ldflag" directive, but "cmd/compile" and "cmd/go" parsed those directives by splitting on raw quote characters without handling backslash escapes or unquoting the string. This mismatch allowed disallowed linker flags or unvalidated linker search paths to be smuggled past the go command's flag checks and passed to the external linker. In addition, deduplicating LDFLAGS in the go command could panic with an out-of-bounds slice index when a prefix of the flag list matched near the end of the slice.

    "cmd/compile" and "cmd/go" now properly handle backslash-escaped quotes and unquote "//go:cgo_*" pragma strings with strconv.Unquote, and the slice bounds check in processCgoOutputs has been fixed.

    This issue was found by the Go Security Team during an internal audit.

    This is CVE-2026-97043 and Go issue https://go.dev/issue/82567.

  View the release notes for more information:
  https://go.dev/doc/devel/release#go1.27.4

  You can download binary and source distributions from the Go website:
  https://go.dev/dl/

  To compile from source using a Git clone, update to the release with

  git checkout go1.27.4
  

  and build as usual.

  Thanks to everyone who contributed to the releases.

  Cheers,
  Cherry and Junyang for the Go team

  Original source

  Show more
• All of your release notes in one feed

  Join Releasebot and get updates from Scala and hundreds of other software products.

  Create account

  Get updates with: RSS Email CLI MCP API Slack n8n
• Nov 10, 2026

  • Date parsed from source:
    Nov 10, 2026
  • First seen by Releasebot:
    Nov 11, 2026
  

  Go by Google

  Go Turns 17

  Go releases a year of major advances in language features, faster and safer libraries, modern hardware support, and developer tooling. Highlights include a modern JSON API, production goroutine leak profiling, post-quantum cryptography, and upgrades that help developers and AI coding assistants write idiomatic Go.

  Today, November 10th, we celebrate the 17th anniversary of Go’s open source release!

  Over the past year, we released Go 1.26 in February and Go 1.27 in August, alongside a steady stream of releases across our golang.org/x libraries and developer tools. Meanwhile, the pace of change across the software industry continues to accelerate, driven by shifting hardware, evolving security threats, and the rapid rise of AI-assisted development and agentic systems.

  In a tumultuous time for the industry, Go aims to be a steady hand on the tiller. Our goal is to keep Go grounded in its foundational principles of simplicity, reliability, efficiency, and an unwavering commitment to compatibility, while adapting to modern hardware, production workloads, and developer workflows. Increasingly, our investments serve a dual purpose: what helps human engineers write, understand, and maintain reliable Go code at scale also provides the guardrails and authoritative context that AI coding assistants and agents need to be effective.

  Core language and library improvements

  In the language itself, Go 1.26 and 1.27 addressed several long-standing restrictions in generics and everyday Go syntax, guided by years of real-world experience. When generics first landed in Go 1.18, methods could not declare their own type parameters, which sometimes forced awkward package-level functions and “inside-out” nested calls. Go 1.27 introduced generic methods on non-interface types (such as the new Rand.N method in math/rand/v2), allowing APIs to stay naturally organized on types and enabling readable method chaining. Together with support for self-referential type constraints in Go 1.26 and broader type inference for generic function values in Go 1.27, generics in Go feel more complete and natural than ever.

  Alongside generics, two refinements to value construction make everyday Go code cleaner and more concise. Go 1.26 extended the built-in new function to accept an initial value expression, allowing new(42) or new("go1.26") without the ubiquitous newInt-style helper functions used to populate optional pointer fields in JSON and protocol buffer structs. And in Go 1.27, struct literal keys can refer directly to fields of embedded or nested structs, reducing boilerplate in composite literals.

  In the standard library, our focus has been on evolving Go’s “production stack” and eliminating subtle operational traps. Few packages are as central to that as encoding/json, which has been a mainstay of Go since before Go 1.0. While its core model has held up remarkably well for over 15 years, tighter JSON standards and security expectations have turned some of its original defaults into interoperability and security hazards, such as silently accepting invalid UTF-8 or duplicate object keys and matching struct fields case-insensitively. At the same time, its buffered design prevented true streaming and limited performance. Addressing these issues while upholding Go’s compatibility promise for the millions of existing programs that depend on encoding/json meant designing a new major version of the package.

  Six years in the making, the new encoding/json/v2 and encoding/json/jsontext packages reached general availability in Go 1.27. Driven by Joe Tsai, Daniel Martí, and contributors from across the Go community, this modern JSON API brings safer, stricter defaults, flexible caller- and type-specified customization, and up to 10× faster unmarshaling, while cleanly separating high-level semantic marshaling (json/v2) from low-level, reflection-free syntactic streaming (jsontext). Crucially, we didn’t leave existing code behind: the original encoding/json package is now implemented entirely in terms of v2 under the hood. Existing v1 callers get faster unmarshaling simply by upgrading, and packages using v1 and v2 interoperate seamlessly so that the ecosystem can migrate gradually without flag days.

  We’ve also brought new production diagnostics to Go’s concurrency primitives. Concurrency is one of Go’s greatest strengths, but goroutines accidentally left blocked on abandoned channels or locks can silently leak memory and CPU in long-running services, and traditional goroutine profiles cannot distinguish leaked goroutines from ones legitimately waiting for work. First previewed in Go 1.26 and now generally available in Go 1.27, the new goroutine leak profiler (goroutineleak in runtime/pprof and /debug/pprof/goroutineleak in net/http/pprof) solves this for production services. Contributed by Vlad Saioc and Uber’s Programming Systems team, building on academic research with Aarhus University and Washington University in St. Louis, the profiler repurposes the garbage collector’s reachability phase to identify goroutines blocked on concurrency primitives that no runnable goroutine can ever reach. That allows it to pinpoint leaks in production with near-zero false positives and zero overhead when not in use.

  In net/http, closing an HTTP/1 response body with even a single unread byte—such as a trailing newline left behind by a JSON decoder—previously forced the client to tear down the underlying TCP and TLS connection. Go 1.27’s HTTP transport now automatically drains small unread response bodies in the background on close, turning a widespread latency footgun into up to a 5× speedup for sequential HTTP/1 requests while letting application code stay clean and simple.

  These releases also added several notable standard library APIs, including a native uuid package, a generic and type-safe errors.AsType, and an in-memory httptest.NewTestServer designed for virtual-time testing with testing/synctest. Existing packages saw significant speedups as well: io.ReadAll now runs twice as fast while allocating half as much memory, compress/flate compresses faster (speeding up gzip, zip, zlib, and png), and image/jpeg has a faster, more accurate encoder and decoder.

  Making the most of modern hardware

  Modern CPUs look very different from the hardware Go first launched on 17 years ago, with wide vector units and deep, non-uniform memory hierarchies. A major focus of our runtime and compiler work is ensuring Go programs make full use of modern silicon, both transparently when you upgrade your toolchain and through new APIs when you need explicit control.

  After debuting as an experiment in Go 1.25, the Green Tea garbage collector became the default in Go 1.26. By organizing object marking around contiguous memory spans rather than chasing pointers across the heap, Green Tea aligns with modern CPU memory architectures to reduce garbage collection overhead by 10–40% in real-world workloads—and by an additional ~10% on recent amd64 processors using AVX-512 vector instructions during scanning.

  Of course, the runtime shouldn’t be the only part of a Go program that can tap into vector hardware. Without access to Single Instruction, Multiple Data (SIMD) capabilities, compute-intensive software, from cryptography and media processing to data analytics and AI, leaves a significant portion of modern silicon dark. Until recently, the only way to light up that hardware in Go was by writing and maintaining per-architecture assembly. To change that, Go 1.26 and 1.27 introduced two experimental SIMD packages: simd/archsimd, for low-level access to architecture-specific vector instructions on amd64, arm64 (NEON), and WebAssembly (wasm); and simd, a higher-level, width-agnostic API that provides portable, near-assembly performance across architectures with automatic fallback emulation.

  We’ve also attacked the cost of memory allocation from multiple angles. The cheapest heap allocation is the one that never happens: in Go 1.26, the compiler began allocating initial slice backing stores on the stack at append sites—even for slices that ultimately escape to the heap—eliminating the flurry of small heap allocations that typically accompany slice growth. And for heap allocations more broadly, Go 1.27 introduced size-specialized memory allocation to speed up allocating the small objects (such as small structs, slices, and strings) that dominate allocator time. Generating dedicated fast-path allocator routines for size classes up to 80 bytes made small allocations up to 30% faster and improved overall performance in allocation-heavy programs. Together with a ~30% reduction in baseline cgo call overhead in Go 1.26, these improvements make Go programs faster and leaner out of the box.

  Secure software and ecosystem defense

  Go’s approach to security spans the entire lifecycle of software: providing safe APIs by design, preparing cryptography for the future, and actively defending the live ecosystem as new threats emerge.

  To defend against store-now, decrypt-later attacks and support the industry’s accelerating timelines for quantum readiness, Go has continued expanding its post-quantum cryptography support. Go 1.26 enabled hybrid post-quantum key exchanges (SecP256r1MLKEM768 and SecP384r1MLKEM1024) by default in crypto/tls and added the crypto/hpke package (implementing RFC 9180 Hybrid Public Key Encryption, including post-quantum hybrid KEMs). Go 1.27 followed up with the new crypto/mldsa package, implementing the FIPS 204 post-quantum ML-DSA signature standard and integrating it into crypto/x509 and crypto/tls.

  At the same time, we’ve continued hardening the standard library and runtime against subtle classes of vulnerabilities. Most key generation and signing functions across Go’s crypto/... packages now unconditionally draw from a secure system randomness source, closing off a classic footgun where non-cryptographic readers were accidentally passed in. Under the hood, Go 1.26 also added 64-bit heap base address randomization to harden cgo binaries and introduced the experimental runtime/secret package for eagerly erasing sensitive cryptographic temporaries from registers, stack frames, and the heap.

  Securing Go deployments also requires rapid vulnerability and incident response in a fast-moving threat landscape. From the Go vulnerability database and govulncheck to our release infrastructure, we’ve invested heavily in ecosystem defense. In October, that preparation was put to the test during the eMudhra certificate key disclosure incident, when eight intermediate TLS and code-signing certificates chaining to a widely trusted root CA were discovered to use trivially weak private keys. Because Linux lacks a uniform OS-level certificate revocation mechanism, Go’s built-in TLS verifier is the frontline defense for millions of Linux services. Within seven and a half hours of initial notification, the Go Security team shipped a targeted block in our first-ever URGENT track security release (Go 1.27.3 and Go 1.26.10) alongside an updated Go vulnerability database entry so govulncheck could flag affected binaries, giving Go users everything they needed to protect their deployments before the weak keys were publicly disclosed the next morning.

  Advancing the broader Go platform and tooling

  Go has always been more than a compiler and standard library: it is an end-to-end platform for software engineering. Over the past year, our work in golang.org/x/tools, the gopls language server, vscode-go, and pkg.go.dev has focused on making that platform even more productive for both human developers and AI coding assistants.

  In last fall’s Go Developer Survey, the single biggest challenge developers reported was ensuring their code follows best practices and current Go idioms. As Go evolves while standing by its compatibility promise, older ways of writing code continue to work alongside newer, clearer, or faster alternatives, creating a natural drift in idioms over time. That drift has been compounded by AI coding assistants, which gravitate toward the older patterns that dominate their training data.

  Go 1.26 tackled this with a complete overhaul of the go fix command, returning the long-dormant tool to its pre-Go 1.0 roots to apply dozens of automatic modernizers across entire codebases. What gofmt did for stylistic consistency, modernizers aim to do for idiomatic consistency. Available both as instant suggestions in gopls and as bulk, push-button upgrades in go fix, modernizers simplify existing code and help developers discover new language and library features. We now routinely consider whether new language and library proposals should ship with a modernizer of their own. Just as importantly, modernizers give coding agents an immediate way to bring generated code up to date, while helping shift the global corpus of open source Go code so that future models learn modern idioms from the start.

  Bespoke modernizers work well for the language and standard library, but a centralized team can never write them for every third-party module in the ecosystem. That’s why Go 1.26 also introduced the annotation-driven source-level inliner, the first step toward a “self-service” paradigm for automated code maintenance. Any package author can now annotate a deprecated function, type, or constant with //go:fix inline, and the inliner will safely migrate callers and references via go fix or in the IDE, carefully handling evaluation order, side effects, and name shadowing.

  In the editor, we’ve made four feature-packed releases of gopls over the past year (v0.21.0, v0.22.0, v0.23.0, and v0.24.0). In collaboration with the Dart team, we designed and proposed an open Language Server Protocol (LSP) extension for interactive refactoring, allowing language servers to ask for user input through dynamic, multi-step dialogs in any supporting editor. Now integrated into gopls and vscode-go, interactive refactoring powers customizable struct tag addition and removal, interface implementation (including generic interfaces) with live symbol search, and cross-package declaration moves. Beyond refactoring, gopls also gained generalized package renaming across directories, zero-configuration support for editing Go assembly files, subexpression hover inspection, completions and inlay hints for promoted fields, automatic govulncheck scanning when go.mod dependencies change, and continued enhancements to its built-in Model Context Protocol (MCP) server for AI coding assistants.

  Rounding out the developer platform, in May we launched the official pkg.go.dev API and followed up with support for go doc pkg@version in Go 1.27. Previously, developer tools and IDE integrations had to resort to fragile web scraping to query ecosystem metadata. Today, the pkg.go.dev API gives tool authors and AI coding agents a fast, authoritative service for querying module versions, package symbols, importers, and vulnerability data, while go doc pkg@version makes it easy to pull up documentation for any version of any package right from the command line.

  Looking ahead

  We have an ambitious year ahead for Go.

  On the tooling front, we’re building on the pkg.go.dev API, gopls, and go fix to make Go’s developer tools even more capable for both human developers and coding agents. Following the strong community response to go fix and //go:fix inline, we’re exploring ways to expand self-service static analysis, enabling developers, package maintainers, and organizations to easily integrate custom analyzers and domain-specific best-practice checks directly into their development workflows. We’re also exploring ways to surface richer package health and quality signals on pkg.go.dev and through its API, helping developers and coding agents evaluate and choose trustworthy, reliable dependencies.

  In the language and libraries, Go 1.28 will resolve one of Go’s longest-standing language requests by allowing composite literals to omit redundant types whenever the type can be inferred from context, cutting visual noise in deeply nested configurations, API requests, and table-driven tests. And with recent generics refinements and hashing APIs in place, we’ve just accepted a swath of proposals for generic collection APIs—including sets, ordered maps, and more—which will land in golang.org/x/exp over the next few weeks so the community can try them out and share feedback ahead of future standard library inclusion.

  Under the hood, we’re working hard to graduate a large subset of the simd and simd/archsimd packages (covering amd64, arm64 NEON, and wasm) in Go 1.28, with further expansions and arm64 scalable vector (SVE) support targeted for Go 1.29. Amid the global RAM crunch, reducing Go’s memory footprint is also one of our major priorities for the coming year.

  In the toolchain, Go 1.28 will increase build parallelism by writing compiler export data early and streamline static analysis by decoupling tool export data from the compiler. Looking further out, we’re working to support cgo builds without requiring a C toolchain, and we’re kicking the tires on WebAssembly’s early-stage stack-switching extension, which is already showing promising improvements in Go Wasm performance and binary size.

  Finally, ensuring Go stands the test of time means scaling not just our technology, but the open source project itself. Over the past year, some of Go’s most impactful advances, including encoding/json/v2 and the goroutineleak profile, were driven by or built in close partnership with contributors outside Google. To better support our growing ecosystem and contributor base, we’re working to bridge the gap between Go maintainers at Google and our broader community, and to diversify Go’s technical stewardship. That includes restructuring the proposal process to improve throughput, give the community clearer visibility into the process and input into prioritization, and formally involve community contributors in triage and review. Beyond proposals, we are building a clearer contributor ladder to empower proven contributors with greater autonomy, decision-making privileges, and maintenance responsibilities, and opening up maintainer summits and day-to-day communications to trusted contributors from our amazing community.

  Seventeen years in, Go is thriving because of the people who use it, build with it, and contribute to it every day. Thank you to everyone in the Go community for being part of this journey, and we wish you all the best in the year ahead!

  Original source

  Show more
• Nov 8, 2026

  • Date parsed from source:
    Nov 8, 2026
  • First seen by Releasebot:
    Oct 12, 2026
  • Modified by Releasebot:
    Nov 9, 2026
  

  Swift

  swift-6.4.x-DEVELOPMENT-SNAPSHOT-2026-11-06-a

  Swift publishes a development snapshot build dated November 6, 2026.

  Tag build swift-6.4.x-DEVELOPMENT-SNAPSHOT-2026-11-06-a

  Original source
• Nov 5, 2026

  • Date parsed from source:
    Nov 5, 2026
  • First seen by Releasebot:
    Nov 6, 2026
  

  Swift

  GSoC 2026 Showcase

  Swift adds DocC navigation and syntax highlighting in SourceKit-LSP, task tracking for concurrency diagnostics, and qualified name lookup in swift-syntax through three completed Google Summer of Code projects.

  The Swift project once again participated in Google Summer of Code in 2026, pairing newcomers to open source with mentors to build new features for Swift and its ecosystem.

  This year, we ran three projects, all of which were completed successfully:

  • DocC language features in SourceKit-LSP
  • Task and TaskGroup tracking for Swift Concurrency
  • Qualified name lookup for swift-syntax

  Here’s a short summary of each project, with links to the full writeups.

  DocC Language Features in SourceKit-LSP

  • Mentee: Padmashree S S
  • Mentors: Matthew Bastien, Prajwal Nadig
  • Project writeup: [GSoC 2026] DocC Language Features in SourceKit-LSP

  DocC is Swift’s documentation compiler. It turns the doc comments in your code, along with Markdown articles and tutorials, into browsable documentation. Inside those comments and files, a symbol link points to a type, function, or property in your code, so readers can jump straight to it:

  /// A type that greets people by name.
  ///
  /// Call ``greet(_:)`` to produce a greeting, or use
  /// ``Greeter/defaultName`` when no name is available.
  struct Greeter {
      static let defaultName = "World"
      func greet(_ name: String) -> String {
          "Hello, \(name)!"
      }
  }
  

  Before this project, editors had no awareness of these links, so you had to find the referenced symbol by hand. DocC Markdown files also had no syntax highlighting.

  Padmashree extended SourceKit-LSP, Swift’s language server, to understand DocC, so editors can help while you write documentation:

  • Go to definition for symbol links in doc comments, Markdown, and tutorial files
  • Clickable symbol links in the DocC preview that jump to the definition in your editor
  • Syntax highlighting for DocC Markdown and tutorial files

  Because these features are implemented in SourceKit-LSP, they aren’t limited to a single editor. They work in any editor that supports the Language Server Protocol (LSP), such as VS Code or Vim.

  Task and TaskGroup Tracking for Swift Concurrency

  • Mentee: Ege Kaya
  • Mentors: Alastair Houghton, Mike Ash
  • Project writeup: [GSoC 2026] Task and TaskGroup tracking for Swift Concurrency

  Programs in Swift use tasks to execute multiple things concurrently. Those tasks may be in different states, like actively running, sleeping, or waiting on another task to complete.

  Previously, the Swift runtime did not have a registry of active tasks that was possible to query a process for, and e.g. use it to detect “stuck” tasks, which made diagnosing these problems difficult.

  Ege’s project focused on implementing a high-performance, always-on registry that allows the concurrency runtime to track tasks in a process.

  Debuggers like lldb and other tools, including swift-inspect, can read this registry and offer developers valuable insights about the activity of tasks in their programs.

  Since every task creation and teardown touches the registry, the design focused on minimal performance impact to existing code. To avoid false sharing, the registry is split into 64 independent lists, or shards.

  In a stress test modeled on a web server that spawned over 600,000 tasks in a short burst, tracking them added about 0.015 seconds to a 0.37-second run; you can read a more detailed analysis in Ege’s writeup.

  Qualified Name Lookup for swift-syntax

  • Mentee: Filip Sakel
  • Mentor: Pavel Yaskevich
  • Project writeup: [GSoC 2026] Qualified Name Lookup for swift-syntax

  Swift macros, linters, and code generators built on swift-syntax could read the structure of Swift code, but they couldn’t easily perform contextual lookups.

  For tool developers, getting those answers meant relying on libraries outside swift-syntax, or hand-rolling lookup themselves, which is a difficult task to get right.

  Filip added qualified name lookup to swift-syntax’s SwiftLexicalLookup module. It builds on the GSoC 2024 project that introduced lexical scopes and unqualified name lookup, which already powers features in swift-java. Qualified lookup can be tricky to get right, as the example below illustrates:

  struct MyView {
      // <- In `struct MyView {}`, find members named 'model'
      #if true
      var model: Model // <- In type 'Model', find members named 'sayHi()'
      #endif
  }
  extension MyView {
      typealias Model = MyModel
  }
  final class MyModel {
      func sayHi() {
          print("Hi")
      }
  }
  

  In this example, we need to process extensions of the type MyView in order to discover that the Model type spelled inside MyView actually refers to the MyModel class, through the typealias Model defined in the extension below the MyView definition. Implementing these kinds of lookups manually is very difficult, and we’re excited to have this functionality built into swift-syntax!

  Thank you

  It’s always a pleasure to work with contributors and see their projects help Swift be more successful. Thank you to the contributors, mentors, and everyone else who offered help and support during this year’s projects!

  Want to see more? Explore projects from previous years, and find out how to take part in future ones, on Swift’s Google Summer of Code page.

  Original source

  Show more
• Nov 4, 2026

  • Date parsed from source:
    Nov 4, 2026
  • First seen by Releasebot:
    Nov 5, 2026
  

  Go by Google

  A new Go API for JSON

  Go releases stable, generally available JSON v2 packages in Go 1.27, bringing stricter input validation, more flexible customization and streaming APIs, and faster unmarshaling while preserving support for the original package.

  Michael Pratt, Joe Tsai, Daniel Martí, Johan Brandhorst-Satzkorn, Roger Peppe, Chris Hines, and Damien Neil
  4 November 2026

  Introduction

  JavaScript Object Notation (JSON) is a simple data interchange format, the most popular data format used on the internet, and widely read and written by Go programs. Go has included support for JSON in the standard library since well before Go 1.0. We first we wrote about support for JSON in Go more than 15 years ago!

  Over time, packages evolve with the needs of their users, and encoding/json is no exception. Last year, we wrote about a new experimental API for JSON designed to bring long-awaited improvements and fixes.

  After additional feedback and refinement, the new encoding/json/v2 and encoding/json/jsontext packages are stable and generally available in Go 1.27! This post is an updated version of the article introducing the experiment, describing the problems with encoding/json, and an introduction to the new packages.

  Problems with encoding/json

  Overall, encoding/json has held up well. The idea of marshaling and unmarshaling arbitrary Go types with some default representation in JSON, combined with the ability to customize the representation, has proven to be highly flexible. However, in the years since its introduction, various users have identified numerous shortcomings.

  Behavior flaws

  There are various behavioral flaws in encoding/json:

  • Imprecise handling of JSON syntax: Over the years, JSON has seen increased standardization in order for programs to properly communicate. Generally, decoders have become stricter at rejecting ambiguous inputs, to reduce the chance that two implementations will have different (successful) interpretations of a particular JSON value.
    • encoding/json currently accepts invalid UTF-8, whereas the latest Internet Standard (RFC 8259) requires valid UTF-8. The default behavior should report an error in the presence of invalid UTF-8, instead of introducing silent data corruption, which may cause problems downstream.
    • encoding/json currently accepts objects with duplicate member names. RFC 8259 does not specify how to handle duplicate names, so an implementation is free to choose an arbitrary value, merge the values, discard the values, or report an error. The presence of a duplicate name results in a JSON value without a universally agreed upon meaning. This could be exploited by attackers in security applications and has been exploited before (as in CVE-2017-12635). The default behavior should err on the side of safety and reject duplicate names.
  • Leaking nilness of slices and maps: JSON is often used to communicate with programs using JSON implementations that do not allow null to be unmarshaled into a data type expected to be a JSON array or object. Since encoding/json marshals a nil slice or map as a JSON null, this may lead to errors when unmarshaling by other implementations. A survey indicated that most Go users prefer that nil slices and maps are marshaled as an empty JSON array or object by default.
  • Case-insensitive unmarshaling: When unmarshaling, a JSON object member name is resolved to a Go struct field name using a case-insensitive match. This is a surprising default, a potential security vulnerability, and a performance limitation.
  • Inconsistent calling of methods: Due to an implementation detail, MarshalJSON methods declared on a pointer receiver are inconsistently called by encoding/json. While regarded as a bug, this cannot be fixed as too many applications depend on the current behavior.

  API deficiencies

  The API of encoding/json can be tricky or restrictive:

  • It is difficult to correctly unmarshal from an io.Reader. Users often write json.NewDecoder(r).Decode(v), which fails to reject trailing junk at the end of the input.
  • Options can be set on the Encoder and Decoder types, but cannot be used with the Marshal and Unmarshal functions. Similarly, types implementing the Marshaler and Unmarshaler interfaces cannot make use of the options and there is no way to plumb options down the call stack. For example, the Decoder.DisallowUnknownFields option loses its effect when calling a custom UnmarshalJSON method.
  • The Compact, Indent, and HTMLEscape functions write to a bytes.Buffer instead of something more flexible like a []byte or io.Writer. This limits the usability of those functions.

  Performance limitations

  Setting aside internal implementation details, the public API commits it to certain performance limitations:

  • MarshalJSON: The MarshalJSON interface method forces the implementation to allocate the returned []byte. Also, the semantics require that encoding/json verify that the result is valid JSON and also to reformat it to match the specified indentation.
  • UnmarshalJSON: The UnmarshalJSON interface method requires that a complete JSON value be provided (without any trailing data). This forces encoding/json to parse the JSON value to be unmarshaled in its entirety to determine where it ends before it can call UnmarshalJSON. Afterwards, the UnmarshalJSON method itself must parse the provided JSON value again.
  • Lack of streaming: Even though the Encoder and Decoder types operate on an io.Writer or io.Reader, they buffer the entire JSON value in memory. The Decoder.Token method for reading individual tokens is allocation-heavy and there is no corresponding API for writing tokens.

  Furthermore, if the implementation of a MarshalJSON or UnmarshalJSON method recursively calls the Marshal or Unmarshal function, then the performance becomes quadratic.

  Trying to fix encoding/json

  Introducing a new, incompatible major version of a package is a heavy consideration. If possible, we should try to fix the existing package.

  While it is relatively easy to add new features, it is difficult to change existing features. Unfortunately, these problems are inherent consequences of the existing API, making them practically impossible to fix within the Go 1 compatibility promise.

  We could in principle declare separate names, such as MarshalV2 or UnmarshalV2, but that is tantamount to creating a parallel namespace within the same package. This leads us to encoding/json/v2 (henceforth called v2), where we can make these changes within a separate v2 namespace in contrast to encoding/json (henceforth called v1).

  Building on encoding/json/jsontext

  Before discussing the v2 API, we first introduce the encoding/json/jsontext package that lays the foundation for improvements to JSON in Go.

  JSON serialization in Go can be broken down into two primary components:

  • syntactic functionality that is concerned with processing JSON based on its grammar, and
  • semantic functionality that defines the relationship between JSON values and Go values.

  We use the terms “encode” and “decode” to describe syntactic functionality and the terms “marshal” and “unmarshal” to describe semantic functionality. We aim to provide a clear distinction between functionality that is purely concerned with encoding versus that of marshaling.

  This diagram provides an overview of this separation. Purple blocks represent types, while blue blocks represent functions or methods. The direction of the arrows approximately represents the flow of data. The bottom half of the diagram, implemented by the jsontext package, contains functionality that is only concerned with syntax, while the upper half, implemented by the json/v2 package, contains functionality that assigns semantic meaning to syntactic data handled by the bottom half.

  The basic API of jsontext is the following:

  package jsontext
  
  type Encoder struct { ... }
  func NewEncoder(io.Writer, ...Options) *Encoder
  func (*Encoder) WriteValue(Value) error
  func (*Encoder) WriteToken(Token) error
  
  type Decoder struct { ... }
  func NewDecoder(io.Reader, ...Options) *Decoder
  func (*Decoder) ReadValue() (Value, error)
  func (*Decoder) ReadToken() (Token, error)
  
  type Kind byte
  type Value []byte
  func (Value) Kind() Kind
  type Token struct { ... }
  func (Token) Kind() Kind
  

  The jsontext package provides functionality for interacting with JSON at a syntactic level and derives its name from RFC 8259, section 2 where the grammar for JSON data is literally called JSON-text. Since it only interacts with JSON at a syntactic level, it does not depend on Go reflection.

  The Encoder and Decoder provide support for encoding and decoding JSON values and tokens. The constructors accept variadic options that affect the particular behavior of encoding and decoding. Unlike the Encoder and Decoder types declared in v1, the new types in jsontext avoid muddling the distinction between syntax and semantics and operate in a truly streaming manner.

  A JSON value is a complete unit of data and is represented in Go as a named []byte. It is identical to RawMessage in v1, which is now a type alias to jsontext.Value. A JSON value is syntactically composed of one or more JSON tokens. A JSON token is represented in Go as the opaque Token type with constructors and accessor methods. It is analogous to Token in v1 but is designed represent arbitrary JSON tokens without allocation.

  To resolve the fundamental performance problems with the MarshalJSON and UnmarshalJSON interface methods, we need an efficient way of encoding and decoding JSON as a streaming sequence of tokens and values. In v2, we introduce the MarshalJSONTo and UnmarshalJSONFrom interface methods that operate on an Encoder or Decoder, allowing the methods’ implementations to process JSON in a purely streaming manner. Thus, the json package need not be responsible for validating or formatting a JSON value returned by MarshalJSON, nor would it need to be responsible for determining the boundaries of a JSON value provided to UnmarshalJSON. These responsibilities belong to the Encoder and Decoder.

  Introducing encoding/json/v2

  Building on the jsontext package, we now introduce the encoding/json/v2 package. It is designed to fix the problems in v1, while remaining familiar to users of the v1 package. Our goal is that usages of v1 will operate mostly the same if directly migrated to v2.

  Here, we primarily cover the high-level API of v2. For examples on how to use it, we encourage readers to study the examples in the v2 package, the “Working with JSON” tutorial, or read Anton Zhiyanov’s blog covering the topic.

  The basic API of v2 is the following:

  package json
  
  func Marshal(in any, opts ...Options) (out []byte, err error)
  func MarshalWrite(out io.Writer, in any, opts ...Options) error
  func MarshalEncode(out *jsontext.Encoder, in any, opts ...Options) error
  
  func Unmarshal(in []byte, out any, opts ...Options) error
  func UnmarshalRead(in io.Reader, out any, opts ...Options) error
  func UnmarshalDecode(in *jsontext.Decoder, out any, opts ...Options) error
  

  The Marshal and Unmarshal functions have a signature similar to v1, but accept options to configure their behavior. The MarshalWrite and UnmarshalRead functions directly operate on an io.Writer or io.Reader, avoiding the need to temporarily construct an Encoder or Decoder just to write or read from such types. The MarshalEncode and UnmarshalDecode functions operate on a jsontext.Encoder and jsontext.Decoder and is actually the underlying implementation of the previously mentioned functions. Unlike v1, options are a first-class argument to each of the marshal and unmarshal functions, greatly extending the flexibility and configurability of v2. There are several options available in v2 which are not covered by this article.

  Type-specified customization

  Similar to v1, v2 allows types to define their own JSON representation by satisfying particular interfaces.

  type Marshaler interface {
      MarshalJSON() ([]byte, error)
  }
  type MarshalerTo interface {
      MarshalJSONTo(*jsontext.Encoder) error
  }
  
  type Unmarshaler interface {
      UnmarshalJSON([]byte) error
  }
  type UnmarshalerFrom interface {
      UnmarshalJSONFrom(*jsontext.Decoder) error
  }
  

  The Marshaler and Unmarshaler interfaces are identical to those in v1. The new MarshalerTo and UnmarshalerFrom interfaces allow a type to represent itself as JSON using a jsontext.Encoder or jsontext.Decoder. This allows options to be forwarded down the call stack, since options can be retrieved via the Options accessor method on the Encoder or Decoder.

  See the OrderedObject example for how to implement a custom type that maintains the ordering of JSON object members.

  Caller-specified customization

  In v2, the caller of Marshal and Unmarshal can also specify a custom JSON representation for any arbitrary type, where caller-specified functions take precedence over type-defined methods or the default representation for a particular type.

  func WithMarshalers(*Marshalers) Options
  
  type Marshalers struct { ... }
  func MarshalFunc[T any](fn func(T) ([]byte, error)) *Marshalers
  func MarshalToFunc[T any](fn func(*jsontext.Encoder, T) error) *Marshalers
  
  func WithUnmarshalers(*Unmarshalers) Options
  
  type Unmarshalers struct { ... }
  func UnmarshalFunc[T any](fn func([]byte, T) error) *Unmarshalers
  func UnmarshalFromFunc[T any](fn func(*jsontext.Decoder, T) error) *Unmarshalers
  

  MarshalFunc and MarshalToFunc construct a custom marshaler that can be passed to a Marshal call using WithMarshalers to override the marshaling of particular types. Similarly, UnmarshalFunc and UnmarshalFromFunc support similar customization for Unmarshal.

  The ProtoJSON example demonstrates how this feature allows serialization of all proto.Message types to be handled by the protojson package.

  Behavior differences

  While v2 aims to behave mostly the same as v1, its behavior has changed in some ways to address problems in v1, most notably:

  • v2 reports an error in the presence of invalid UTF-8.
  • v2 reports an error if a JSON object contains a duplicate name.
  • v2 marshals a nil Go slice or Go map as an empty JSON array or JSON object, respectively.
  • v2 unmarshals a JSON object into a Go struct using a case-sensitive match from the JSON member name to the Go field name.
  • v2 redefines the omitempty tag option to omit a field if it would have encoded as an “empty” JSON value (which are null, "", [], and {}).
  • v2 reports an error when trying to serialize a time.Duration, which currently has no default representation, but provides options to let the caller decide.

  For most behavior changes, there is a struct tag option or caller-specified option that can configure the behavior to operate under v1 or v2 semantics, or even other caller-determined behavior. See “Migrating to v2” for more information.

  Performance optimizations

  The Marshal performance of v2 is roughly at parity with v1. Sometimes it is slightly faster, but other times it is slightly slower. The Unmarshal performance of v2 is significantly faster than v1, with benchmarks demonstrating improvements of up to 10x.

  In order to obtain greater performance gains, existing implementations of Marshaler and Unmarshaler should migrate to also implement MarshalerTo and UnmarshalerFrom, so that they can benefit from processing JSON in a purely streaming manner. For example, recursive parsing of OpenAPI specifications in UnmarshalJSON methods significantly hurt performance in a particular service of Kubernetes (see kubernetes/kube-openapi#315), while switching to UnmarshalJSONFrom improved performance by orders of magnitude.

  For more benchmark details, see the go-json-experiment/jsonbench repository.

  On top of structural improvements, we’re continuing to invest in performance optimizations in the implementation for cases where the v2 implementation is slower than v1. You can expect additional improvements in Go 1.28.

  Compatibility

  The Go 1 compatibility promise is a core guarantee from the Go project that allows developers to build applications that will stand the test of time and continue working on future versions of Go.

  The original encoding/json and new encoding/json/v2 packages are of course both subject to the Go 1 compatibility promise. Applications using v1 will continue to be supported indefinitely and need not ever migrate to v2.

  That said, when designing the v2 packages we wanted to do better than keeping v1 supported. We wanted to ensure that v1 and v2 are compatible with one another so that packages using different versions can work together. Doing so allows a smooth ecosystem migration rather than forcing users to use one version or another due to the choices of their dependencies.

  For instance, suppose your package uses v2 to marshal a struct containing a field with a type defined in another package. That package may use the original MarshalJSON method to define its marshaling behavior. No problem, v2 supports MarshalJSON methods, so marshaling will continue working as expected.

  Vice versa, suppose your package uses v1 to marshal the same struct. The other package may use the v2 MarshalJSONTo method for better performance. No problem here either, as the v1 implementation supports v2’s MarshalJSONTo method under the hood.

  We’ve achieved this by designing the new packages such that, under the hood, v1 is implemented in terms of v2. As mentioned above, v2 supports a variety of Options. Each behavior difference is controlled by one of the these options. Thus, v1 can be implemented in terms of v2 by passing the full set of v1 compatibility options.

  With this approach, backwards-compatible additions such as new methods (e.g., MarshalJSONTo) or new struct tags (e.g., embed) are automatically supported to the benefit of existing v1 users.

  Migration

  Implementing v1 in terms of v2 options has the additional benefit of allowing gradual migration of callsites.

  encoding/json documents the full set of behavior differences between v1 and v2, and which option controls that behaviors.

  Many applications can migrate directly to v2 with no visible behavior changes, but applications that depend on v1 behavior can use the options to change only the behaviors they depend on.

  For example, we can select all v2 behavior except for allowing duplicate names:

  json.Marshal(..., json.DefaultOptionsV2(), jsontext.AllowDuplicateName(true))
  

  Alternatively, we can select all v1 behavior except for disallowing duplicate names:

  json.Marshal(..., jsonv1.DefaultOptionsV1(), jsontext.AllowDuplicateName(false))
  

  The encoding/json/v2 Migration Guide goes into more detail, covering a variety of scenarios for approaching migration of an application from v1 to v2.

  More information

  For additional references on working with the new JSON packages, see:

  • The “Working with JSON” tutorial,
  • The encoding/json/v2 and encoding/json/jsontext package documentation,
  • The encoding/json package’s v2 comparison documentation,
  • and the encoding/json/v2 Migration Guide.

  A long time coming

  The planning for a new major version of encoding/json spanned years. In late 2020, spurred on by the inability to fix issues in the current package, Daniel Martí (one of the maintainers of encoding/json) first drafted his thoughts on what a hypothetical v2 package should look like. Separately, after previous work on the Go API for Protocol Buffers, Joe Tsai was disappointed that the protojson package needed to use a custom JSON implementation because encoding/json was neither capable of adhering to the stricter JSON standard that the Protocol Buffer specification required, nor of efficiently serializing JSON in a streaming manner.

  Believing a brighter future for JSON was both beneficial and achievable, Daniel and Joe joined forces to brainstorm on v2 and started to build a prototype (with the initial code being a polished version of the JSON serialization logic from the Go protobuf module). Over time, a few others (Roger Peppe, Chris Hines, Johan Brandhorst-Satzkorn, Damien Neil, Austin Clements, and Michael Pratt) joined the effort by providing design review, code review, and regression testing. Many of the early discussions are publicly available in our recorded meetings and meeting notes. Later discussions are available in our encoding/json/v2 working group meeting notes.

  This work has been public since the beginning, and we increasingly involved the wider Go community, first with a GopherCon talk and discussion posted in late 2023, formal proposal posted in early 2025, and finally adopting encoding/json/v2 as a Go experiment in Go 1.25 for wider-scale testing by all Go users.

  The v2 effort took about 6 years to reach this point, incorporating feedback from many contributors and also gaining valuable empirical experience from use in production settings.

  It’s worth noting that it’s largely been developed and promoted by people not employed by Google, demonstrating that the Go project is a collaborative endeavor with a thriving global community dedicated to improving the Go ecosystem.

  Thank you to everyone that contributed!

  Original source

  Show more
• Nov 2, 2026

  • Date parsed from source:
    Nov 2, 2026
  • First seen by Releasebot:
    Jul 18, 2026
  • Modified by Releasebot:
    Nov 7, 2026
  

  Swift

  swift-DEVELOPMENT-SNAPSHOT-2026-11-01-a

  Swift ships a development snapshot build dated November 1, 2026.

  Tag build swift-DEVELOPMENT-SNAPSHOT-2026-11-01-a

  Original source
• Oct 29, 2026

  • Date parsed from source:
    Oct 29, 2026
  • First seen by Releasebot:
    Apr 15, 2026
  • Modified by Releasebot:
    Nov 3, 2026
  

  Swift

  swift-DEVELOPMENT-SNAPSHOT-2026-10-27-a

  Swift releases a development snapshot build dated October 27, 2026.

  Tag build swift-DEVELOPMENT-SNAPSHOT-2026-10-27-a

  Original source
• Oct 28, 2026

  • Date parsed from source:
    Oct 28, 2026
  • First seen by Releasebot:
    Oct 30, 2026
  

  Scala

  SCALA 3.3.9 LTS IS NOW AVAILABLE!

  Scala releases 3.3.9 LTS with backported bug fixes and improvements, including better Java generic signatures, exhaustiveness checks for sealed Java classes, clearer diagnostics, and Scaladoc fixes. The update preserves source and binary compatibility, validated across more than 1,500 projects.

  Scala 3.3.9 LTS is now available!

  This patch release backports most of the bugfixes and some of the improvements introduced in Scala 3.9.0. All of the backported changes were proven to not break either binary or source compatibility, by testing over 1500 projects in the Scala 3 Open Community Build.

  Notable changes

  • Stop using custom fonts for Scaladoc, to reduce doc jar size #26393
  • Improve Java generic signatures for higher-kinded types, value classes #25540 #25744 #25631
  • Exhaustiveness checking for sealed abstract Java classes #25788
  • Actionable diagnostic for missing members #23572
  • Warn on dubious negative literal syntax (- 42, -42.abs) #24163
  • Scaladoc no longer crashes with an NPE on JDK 25 #25779

  For a full list of changes and contributor credits, please refer to the release notes.

  Scala LTS Release Notice

  The next planned LTS 3.3 release will include updates introduced until last Scala 3.10.x before 3.11. We’ll continue to backport eligible bug fixes and improvements from the Scala Next series. Because the next LTS 3.9.0 has now been released, we will continue to support the 3.3.x series for the next year.

  Scala 3.x | End of service
  3.3.x | 2027 Sep
  3.9.x | 2029 Sep or later
  3.10.x | Until 3.11.x

  Original source

  Show more
• Oct 27, 2026

  • Date parsed from source:
    Oct 27, 2026
  • First seen by Releasebot:
    Oct 30, 2026
  

  Go by Google

  Vulnerabilities in golang.org/x/net

  Go releases golang.org/x/net v0.62.0 with fixes for two HTML security issues, improving text-node parsing efficiency and ensuring rendered raw text preserves namespace handling across ancestor transitions.

  Hello gophers,

  We have tagged version v0.62.0 of golang.org/x/net in order to address the following security issues:

  html: avoid quadratic complexity when coalescing text nodes

  When coalescing adjacent text nodes in addText and fosterParent, appending to an existing TextNode's Data via string concatenation (n.Data += text) reallocated and copied the accumulated string on every token. Inputs containing many short text runs separated by ignored end tags (such as "a") caused O(n^2) allocations and byte copies.

  Accumulate coalesced text in per-node byte slices during parsing and materialize Data strings once at the end of parse.

  Thanks to Markus Magnuson for reporting this issue.

  This is CVE-2026-78661 and Go issue https://go.dev/issue/82224.

  html: check all ancestor namespace transitions when rendering raw text

  In childTextNodesAreLiteral, walking up the tree previously stopped at the nearest foreign ancestor once an HTML integration point was found. However, that integration point may itself be a descendant of an element that was foster-parented into a foreign namespace (such as or fostered under ), causing a parser to resolve the subtree in a different foreign namespace upon re-parsing the rendered output.

  Continue walking the full ancestor chain and verify that every transition from a non-empty namespace occurs at an HTML integration point before emitting literal text.

  Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276) for reporting this issue.

  This is CVE-2026-97045 and Go issue https://go.dev/issue/82622.

  Cheers,
  Go Security team

  Original source

  Show more