Forem: Jefferson Otoni Lima

Quick Framework and some Performance Improvements

Jefferson Otoni Lima — Sun, 05 Oct 2025 17:17:37 +0000

I'm very excited to share more improvements implemented in the Quick Framework, developed by @jeffotoni. These updates focus on robustness, performance, and support for modern protocols.

Early mornings improving Quick

As we're using Quick for an AI (Artificial Intelligence) communication project, several needs have emerged that have led to new implementations and improvements to Quick. So, I'll present some improvements made this week.

There's nothing better than putting a framework to the test in practice, and it's fascinating! I'm using it in AI projects, developing native servers to orchestrate flows with LLMs, creating custom connectors, and continuously building RAG solutions. It's been a challenging yet very exciting experience.

Reflections from a curious developer

The path is arduous, long, but incredibly enjoyable. I'm driven by curiosity, and sometimes I can't contain myself. I need to study again, revisit something that was right there with me all along, but only now makes sense, you know? It wasn't the right moment before, perhaps, but it was there, so close and yet so distant. And this belated discovery intrigues me even more.

Despite years of practice and development, I often feel as if I'm seeing the world of technology through a crack, like someone peeking at the "whole" through a keyhole. Reality seems fragmented; we only access bits and pieces, flashes, never the complete whole, and that's intriguing. And perhaps we'll never truly see it.

That's why I decided to create these posts, not only to show in practice what was done for the Quick framework, but also to share some sincere reflections from a developer constantly learning.

What was implemented? 😁

1. Duplicate WriteHeader Protection

We implemented a custom wrapper (responseWriter) that prevents "superfluous response.WriteHeader" errors. Now, multiple calls to WriteHeader are handled silently, avoiding crashes in complex middleware chains.

2. Hijacker Support

The responseWriter now implements the http.Hijacker interface, allowing connection upgrades natively. This enables real-time bidirectional communication directly through Quick.

3. HTTP/2 Server Push

We added support for the http.Pusher interface with the c.Pusher() method, enabling HTTP/2 Server Push to improve performance by proactively sending resources to the client before they are even requested, reducing latency and round-trips.

Example:

q.Get("/", func(c *quick.Ctx) error {
    pusher, ok := c.Pusher()
    if ok {
        pusher.Push("/static/style.css", nil)
        pusher.Push("/static/app.js", nil)
    }
    return c.Status(200).SendString("<html>...</html>")
})

4. Simplified Server-Sent Events (SSE) for Streaming LLMs

We implemented the c.Flusher() method, which facilitates real-time data streaming, essential for modern applications with Large Language Models (LLMs). It allows you to progressively send tokens as they are generated, creating interactive experiences in both the browser and CLIs.

Real-world use cases:
Streaming responses from ChatGPT, Claude, and Gemini
Real-time deployment logs
Progressive dashboard updates
Server push notifications

Example 1:

q.Post("/ai/chat", func(c *quick.Ctx) error {
    c.Set("Content-Type", "text/event-stream")
    c.Set("Cache-Control", "no-cache")
    c.Set("Connection", "keep-alive")

    flusher, ok := c.Flusher()
    if !ok {
        return c.Status(500).SendString("Streaming not supported")
    }

    // Simulate streaming of tokens the LLM
    tokens := []string{"Hello", " this", " is", " a", " streaming", " response", " from", " AI"}

    for _, token := range tokens {
        // Standard SSE format
        fmt.Fprintf(c.Response, "data: %s\n\n", token)
        flusher.Flush() // Sends immediately to the customer
        time.Sleep(100 * time.Millisecond) // Simulates LLM latency
    }

    // Signals end of stream
    fmt.Fprintf(c.Response, "data: [DONE]\n\n")
    flusher.Flush()
    return nil
})

Example 2:

q.Get("/events", func(c *quick.Ctx) error {
    c.Set("Content-Type", "text/event-stream")
    c.Set("Cache-Control", "no-cache")

    flusher, ok := c.Flusher()
    if !ok {
        return c.Status(500).SendString("Streaming not supported")
    }

    for i := 0; i < 10; i++ {
        fmt.Fprintf(c.Response, "data: Message %d\n\n", i)
        flusher.Flush()
        time.Sleep(time.Second)
    }
    return nil
})

Client JavaScript (Browser):

const eventSource = new EventSource('/ai/chat');
eventSource.onmessage = (event) => {
    if (event.data === '[DONE]') {
        eventSource.close();
        return;
    }
    document.getElementById('response').innerText += event.data;
};

Client CLI (Go):

resp, _ := http.Post("http://localhost:8080/ai/chat", "application/json", body)
reader := bufio.NewReader(resp.Body)
for {
    line, _ := reader.ReadString('\n')
    if strings.Contains(line, "[DONE]") {
        break
    }
    fmt.Print(strings.TrimPrefix(line, "data: "))
}

It works perfectly with HTTP/2 multiplexing, allowing multiple simultaneous streams on the same connection.

5. Pooling Optimization

The Reset() method has been optimized to reuse the existing wrapper instead of recreating it with each request. This reduces memory allocations in the hot path, improving throughput.

6. Memory Leak Prevention

We implemented full context cleanup in releaseCtx(), including Context and wroteHeader fields, ensuring that no residual state remains between requests.

Impact

✅ Greater robustness in high-concurrency scenarios
✅ Native HTTP/2 support
✅ Server-Sent Events (SSE) made easy with c.Flusher()
✅ Reduced allocations per request
✅ Zero breaking changes and 100% backward compatibility

All changes maintain full compatibility with existing code.

🆚 SSE vs WebSocket

Appearance	SSE	WebSocket
Server CPU	🟢 Low	🟡 Medium
Server Memory	🟢 2-4 KB/connection	🟡 8-16 KB/connection
Bandwidth	🟢 Lower overhead	🟡 Higher overhead
Latency	🟡 ~50 ms	🟢 ~5-10 ms
Implementation	🟢 Simple	🟡 Complex
Debugging	🟢 HTTP Tools	🔴 Specific Tools
Firewall/Proxy	🟢 Standard HTTP	🟡 Power Issues
Bidirectional	🔴 No (server-client only)	🟢 Yes
Protocol	HTTP/1.1 or HTTP/2	WebSocket (RFC 6455)
Parser	Plain Text	Binary Frames
Handshake	Normal HTTP Request	HTTP Refresh
Automatic Reconnect	🟢 Yes (native)	🔴 Manual
Browser Support	🟢 All modern	🟢 All modern
Message Overhead	~45 bytes	~50+ bytes
Ideal for	Notifications, feeds, logs	Chat, games, collaboration
Scalability	🟢 I have ~10,000 connections	🟢 Thousands of Connections
CDN Compatible	🟢 Yes	🟡 Limited
Backend Complexity	🟢 Low	🟡 High

📊 Performance Comparison - SSE Writing Methods

This benchmark was run to identify the most efficient method for detecting SSE events unrelated to http.ResponseWriter. Tests were performed on an Apple M3 Max with Go 1.x, measuring nanoseconds per operation (ns/op), bytes allocated (B/op), and number of allocations (allocs/op).

Benchmark Results

The w.Write([]byte()) method performs best with 13.56 ns/op and zero allocations, approximately 4x faster than fmt.Fprint() and 9x faster than io.WriteString().

For large messages (>1 KB), it is recommended to use sync.Pool to reuse buffers, reducing allocation and putting pressure on the garbage collector.

Recommendations

Development/Debugging: Use fmt.Fprint() for simplicity.
Production (small messages): Use w.Write([]byte()) for maximum performance.
Production (large messages): Use sync.Pool with reused buffers.
High performance (>10,000 requests/s): Combine w.Write() with a buffer pool.

The full benchmark is available in /bench.

Method	Performance	Allocations	Complexity	Recommendation
`fmt.Fprint()`	🟡 Medium (53 ns)	3 allocations	🟢 Simple	✅ Development
`io.WriteString()`	🟡 Slow (116 ns)	1 allocation	🟢 Simple	⚠️ Avoid
`w.Write([]byte)`	🟢🟢 Excellent (13 ns)	0 allocations	🟢 Simple	✅ Throughput
`strings.Builder`	🟡 Slow (124 ns)	1-2 allocations	🟡 Media	⚠️ Avoid
`Multiple Writes`	🟢 Good (21 ns)	0 allocations	🟢 Simple	✅ Alternative
`sync.Pool`	🟢🟢 Excellent (40 ns)	0 allocations	🔴 Complex	✅ High-performance
`Unsafe`	🟢🟢 Excellent (21 ns)	0 allocations	🔴 Complex	⚠️ Experts

🚀 Running the Benchmark

To reproduce the performance tests and validate the results on your machine, run:

go test -bench=. -benchtime=1s -benchmem ctx_bench_test.go

Benchmark Parameters

-bench=. - Run all benchmarks
-benchtime=1s - Run each benchmark for 1 second
-benchmem - Include memory allocation statistics

📊 Benchmark Results

Test Environment:

OS: macOS (darwin)
Architecture: ARM64
CPU: Apple M3 Max
Go Version: 1.x

Method	ns/op	ops/sec	B/op	allocs/op	Performance
`WriteBytes`	13.32	75.1M	0	0	🥇 Winner
`MultipleWrites`	20.68	48.4M	0	0	🥈 Excellent
`Unsafe`	20.98	47.7M	0	0	🥉 Great
`Pooled`	39.00	25.6M	0	0	✅ Good
`FmtFprint`	52.69	19.0M	16	1	⚠️ Slow
`FmtFprintf`	62.61	16.0 million	16	1	⚠️ Slow
`IoWriteString`	111.6	9.0 million	1024	1	🔴 Very slow
`Optimized`	119.7	8.4 million	1024	1	🔴 Very slow
`StringsBuilder`	122.7	8.2 million	1032	2	🔴 Very slow

Method	ns/op	Speedup	B/op	allocs/op	Performance
`PooledLarge`	234.5	Baseline	0	0	🥇 Winner
`WriteBytesLarge`	811.2	3.46x slower	9472	1	🔴 Much Slower

Examples and Source Code

All tests can be accessed here -> Quick SSE

Here you can view the Bench source code bench

Contributions

Quick is an open-source project in constant evolution. Feedback and contributions are always welcome!
GitHub: Quick

golang #webframework #performance #opensource #go #quick

Quick Framework e algumas Melhorias de Performance

Jefferson Otoni Lima — Sat, 04 Oct 2025 17:08:02 +0000

Muito feliz em compartilhar mais melhorias implementadas no Quick Framework, desenvolvido por @jeffotoni. Essas atualizações focam em robustez, performance e suporte a protocolos modernos.

Madrugadas melhorando o Quick

Como estamos usando o Quick para projeto de comunicação com IA(Inteligência Artificial) apareceu diversas necessidades que levaram a novas implementações e melhorias no Quick. Então vou apresentar algumas melhorias que foram feitas essa semana.

Nada melhor do que colocar um framework à prova na prática e isso é fascinante! Estou utilizando em projetos de IA, desenvolvendo servidores nativos para orquestrar fluxos com LLMs, criando conectores personalizados e construindo soluções RAG continuamente. Tem sido uma experiência desafiadora e ao mesmo tempo muito empolgante.

Reflexões de um desenvolvedor curioso

O caminho é árduo, longo, mas incrivelmente prazeroso. Sou movido pela curiosidade e, às vezes, não me contenho, preciso estudar de novo, revisitar algo que estava ali ao meu lado o tempo todo, mas que só agora faz sentido, entende?. Não era o momento antes, talvez mas estava ali tão perto e ao mesmo tempo tão distante. E essa descoberta tardia me intriga ainda mais.

Apesar dos anos de prática e desenvolvimento, frequentemente me sinto como se estivesse vendo o universo da tecnologia por uma fresta como quem espreita o “todo” pela fechadura de uma porta. A realidade parece fragmentada acessamos apenas pedaços, flashes, nunca o todo completo e isso é intrigante. E talvez nunca o vejamos de fato.

Foi por isso que resolvi criar estes posts não somente para mostrar na prática o que foi feito para framework Quick mas algumas reflexões sinceras de um desenvolvedor em constante aprendizado.

O que foi implementado? 😁

1. Proteção contra WriteHeader Duplicado

Implementamos um wrapper customizado (responseWriter) que previne erros de "superfluous response.WriteHeader". Agora, múltiplas chamadas a WriteHeader são tratadas silenciosamente, evitando crashes em chains complexas de middleware.

2. Suporte Hijacker

O responseWriter agora implementa a interface http.Hijacker, permitindo upgrades de conexão de forma nativa. Isso habilita comunicação bidirecional em tempo real diretamente através do Quick.

3. HTTP/2 Server Push

Adicionamos suporte à interface http.Pusher com método c.Pusher(), habilitando HTTP/2 Server Push para melhorar performance ao enviar recursos proativamente ao cliente antes mesmo deles serem requisitados, reduzindo latência e round-trips.

Exemplo:

q.Get("/", func(c *quick.Ctx) error {
    pusher, ok := c.Pusher()
    if ok {
        pusher.Push("/static/style.css", nil)
        pusher.Push("/static/app.js", nil)
    }
    return c.Status(200).SendString("<html>...</html>")
})

4. Server-Sent Events(SSE) Simplificado para Streaming de LLMs

Implementamos o método c.Flusher() que facilita streaming de dados em tempo real, essencial para aplicações modernas com LLMs (Large Language Models). Permite enviar tokens progressivamente conforme são gerados, criando experiências interativas tanto no browser quanto em CLIs.

Casos de uso reais:
Streaming de respostas de ChatGPT, Claude, Gemini
Logs em tempo real de deployments
Atualizações progressivas de dashboards
Notificações push do servidor

Exemplo1:

q.Post("/ai/chat", func(c *quick.Ctx) error {
    c.Set("Content-Type", "text/event-stream")
    c.Set("Cache-Control", "no-cache")
    c.Set("Connection", "keep-alive")

    flusher, ok := c.Flusher()
    if !ok {
        return c.Status(500).SendString("Streaming not supported")
    }

    // Simula streaming de tokens de uma LLM
    tokens := []string{"Hello", " this", " is", " a", " streaming", " response", " from", " AI"}

    for _, token := range tokens {
        // Formato SSE padrão
        fmt.Fprintf(c.Response, "data: %s\n\n", token)
        flusher.Flush() // Envia imediatamente ao cliente
        time.Sleep(100 * time.Millisecond) // Simula latência da LLM
    }

    // Sinaliza fim do stream
    fmt.Fprintf(c.Response, "data: [DONE]\n\n")
    flusher.Flush()
    return nil
})

Exemplo2:

q.Get("/events", func(c *quick.Ctx) error {
    c.Set("Content-Type", "text/event-stream")
    c.Set("Cache-Control", "no-cache")

    flusher, ok := c.Flusher()
    if !ok {
        return c.Status(500).SendString("Streaming not supported")
    }

    for i := 0; i < 10; i++ {
        fmt.Fprintf(c.Response, "data: Message %d\n\n", i)
        flusher.Flush()
        time.Sleep(time.Second)
    }
    return nil
})

Cliente JavaScript (Browser):

const eventSource = new EventSource('/ai/chat');
eventSource.onmessage = (event) => {
    if (event.data === '[DONE]') {
        eventSource.close();
        return;
    }
    document.getElementById('response').innerText += event.data;
};

Cliente CLI (Go):

resp, _ := http.Post("http://localhost:8080/ai/chat", "application/json", body)
reader := bufio.NewReader(resp.Body)
for {
    line, _ := reader.ReadString('\n')
    if strings.Contains(line, "[DONE]") {
        break
    }
    fmt.Print(strings.TrimPrefix(line, "data: "))
}

Funciona perfeitamente com HTTP/2 multiplexing, permitindo múltiplos streams simultâneos na mesma conexão.

5. Otimização de Pooling

O método Reset() foi otimizado para reusar o wrapper existente ao invés de recriá-lo a cada requisição. Isso reduz alocações de memória no hot path, melhorando throughput.

6. Prevenção de Memory Leaks

Implementamos limpeza completa de contexto no releaseCtx(), incluindo campos Context e wroteHeader, garantindo que nenhum state residual permaneça entre requisições.

Impacto

✅ Maior robustez em cenários de alta concorrência
✅ Suporte nativo a HTTP/2
✅ Server-Sent Events (SSE) facilitado com c.Flusher()
✅ Redução de alocações por requisição
✅ Zero breaking changes e 100% retrocompatível

Todas as mudanças mantêm compatibilidade total com código existente.

🆚 SSE vs WebSocket

Aparência	SSE	WebSocket
CPU do Servidor	🟢 Baixa	🟡 Média
Memória do Servidor	🟢 2-4 KB/conexão	🟡 8-16 KB/conexão
Comprimento de Banda	🟢 Menor overhead	🟡Maior overhead
Latência	🟡 ~50 ms	🟢 ~5-10 ms
Implementação	🟢 Simples	🟡 Complexa
Depuração	🟢 Ferramentas HTTP	🔴 Ferramentas específicas
Firewall/Proxy	🟢 HTTP padrão	🟡 Problemas de energia
Bidirecional	🔴 Não (apenas servidor→cliente)	🟢 Sim
Protocolo	HTTP/1.1 ou HTTP/2	WebSocket (RFC 6455)
Parser	Texto simples	Quadros binários
Handshake	Solicitação HTTP normal	Atualização HTTP
Reconexão automática	🟢 Sim (nativo)	🔴 Manual
Suporte a navegadores	🟢 Todos os modernos	🟢 Todos os modernos
Sobrecarga por Mensagem	~45 bytes	~50+ bytes
Ideal para	Notificações, feeds, logs	Bate-papo, jogos, colaboração
Escalabilidade	🟢 Tenho ~10 mil conexões	🟢 Milhares de conexões
Compatível com CDN	🟢 Sim	🟡 Limitado
Complexidade do Backend	🟢 Baixa	🟡 Alta

📊 Comparação de Desempenho - Métodos de Escrita SSE

Este benchmark foi executado para identificar o método mais eficiente de detecção de eventos SSE não relacionados a http.ResponseWriter. Os testes foram realizados em um Apple M3 Max com Go 1.x, medindo nanossegundos por operação (ns/op), bytes alocados (B/op) e número de alocações (allocs/op).

Resultado do Benchmark

O método w.Write([]byte()) apresenta melhor desempenho com 13,56 ns/op e zero alocações, sendo aproximadamente 4x mais rápido que fmt.Fprint() e 9x mais rápido que io.WriteString().

Para mensagens grandes (>1 KB), recomenda-se usar sync.Pool para reutilizar buffers, reduzindo a alocação e pressionando o coletor de lixo.

Recomendações

Desenvolvimento/Depuração use fmt.Fprint() para simplificar
Produção (mensagens pequenas) use w.Write([]byte()) para desempenho máximo.
Produção (mensagens grandes) use sync.Pool com buffers reutilizados
Alto desempenho (>10 mil req/s): Combine w.Write() com buffer pool

O benchmark completo está disponível em /bench.

Método	Desempenho	Alocações	Complexidade	Recomendação
`fmt.Fprint()`	🟡 Médio (53 ns)	3 alocações	🟢 Simples	✅ Desenvolvimento
`io.WriteString()`	🟡 Lento (116 ns)	1 alocação	🟢 Simples	⚠️ Evite
`w.Write([]byte)`	🟢🟢 Excelente (13 ns)	0 alocações	🟢 Simples	✅ Produção
`strings.Builder`	🟡 Lento (124 ns)	1-2 alocações	🟡 Mídia	⚠️ Evitar
`Múltiplas Gravações`	🟢 Boa (21 ns)	0 alocações	🟢 Simples	✅ Alternativo
`sync.Pool`	🟢🟢 Excelente (40 ns)	0 alocações	🔴 Complexa	✅ Alto desempenho
`Inseguro`	🟢🟢 Excelente (21 ns)	0 alocações	🔴 Complexa	⚠️ Especialistas

🚀 Executando o Benchmark

Para reproduzir os testes de desempenho e validar os resultados em sua máquina, execute:

go test -bench=. -benchtime=1s -benchmem ctx_bench_test.go

Parâmetros do Benchmark

-bench=. - Executar todos os benchmarks
-benchtime=1s - Executar cada benchmark por 1 segundo
-benchmem - Incluir estatísticas de alocação de memória

📊 Resultados do Benchmark

Ambiente de Teste:

SO: macOS (darwin)
Arquitetura: ARM64
CPU: Apple M3 Max
Versão Go: 1.x

Método	ns/op	ops/seg	B/op	allocs/op	Desempenho
`WriteBytes`	13,32	75,1M	0	0	🥇 Vencedor
`MultipleWrites`	20,68	48,4M	0	0	🥈 Excelente
`Inseguro`	20,98	47,7 milhões	0	0	🥉 Ótimo
`Pooled`	39,00	25,6 milhões	0	0	✅ Bom
`FmtFprint`	52,69	19,0 milhões	16	1	⚠️ Lento
`FmtFprintf`	62,61	16,0 milhões	16	1	⚠️ Lento
`IoWriteString`	111,6	9,0 milhões	1024	1	🔴 Muito lento
`Otimizado`	119,7	8,4 milhões	1024	1	🔴 Muito lento
`StringsBuilder`	122,7	8,2 milhões	1032	2	🔴 Muito Lento

Método	ns/op	Aceleração	B/op	allocs/op	Desempenho
`PooledLarge`	234,5	Linha de Base	0	0	🥇 Vencedor
`WriteBytesLarge`	811,2	3,46x mais lento	9472	1	🔴 Muito Mais Lento

Exemplos e código fonte

Todos os testes pode ser acessados aqui -> Quick SSE

Aqui você consegue visualizar o codigo fonte do Bench bench

Contribuições

Quick é um projeto open-source em constante evolução. Feedbacks e contribuições são sempre bem-vindos!
GitHub: Quick

golang #webframework #performance #opensource #go #quick

A Dev's Reflections on AI

Jefferson Otoni Lima — Fri, 29 Aug 2025 18:01:02 +0000

Ethics in Artificial Intelligence?

Let's not fool ourselves, the game has changed and I have no doubt about that, so let's reflect a bit on this subject.

I recently participated in a presentation given by the LinkedIn News Event presented by Ana Prado and the special guest, the distinguished Teacher Dr. Alvaro Machado Dias"Risks and ethical limits in the use of artificial intelligence" . It was very interesting and made me reflect a little more on this provocative and complex issue that often goes unnoticed by those of us who work directly with technology on a daily basis.

It's curious how certain topics awaken in us that almost uncontrollable urge to think a little beyond, to go deeper, to open the mental "sublime" and start coding ideas as if they were lines of Go code or any other language, of course. That's exactly what happened to me. I could simply follow the routine of a software engineer, systems architect, think about data structures, algorithms, k8s pipelines, but with every conversation I heard, something inside me screamed, you know?

We need to reflect more about this as humanity I thought to myself. And here I am, trying to write, not because it was in my daily planning, but because it's as if I'm compiling philosophical code that insists on running inside me.

They say I'm an exception, but am I? A technician, an engineer, someone immersed for more than two decades in architecture and programming, but who isn't content with just designing systems. I love when conversation invades the terrain of philosophy, ethics, those things that have no official documentation, no README on GitHub to guide us where to go, what to do, but that need dense and "human" interpretation. I get really annoying when I get into this subject with colleagues.

AI in the Gray Territory

And artificial intelligence coming with all its force since the paper "Attention Is All You Need (Vaswani et al., 2017)" published in 2017, which defines the "Transformer" model as a new architecture eliminating the need for RNNs (Recurrent Neural Networks) that were standard in NLP (Natural Language Processing) using the "self-attention" mechanism, exactly, used to capture relationships between words regardless of the distance between them, and this was the watershed moment. Something extraordinary would come from all this soon after, enabling the training of the models we know today: GPT, Claude, Gemini, etc.

All of this is precisely in this gray territory if you understand me. It's technical, mathematical, but at the same time forces us to ask what it means to be human, what is right or wrong, what the actual definition of the word "intelligence" and "knowledge" is, leading us to question and reflect even more on the "definitions of words" and how they are used nowadays.

I see many always replicating an "absolute concept" as an imposition, treating the word as if it were temporal. In my view, it's much beyond that, it's timeless, molding itself to each era as something flexible, expandable, continuous and evolutionary. The words "intelligence" and "knowledge" were not, and are not understood in an absolute way. It's something much broader. I believe it's present from primitive biological processes to the possibility of manifesting in artificial systems, you know?

Of course, this is just an opinion. I discovered that I love talking about this. I feel something inside, exactly the same feeling when I'm coding.

Maybe it sounds strange to some, but writing about AI ethics gives me the same energy as opening the terminal, importing a package and starting to structure an API in Go, yes Go too. The difference is that here the terms are dilemmas, provocations, questions that stay in goroutines, exactly, waiting for a return because we don't have an immediate, absolute defined answer. They need reflection and time to be processed, you know? Like we do in Go when we want to run something asynchronously.

Everyone talks about ethics when the subject is artificial intelligence. The concern from everyone is clear and evident. "Questions like what about copyrights?", "Who is responsible when an AI system makes an error or causes damage?", "What are the limits of AI?" and so many others we know...

Ethics is discussed in beautiful reports, in corporate PDFs, in international conferences and even in emerging legislation. Nothing against it, but I prefer to go straight to the point, and the question would be: are we really talking about ethics? Or are we just trying to organize conflicts of interest that clash all the time?

The Myth of Universal Ethics

I believe that we will never achieve "ethics" itself. Ethics as an absolute value, as universal truth, simply doesn't exist in the contemporary world. What exists are conflicts of ethics. On one side we have the ethics of privacy, on the other the ethics of security. On one side the ethics of freedom, on the other the ethics of profit.

What is ethical for one culture can be immoral for another, what is acceptable for a company can be intolerable for a community. And what we know about AI today it's not born within a neutral vacuum. AI as we know it needs to be fed, trained and controlled by humans and organizations, I say "still." And this is where the debate starts to get much more interesting.

Who Really Decides?

Many people think that when we talk about ethics in AI, it's simply about teaching the machine not to do harm. Beautiful, isn't it? But the real question that should be asked is: who defines what is "harm"? Who has the power to determine which values will be embedded in algorithms? Who controls the machine, who profits from it, who loses, who decides what is good? These four simple questions expose a reality that most avoid facing.I understand it's a dense and complex subject, but we have to question ourselves all the time about how we're going to deal with all this.

The NYT vs OpenAI Case - A Wake-up Call

A recent example shows the size of the problem. Look, the New York Times managed to get a court order forcing OpenAI to store all chats, including temporary ones (wait, temporary too? can they be stored? Aren't they temporary? Temporary for whom? I was really curious and in doubt), from users. Look at what this means: a judicial decision can force a global company to change how it handles data from millions of people, without those people having a voice or choice. Imagine the dimension of this.

What was temporary becomes permanent. Wasn't it private? And now it becomes potentially accessible. Crazy, isn't it? There's a break in trust and vulnerability increases, both for individuals and companies. You can't take sides. I'm not trying to get into the merits here, I'm just demonstrating the fragility that exists and everything is very new and recent, something that came to radically transform what we know.

And you know what's most serious about all this? Until now we don't have clear jurisprudence, there's no solid regulatory framework, there's not even consensus among countries, imagine at a global level, dealing with situations like this. And this is where I believe we're stuck in limbo, exactly in a for {}, that is, in an infinite loop subject to all kinds of harm, momentary interests of those who have more POWER.

Trapped in the Infinite Loop

I have no doubt about the complexity this represents, and if we observe in a global context it's even denser and more complex. What we see all the time is that interests speak louder than universal principles. To facilitate understanding: companies seek profit, governments seek power, communities seek survival. And AI (artificial intelligence), with all its processing capacity and reach, stays at the center of everything and that's where we see all these interests clashing all the time like an old game "Asteroids" - believe me, it's not from my era but I love it. That's why when we talk about AI ethics without talking about politics, economics and power disputes, you can be sure we're not talking about the "same ethics" at all.

I see many defending codes of conduct and best practices as absolute solutions. I think: is this really possible? Or is it just a smokescreen, because they're not asking the fundamental questions to get straight to the point? Who controls? Who profits? Who is negatively impacted? Who decides what is good? If we don't have the courage to answer these questions, any conversation about ethics will just be rhetoric.

And what I notice is that we're giving up, little by little, our autonomy. Literally handing over our data in exchange for "convenience." I'm also part of all this, I'm also trapped and hostage to everything, but that doesn't mean we can't reflect and discuss everything that's happening. We've trusted platforms without knowing how the rules actually work. I notice that we're allowing them to define the limits of technology in our place. I feel like we're outsourcing our own responsibility and somewhere far away, well hidden, far away, someone will be taking care of ethics for us. But are they really?

And the reflection always remains: AI ethics is not a corporate guide, not a checklist of good intentions but a beautiful and enormous battlefield like the game "CALL OF DUTY." Where values confront each other, where interests impose themselves and where human beings need to make complex decisions about who will be or continue being the protagonist, you know?

We shouldn't pretend anymore that AI ethics is just a beautiful chapter in corporate reports, but rather about who will decide the future of our relationship with technology: us or them?

As a good user and developer, of course, we know that every code has a gigantic possibility of having some kind of bug, especially code generated by AI.

The question here is: are we going to continue debugging our humanity in production or are we finally going to take control of our own ethical code?

What do you think? Are we being protagonists or just users of a system we don't fully understand?

If you made it this far, I thank you from the heart and thank you very much for this joint reflection. Share your views in the comments and let's build this debate together, line by line, like good collaborative code.

Hope you enjoy it! 🚀🚀 ☺️

Reflexões de um Dev sobre IA

Jefferson Otoni Lima — Fri, 29 Aug 2025 18:00:24 +0000

Ética em Inteligência Artificial ?

Participei recentemente de um apresentação feita pelo Evento da LinkedIn Notícias apresentado pela Ana Prado e o convidado especial o ilustre Professor Dr. Alvaro Machado Dias "Riscos e limites éticos no uso da inteligência artificial", bem interessante e que me fez refletir um pouco mais sobre essa questão tão provocativa e complexa e que muitas vezes passa despercebido por nós que está trabalhando no dia a dia diretamente com a tecnologia.

Não devemos nos iludir, o jogo é outro e isso não tenho dúvidas, então vamos refletir um pouco sobre o assunto.

É curioso como certos temas despertam em nós aquela vontade quase incontrolável de pensar um pouco além, de ir mais fundo, de abrir o sublime mental e começar a godar ideias como se fossem linhas de código em Go ou qualquer outra lang é claro. Foi exatamente o que aconteceu comigo. Eu poderia simplesmente seguir a rotina de engenheiro de software, arquiteto de sistemas, pensar em estruturas de dados, em algoritmos, em pipelines k8s, mas a cada fala que eu ouvia, algo dentro de mim gritava, entende?

Precisamos refletir mais sobre isso como humanidade pensei comigo. E aqui estou, tentando escrever, não porque estava no meu planejamento do dia a dia, mas porque é como se estivesse compilando um código filosófico que insiste em rodar dentro de mim.

Dizem que sou uma exceção, mas será? Um técnico, um engenheiro, alguém mergulhado há mais de duas décadas em arquitetura e programação, mas que não se contenta em apenas projetar sistemas. Eu amo quando a conversa invade o terreno da filosofia, da ética, daquilo que não tem documentação oficial, não existe no github um README para nos orientar para onde ir, o que fazer, mas que precisa de interpretação densa e "humana", fico muito chato quando entro nesse assunto com os colegas.

A AI no Território Cinzento

E a inteligência artificial vindo com toda sua força desde do paper "Attention Is All You Need (Vaswani et al., 2017)" publicado em 2017, que define o modelo "Transformer" como uma nova arquitetura eliminando a necessidade de RNNs (Recurrent Neural Networks) redes recorrentes que era padrão em NLP (Natural Language Processing) usando mecanismo de atenção "self-attention" isso mesmo usado para capturar relações entre palavras independente da distância entre elas, e isso foi o divisor de águas algo extraordinário viria de tudo isso logo depois permitindo o treinamento dos modelos que conhecemos hoje GPT, Claude, Gemini, etc.

Tudo isso está justamente nesse território cinzento se é que me entende, ela é técnica, matemática, mas ao mesmo tempo nos obriga a perguntar o que é ser humano, o que é certo ou errado, qual é a definição de fato da palavra "inteligência" e "conhecimento" nos levando a questionar a refletir ainda mais sobre as "definições das palavras" e como ela é utilizada nos dias atuais.

Vejo muitos replicando sempre um "conceito absoluto" como uma imposição, tratando como se a palavra fosse temporal, ao meu ver é muito além disso, é atemporal se moldando a cada época como algo flexível, expansível, contínuo e evolutivo a palavra "inteligência" e "conhecimento" não foi, e nem é entendida de forma absoluta, é algo bem mais amplo, eu acredito que está presente desde dos processos biológicos primitivos até a possibilidade de se manifestar em sistemas artificiais entende ?

Claro que é somente uma opinião. Descobri que adoro falar sobre isso, eu sinto algo por dentro exatamente o mesmo sentimento quando estou godando.

Talvez soe estranho para alguns, mas escrever sobre ética em IA me dá a mesma energia que abrir o terminal, importar um pacote e começar a estruturar uma API em Go, sim Go também. A diferença é que aqui os termos são dilemas, provocações, perguntas que ficam em goroutines, isso mesmo ficam aguardando o retorno por que não temos uma resposta imediata definida absoluta. Precisam de reflexão e de tempo para serem processadas, entende ? Como fazemos em Go quando queremos rodar algo de forma assíncrona.

Todo mundo fala em ética quando o assunto é inteligência artificial é claro e nítido a preocupação de todos. "Perguntas como e os direitos autorais?", "Quem é responsável quando um sistema de IA comete um erro ou dano?", "Qual o limite da IA?" e tantas outras que conhecemos…

Fala-se em ética nos relatórios bonitos, nos PDFs corporativos, nos congressos internacionais e até nas legislações que estão nascendo, nada contra, porém eu prefiro irmos direto ao ponto, e a pergunta seria que estamos realmente falando de ética? Ou será que estamos apenas tentando organizar conflitos de interesses que se chocam o tempo todo?

O Mito da Ética Universal

Eu acredito que nunca vamos alcançar "a ética" em si. Ética como valor absoluto, como verdade universal, simplesmente não existe no mundo contemporâneo.O que existe são conflitos de ética. De um lado temos a ética da privacidade, de outro a ética da segurança. De um lado a ética da liberdade, de outro a ética do lucro.

O que é ético para uma cultura pode ser imoral para outra, o que é aceitável para uma empresa pode ser intolerável para uma comunidade. E o que conhecemos de AI hoje ela não nasce dentro de um vácuo neutro. A AI como conhecemos precisa ser alimentada, treinada e controlada por humanos e organizações, eu digo "ainda". E é aqui que o debate começa a ficar bem mais interessante.

Quem Realmente Decide?

Muitas pessoas pensam que, ao falarmos de ética na AI, trata simplesmente de ensinar a máquina a não fazer mal. Lindo isso não é ? Mas a pergunta real deveria ser feita é, quem define o que é "mal"? Quem tem o poder de determinar quais valores serão embutidos nos algoritmos? Quem controla a máquina, quem lucra com ela, quem perde é quem decide o que é bom? Essas quatro perguntas simples escancaram uma realidade que a maioria evita enfrentar. Entendo que é um assunto denso e complexo, mas temos que nos questionar todo o tempo como vamos lidar com tudo isso.

O Caso NYT vs OpenAI - Um Wake-up Call

Um exemplo recente mostra o tamanho do problema, olhem só o New York Times conseguiu na Justiça que a OpenAI guarde todos os chats, inclusive os temporários (ops temporários também? eles podem ser armazenados? Não são temporários ? Temporários para quem ? Fiquei realmente curioso e na dúvida), dos usuários. Olha o que isso significa, uma decisão judicial pode obrigar uma empresa global a alterar a forma como lida com dados de milhões de pessoas, sem que essas pessoas tenham voz ou escolha, imagina a dimensão disso.

O que era temporário, passa a ser permanente. Não era privado ? E agora passa a ser potencialmente acessível. Loucura não é ? Existe uma quebra na confiança e a vulnerabilidade aumenta, tanto para indivíduos quanto para empresas. Não dá para assumir lados, não estou querendo aqui entrar no mérito, estou só demonstrando a fragilidade que existe e tudo é muito novo e recente algo que veio para transformar radicalmente o que conhecemos.

E sabem o que é mais grave disso tudo até o momento não temos uma jurisprudência clara, não existe um marco regulatório sólido, não existe nem um consenso nos países imagina a nível global tratando de situações como esta. E é aqui que acredito que ficamos em um limbo isso mesmo em um for {} , ou seja em um loop infinito sujeitos a todo tipo de mazelas, interesses momentâneos de quem tem mais PODER.

Presos no Loop Infinito

Não tenho dúvidas da complexidade que representa tudo isso, e se observamos em um contexto global é ainda mais denso e complexo. O que vemos todo o tempo é que os interesses falam mais alto do que princípios universais. Para facilitar o entendimento temos. As empresas buscam lucro, governos buscam poder, comunidades buscam sobrevivência. E a AI (inteligência artificial), com toda sua capacidade de processamento e alcance, fica no centro de tudo e aí que vemos todos esses interesses se chocando todo o tempo como um game antigo "Asteroids" acreditem não é da minha época mas curto muito. É por isso que quando falamos de ética em AI sem falarmos de política, de economia e disputas de poder pode ter certeza que não estamos falando da "mesma ética" não mesmo.

Vejo muitos defendendo códigos de conduta e boas práticas como solução absoluta, eu penso que será mesmo possível ? Ou é somente uma cortina de fumaça, por que não estão fazendo as perguntas fundamentais para irmos direto ao ponto ? Quem controla? Quem lucra? Quem é impactado negativamente? Quem decide o que é bom? Se não tivermos coragem de responder a essas questões, qualquer conversa sobre ética será só retórica.

E o que percebo é que estamos abrindo mão, pouco a pouco, da nossa autonomia. Literalmente entregando nossos dados em troca de "conveniência". Eu também faço parte de tudo isso, eu também estou preso e refém de tudo, mas não quer dizer que não podemos refletir e discutir sobre tudo que está ocorrendo. Temos confiado em plataformas sem saber como de fato funcionam as regras. Percebo que estamos permitindo que eles definem os limites da tecnologia em nosso lugar, eu sinto que estou terceirizando nossa própria responsabilidade e em algum lugar bem distante, bem oculto bem longe estará cuidando da ética para nós. Mas será que está?

E fica sempre a reflexão ética em inteligência artificial não é um guia corporativo, não é um checklist de boas intenções e sim um belo e enorme campo de batalha como o game "CALL OF DUTY". Onde os valores se confrontam, onde interesses se impõem e onde o ser humano precisa tomar decisões complexas como quem será ou continuará sendo protagonista, entende ?

Não deveríamos mais fingir que ética em IA é só um capítulo bonito em relatórios corporativos, mas sim de quem vai decidir o futuro da nossa relação com a tecnologia, ou seja, nós ou eles?

Como um bom usuário e desenvolvedor claro, sabemos que todo código existe uma possibilidade gigantesca em possuir algum tipo de bug, principalmente códigos gerados por AI.

A questão aqui é, vamos continuar debugando nossa humanidade em produção ou finalmente vamos assumir o controle do nosso próprio código ético?

E vocês, o que pensam? Estamos sendo protagonistas ou apenas users de um sistema que não compreendemos totalmente?

Se chegaram até aqui, agradeço de coração e muito obrigado pela reflexão conjunta. Compartilhem suas visões nos comentários e vamos construir esse debate juntos, linha por linha, como um bom código colaborativo.

Espero que gostem 🚀🚀 ☺️

Cache em Memória usando Go ❤️

Jefferson Otoni Lima — Fri, 22 Aug 2025 19:41:24 +0000

Se tem uma coisa que sempre me salva no dia a dia, é cache em memória.

Quando a latência aperta e a performance precisa voar, um bom cache faz toda a diferença!

Ao longo do tempo, tive a oportunidade de testar várias implementações: go-cache, FreeCache, Ristretto, FastCache… e o mais legal do Go é que a inovação não para, sempre surgem novas opções!

Então, bateu aquela curiosidade e um pouco de desafio claro 😁, e para deixar tudo ainda mais empolgante, voltei a colaborar no projeto open source do Quick! 🚀

O Quick, é um roteador leve feito em Go, que está evoluindo para se tornar um framework web completo! 💡🔥

E fiquem ligados… em breve trago mais novidades sobre ele! 😍

O Quick está precisando de um middleware de cache, isso mesmo acreditem 🤣, e um dos seus pilares é não ter dependências externas, mantendo sua abordagem minimalista.

Juntando tudo isso, eu não aguentei… e quem me conhece sabe bem como eu sou 🤣🤣.

Resolvi reviver o que havia feito há um ano, testar novas ideias e evoluir o gcache para gocache. Já faz um tempo que venho brincando nas madrugadas com alguns algoritmos de cache e até gravei um vídeo sobre isso, acredita ? De tão gostoso é brincar com esta estrutura de dados.

📌 Quer ver na prática? Confere aqui => gcache no YouTube 🎥

O resultado do que fiz ? Tá tudo no post abaixo! 👇 Espero que gostem 🚀😃.

O que é Cache em Memória ?

O cache em memória é uma técnica essencial para otimização de desempenho em sistemas computacionais. Ele consiste no armazenamento temporário de dados diretamente na RAM, reduzindo a necessidade de acessos repetidos a fontes mais lentas, como bancos de dados ou sistemas de arquivos.

Ao manter os dados mais acessados na memória, eliminamos o gargalo de I/O (entrada e saída), permitindo respostas extremamente rápidas e um uso mais eficiente dos recursos computacionais. Lindo, não é? Para alcançar essa eficiência, é essencial utilizar linguagens de programação que ofereçam um gerenciamento robusto e controle eficiente sobre esses processos.

A linguagem que escolhi, alguém tem dúvidas ? Claro, foi o Go. ❤️

Embora o Go não seja uma linguagem de gerenciamento manual de memória como C ou Rust, ele ainda oferece um equilíbrio poderoso entre simplicidade, eficiência e controle de recursos. Mesmo contando com um Garbage Collector (GC), sua baixa latência e otimizações constantes permitem a criação de sistemas de cache em memória altamente performáticos, e vamos ver isso logo abaixo na prática.

Go se destaca por seu modelo de concorrência eficiente, utilizando goroutines e sync.Mutex / RWMutex para garantir acesso rápido e seguro ao cache, minimizando contenção e maximizando a escalabilidade.

Seu runtime altamente otimizado, aliado à capacidade de gerar binários leves e de alta performance, faz dele uma escolha excepcional para aplicações que exigem respostas rápidas, baixo consumo de CPU e um uso eficiente da RAM.

Quer saber mais sobre esse tópico ?

Escrevi alguns artigos sobre o assunto, e se você curte desempenho e concorrência em Go, recomendo dar uma olhada nesses dois:

📌 “Um pouco sobre Goroutines” → Explorando a magia das goroutines e como elas ajudam a escalar aplicações com eficiência.

📌 “Workloads: CPU-Bound e IO-Bound” → Um guia essencial para entender e otimizar cargas de trabalho no Go.

Espero que gostem! 😌🤗

O Go é a ferramenta fantástica, e para construirmos soluções robustas e simples ❤️.

O que é gocache ?

O gocache é um cache de memória fragmentada de alto desempenho para aplicativos Go, projetado para velocidade e eficiência. Ele foi otimizado para operações simultâneas de leitura e gravação, aproveitando fragmentação inteligente, otimizações de bloqueio (mutex) e gerenciamento eficiente de expiração para superar outras soluções de cache baseadas em Go.

A implementação do gocache é uma evolução do gcache, que comecei há um ano, inicialmente como um projeto didático e acadêmico. Desde então, fiz diversas versões diferentes de forma didática, refinando a arquitetura até chegar no gocache 😍.

Dentre as versões existe uma feita toda com Generics antes que me perguntem 🤗 e foi criado um outro repo chamado Benchmarking gocache é aqui que encontraram todas versões disponíveis e os tests que fiz até chegar em nossa V9 gocache , isso mesmo a versão que estamos usando hoje é a v9 🤗.

Um dos seus pilares é ser 100% minimalista e livre de dependências externas.

📌 gocache é uma biblioteca em Go, não um serviço como Redis!

Embora tanto o gocache quanto o Redis armazenem dados em memória, eles têm propósitos diferentes:

📌 gocache é uma LIB escrita em Go, projetada para ser embutida diretamente no seu código Go, funcionando como um cache local dentro da aplicação.

📌 Redis é um serviço externo que roda como um banco de dados em memória independente, permitindo cache distribuído e comunicação entre múltiplas instâncias.

Se você precisa de um cache ultrarrápido diretamente na sua aplicação Go, sem necessidade de conexões externas ou infraestrutura adicional, o gocache é a solução ideal! 🚀

Caso necessite de uma cache distribuído e compartilhado entre múltiplas aplicações, Redis pode ser uma melhor escolha.

Quer contribuir, sugerir melhorias ou compartilhar novas ideias? Fique à vontade! 🚀 Aprender e evoluir faz parte do processo, e vou adorar discutir otimizações e novas possibilidades! 😃

Podem enviar aqui issues gocache 🤗.

gocache vs. go-cache vs. freecache

Para validar o desempenho do gocache, realizamos benchmarks comparativos contra duas das bibliotecas de cache em memória mais conhecidas no ecossistema Go.

go-cache

Amplamente utilizado, fornece um cache baseado em mapa com controle de expiração.

freecache

Um cache baseado em segmentos de memória, eficiente para workloads de alta concorrência.

Cenário de Teste

Os benchmarks foram executados simulando um ambiente de alta demanda, onde diversas operações de SET e GET são realizadas de forma concorrente.

O objetivo era avaliar a eficiência da escrita (SET) a quantidade de operações por segundo e tempo médio de execução. A eficiência da leitura (GET) e o tempo médio de recuperação dos dados. O impacto da concorrência como o cache responde sob alta carga.

Benchmark

Resultados dos Benchmarks (3 segundos de execução)

LIBS. SET Ops SET ns/op GET Ops GET ns/op Observações

gocache 24,317,970 248.9 ns/op 14,749,851 270.8 ns/op 🏆 Very fast write, good read

go-cache 16,311,879 389.9 ns/op 13,021,398 277.5 ns/op 🚀 Excellent reads, slow writes

freecache 23,577,146 293.9 ns/op 8,554,900 395.8 ns/op ❌ Decent write, slow read

O gocache foi a implementação mais rápida em escrita (SET), conseguindo 24,3M de operações em 3s com um tempo médio de 248.9 ns/op, superando go-cache (389.9 ns/op) e FreeCache (293.9 ns/op). Esse desempenho demonstra a eficiência da estratégia de shards e mutexes bem otimizados, minimizando contenção e garantindo operações mais rápidas.

O go-cache teve um desempenho razoável na leitura, processando 13M de GETs em 3s com um tempo médio de 277.5 ns/op. Apesar de ser significativamente mais lento na escrita, seu modelo baseado em mapas de memória com RWMutex ajuda a reduzir o overhead em workloads voltadas para leitura de dados.

O FreeCache apresentou o pior tempo de leitura, com um GET médio de 395.8 ns/op, tornando-o menos eficiente para cargas de trabalho intensivas em leituras. Apesar de ser competitivo na escrita (23,5M de SETs em 3s), sua abordagem baseada em segmentação de memória pode resultar em fragmentação e maior overhead ao recuperar os dados armazenados.

O gocache demonstrou ser a melhor escolha para cenários onde a velocidade de escrita é crítica, sendo cerca de 36% mais rápido que o go-cache e 18% mais rápido que o FreeCache em operações de SET. Além disso, o gocache manteve uma boa performance em GETs, tornando-se uma solução balanceada e eficiente para aplicações de cache em memória. 🚀

Todos os testes detalhados podem ser encontrados no repositório:

Benchmark completo no GitHub

gocache X go-cache X freecache

Exemplo

Para utilizar o gocache, basta fazer a chamada direto do seu code Go

$ go mod init myprojet

$ go mod tidy

📌 Para acessar basta entrar aqui gocache 🚀

O gocache utiliza uma estratégia baseada em shards e um ring buffer para garantir alto desempenho e evitar contenção excessiva de locks.

estrutura dados gocache

Cada shard é uma partição independente do cache, possuindo sua própria estrutura de sincronização (RWMutex) e um ring buffer para rastrear a expiração dos itens. O ring buffer permite um gerenciamento eficiente de itens expirados sem precisar percorrer todo o cache.

Algoritmos de Hash Mais Usados em Cache em Memória

Os algoritmos de hash desempenham um papel essencial no desempenho de caches em memória, sendo responsáveis por transformar chaves em identificadores únicos para recuperação eficiente de dados. Escolher o algoritmo certo pode influenciar diretamente a velocidade das operações de SET e GET, consumo de memória e concorrência.

📊 Comparação de Algoritmos de Hash

🧮 Algoritmo | ✅ Melhor Para | 🚀 Ponto Forte

🔹 FNV-1a | 🔑 Chaves curtas (≤10 caracteres) | ⚡ Baixo overhead e simplicidade

🔹 xxHash | 🏗️ Chaves longas (>10 caracteres) | ⚡ Rápido e eficiente strings longas

🔹 MurmurHash3 | 🎲 Estruturas de dados probabilis. | 🎯 Boa dispersão e baixa colisão

🔹 CityHash | 📚 Indexação de grandes volumes | 🏎️ Ótimo para CPUs modernas

🔹 MetroHash | 🌐 Telecom e redes | 📡 Alto desempenho tráfego massivo

O FNV-1a é uma variante do algoritmo Fowler-Noll-Vo, projetado para ser rápido e eficiente em CPUs modernas. Ele opera aplicando XOR e multiplicações para espalhar os bits da chave de forma uniforme.

fnv1aHash utilizado no gocache

O xxHash é um algoritmo altamente otimizado que processa dados em blocos de 4 ou 8 bytes, reduzindo significativamente a latência para chaves longas. Ele usa operações bitwise e multiplicações otimizadas para arquitetura moderna de CPU.

xxHash64

O MurmurHash3 usa um esquema de mistura de bits para produzir distribuições uniformes de hashes, minimizando colisões. Ele é altamente eficiente em estruturas como bloom filters e tabelas hash distribuídas.

O CityHash, desenvolvido pelo Google, é otimizado para arquiteturas x86 e ARM modernas, utilizando instruções vetorizadas (SSE e AVX) para aumentar a velocidade. Ele é altamente eficiente para grandes volumes de dados.

O MetroHash é um hash projetado para alta velocidade e baixa latência, sendo usado em redes de telecomunicações e aplicações que requerem alto throughput. Ele é baseado em técnicas de processamento paralelo para maximizar a performance

Conclusão

O uso de cache em memória é uma estratégia essencial para aplicações de alto desempenho. O gocache implementa um sistema eficiente baseado em shards, mutexes e um ring buffer para expiração de itens, garantindo baixo overhead. Durante os testes, analisamos diferentes técnicas de hashing e validamos a melhor abordagem para manter um desempenho consistente.

Ainda sigo observando e testando mais possibilidades a medida que vou estudando e aprendendo, recebo muitos comentários e sugestões, e vou testando e subindo em um repo de benchmarking que pode se encontrado aqui Benchmark gocache.

Se você trabalha com Go e precisa de um cache de alto desempenho, experimente o gocache e compartilhe seu feedback! 🚀

Espero que gostem 🚀🚀 ☺️

Artificial Intelligence – Exploring the Future and Its Implications

Jefferson Otoni Lima — Wed, 07 May 2025 05:12:37 +0000

“The greatest revolution of our time is not industrial, nor digital — it’s cognitive. And the protagonist is the infamous Artificial Intelligence.”

🚀 This post is an expanded summary of our YouTube video.

We recorded a special episode to discuss the real impact of Artificial Intelligence on society, the economy, and the future of software development. Now, with new insights and terms that emerged after the recording — like “Vibe Coding” — we’ve decided to expand the conversation here.

🎥 Want the full video experience?
👉 Check it out on YouTube: Exploring Modern AI

Artificial Intelligence - From Sci-Fi to Reality

AI is no longer a sci-fi concept. It’s one of the most powerful forces shaping modern society — from voice assistants and recommendation engines to medical diagnostics and artistic creation, AI is transforming our world at an increasingly fast pace.

In this post, you’ll embark on a complete journey through the AI universe: from its historical roots to social and ethical impacts, practical applications, and visions of the future. Our goal is to deliver a critical, in-depth, yet accessible view of how AI is reshaping the present — and what it means for tomorrow.

What Is Artificial Intelligence, Anyway?

Artificial Intelligence is a branch of computer science focused on building systems capable of performing tasks that typically require human intelligence — such as pattern recognition, decision-making, problem-solving, understanding natural language, and even creating art.

AI can be classified into different levels:

Narrow AI: Specialized in a specific task (e.g., facial recognition, automatic translators).
General AI (AGI): Capable of performing any intellectual task that a human can.
Superintelligent AI: A hypothetical future AI that surpasses human intelligence in all aspects.

We currently live in the era of narrow AI, but rapid progress is steering us toward broader and more autonomous systems.

A Brief History of AI - From Philosophy to the Data Revolution

1950 – Alan Turing proposes the Turing Test, asking: “Can machines think?”
1956 – The Dartmouth Conference officially marks the birth of AI as an academic field.
1960s–1980s – Symbolic AI and logic-based systems see limited progress.
1997 – IBM’s Deep Blue defeats world chess champion Garry Kasparov.
2012 onward – The deep learning boom begins, with powerful neural networks fueled by more data and computing power.
2016 – DeepMind’s AlphaGo defeats Go champion Lee Sedol, showcasing reinforcement learning’s power.

Since then, models like GPT (OpenAI) and PaLM (Google DeepMind) have begun generating text, images, code, and even music. Welcome to the era of generative AI — where machines no longer just solve problems, they create.

Generative AI and LLMs - When Machines Learn to Create

LLMs (Large Language Models) — such as GPT-3, GPT-4, Claude, Gemini, LLaMA, and others — are trained on billions or even trillions of words from the internet. These models learn linguistic patterns and predict the next word, phrase, or paragraph.

As a result, they can:

Write texts
Answer questions
Translate languages
…and yes, even write code!

All you need is a simple natural language prompt — the model returns functions, scripts, entire APIs.
First reaction? “Whoa!” That’s what most people say when they see it in action.

Welcome to the new age of software development — the era of “Vibe Coding”, where ideas become code through natural language and AI.

This term didn’t exist when we recorded the video, but we had to include it — it perfectly captures this shift: programming is becoming less about syntax and more about creativity, collaboration, and fluid interaction between humans and machines.

🎥 Want the full video experience?
👉 Check it out on YouTube: Exploring Modern AI

The Impact Is Huge

Chatbots have become more natural and helpful

Translation tools now reach near-human fluency
Content creators have powerful tools to scale creativity
Developers code with AI assistants like GitHub Copilot and Cursor AI

Since our video, the pace has only accelerated

Claude 3.5 Sonnet, Gemini, GPT-4o — new models flood the market.
Tools like Windsurf allow you to talk naturally with your codebase.
JetBrains IDEs (like GoLand) now have native AI assistants.

We’re witnessing a shift programming is evolving into a dialogue, driven by context and intention, not just syntax.

This post goes beyond our video it’s an expanded reflection on the era in which AI is no longer just a tool but a protagonist in the creative and technical process of building software.

Ethical Dilemmas and Machine Power

The rise of AI brings complex and deeply human questions:
🔐 Privacy & Surveillance: Facial recognition is used to monitor crowds. Where do we draw the line?
⚖️ Algorithmic Bias: AI trained on human data inherits our biases — racial, gender, economic.
🤖 Autonomy: Should AI decide who gets a transplant, a loan — or fires a weapon in war?
💼 Tech Unemployment: Which jobs will disappear? How do we prepare future generations?

These aren’t just technical questions — they’re ethical ones. The field of AI ethics is now urgent and interdisciplinary, involving engineers, philosophers, sociologists, and lawmakers.

AI vs. Humans - Complement or Replacement?

AI can simulate intelligence — but not consciousness, empathy, or intuition. At least, not yet.

Imagine a doctor and an AI analyzing the same scan. The algorithm might detect invisible patterns, but only the doctor understands the patient’s emotional history, beliefs, and social context. Human intelligence is contextual, emotional, imperfect — and that’s what makes it irreplaceable.

The best future is collaborative, not competitive — humans augmented by AI, not replaced by it.

The Big Tech Players: Who Controls AI?

Companies like OpenAI, Google DeepMind, Meta, Amazon, and Microsoft are racing for dominance in AI.

These corporations:

Invest billions in R&D
Control the data used to train models
Set the rules of what AI can and cannot do

This raises critical questions:

Is AI too concentrated in too few hands?
How do we ensure transparency and access?
Is civil society represented in these decisions?

The debate over open vs. closed AI (e.g., Hugging Face vs. OpenAI) is just beginning — and it will shape our future.

Real-World Applications of AI 🌍

🩺 Healthcare - Cancer, cardiac, and neurological diagnoses with superior accuracy; AI-assisted surgeries; large-scale scan analysis; personalized treatments using genomic data
⚖️ Justice - AI analysis of court decisions and petitions helps speed up processes and improve consistency
🌱 Agriculture - Sensors, drones, and predictive models for climate, soil, and pest monitoring; optimized harvests and less waste
📚 Education - Personalized AI tutors that adapt to individual learning styles, boosting inclusion and engagement
🎨 Art & Music - AI composes music, paints, illustrates, writes scripts — expanding human creativity
💼 Business - Customer service automation, market behavior prediction, fraud detection, decision-making support
🚗 Mobility - Autonomous vehicles, traffic management, driver assistance, logistics powered by real-time AI
💻 Software Development - Code generation from natural language, smart IDE assistants, automated testing and documentation
🧬 Molecular Computing - Drug discovery acceleration, protein simulations, molecular interaction analysis, advanced genetic engineering
🏭 Industry - Predictive maintenance, automated quality control via computer vision, real-time supply chain optimization
🛰️ Space & Science - AI in space missions, astronomy image analysis, exoplanet discovery, particle physics simulations
🛡️ Cybersecurity - Threat detection, automated responses, vulnerability scanning based on behavioral patterns

AI is leaving the labs and impacting real life — at scale.

The Future of AI What’s Coming Next?

Here are some of the most promising (and challenging) frontiers:

Artificial General Intelligence (AGI) - A broader AI capable of learning multiple skills
Explainable AI (XAI) - Algorithms that explain how they make decisions — crucial in fields like law and healthcare
Creative AI - Generating original scripts, books, games, videos, and art
Autonomous AI & Agents: Systems that interact with APIs, apps, and humans in real time

And beyond that:

Quantum AI
Biotech integration
Brain-machine interfaces

Yes — we’re just getting started.

Final Thoughts: Opportunity or Threat?

Artificial Intelligence is neither good nor bad by nature — it reflects the intentions of its creators and the data it’s trained on. Like fire, it can warm or destroy.

So we must:

Educate society about AI from an early age

Create democratic and transparent regulations
Encourage diversity in AI development teams
Keep humans at the center of technological decisions

The future of AI is still being written — and all of us: engineers, educators, artists, politicians, parents, and children, have a role to play.

Want More?

If you’re passionate about AI and want to explore more content, tutorials, tools, and case studies — follow us on YouTube and across our networks.

The revolution has already begun.
The only question is:
Will you be a spectator or a protagonist?

🎥 Want the full video experience?
👉 Check it out on YouTube: Exploring Modern AI

Inteligência Artificial - Explorando o Futuro e Suas Implicações

Jefferson Otoni Lima — Wed, 07 May 2025 03:12:29 +0000

“A maior revolução da nossa era não é industrial, nem digital na verdade é cognitiva. E a protagonista é a famigerada Inteligência Artificial.”

🚀 Este post é um resumo expandido do nosso vídeo no YouTube

Gravamos um episódio especial para discutir o impacto real da Inteligência Artificial na sociedade, na economia e no futuro do desenvolvimento de software. Agora, com novas reflexões e termos que surgiram após a gravação como o "Vibe Coding" decidimos ampliar essa conversa por aqui.

Se você quiser a experiência completa em vídeo, assista ao episódio no YouTube:
🎥 Confira o vídeo completo no YouTube:
👉 youtube - Explorando a AI Moderna

A Inteligência Artificial (IA) deixou de ser um conceito de ficção científica para se tornar uma das forças mais influentes na transformação da sociedade contemporânea. Presente nos assistentes de voz, algoritmos de recomendação, sistemas de diagnóstico médico e até na criação de arte, a IA está moldando o mundo ao nosso redor em um ritmo acelerado e muitas vezes difícil de acompanhar.

Neste post, você vai embarcar em uma jornada completa pelo universo da IA: da sua origem histórica aos impactos sociais e éticos, passando por suas aplicações práticas e visões sobre o futuro. Nosso objetivo é apresentar uma visão crítica, profunda e acessível para qualquer pessoa interessada em entender como a inteligência artificial está transformando o presente — e o que isso significa para o amanhã.

O que é Inteligência Artificial, afinal?

A Inteligência Artificial é um ramo da ciência da computação que se concentra no desenvolvimento de sistemas capazes de executar tarefas que normalmente exigiriam inteligência humana, como reconhecer padrões, resolver problemas, tomar decisões, compreender linguagem natural e até mesmo criar arte.

Ela pode ser classificada em diferentes níveis
• IA fraca (ou estreita): especializada em uma tarefa específica (ex: reconhecimento facial, tradutores automáticos).
• IA forte (ou geral/AGI): teria a capacidade de realizar qualquer tarefa intelectual que um ser humano consiga.
• IA superinteligente: um conceito hipotético de IA que ultrapassaria a inteligência humana em todos os aspectos.

Atualmente, vivemos a era da IA estreita, mas os avanços estão nos aproximando rapidamente de cenários mais amplos e autônomos.

Breve História da IA das raízes filosóficas à revolução dos dados

A ideia de máquinas pensantes não é nova. Desde a Antiguidade, filósofos especulam sobre a possibilidade de reproduzir a mente humana. No entanto, o campo da IA só começou a se estruturar no século XX.

1950 - Alan Turing propõe o Teste de Turing, perguntando: “As máquinas podem pensar?”.
1956 - A conferência de Dartmouth marca o nascimento oficial da IA como disciplina acadêmica.
Décadas de 60 a 80 - Avanços em regras simbólicas e lógica, mas com resultados limitados.
Anos 90 - O xadrez tornou marco. Em 1997, o Deep Blue da IBM derrota o campeão Garry Kasparov.
2012 em diante - A explosão do deep learning com redes neurais profundas, graças ao aumento do poder computacional e grandes volumes de dados, revoluciona o campo.
2016 - O AlphaGo da DeepMind derrota o campeão mundial Lee Sedol no jogo Go, marcando um salto impressionante na IA com o uso de redes neurais e aprendizado por reforço.

Desde então, modelos como o GPT (OpenAI) e o PaLM (Google DeepMind) passaram a gerar textos, imagens, códigos e até música de forma autônoma. Estamos oficialmente na era da IA generativa — um novo capítulo onde máquinas não apenas resolvem problemas, mas criam.

IA Generativa e os LLMs quando a máquina aprende a criar

Os LLMs (Large Language Models), como GPT-3, GPT-4, Claude, Gemini, LLaMA, entre outros, são modelos treinados com bilhões — às vezes trilhões — de palavras retiradas da internet. Esses modelos aprendem padrões da linguagem para prever qual será a próxima palavra, frase ou até parágrafo.

Com isso, são capazes de gerar textos, responder perguntas, traduzir idiomas e… sim, até escrever código!

Isso mesmo: código. Basta descrever o que você quer em linguagem natural e o modelo gera funções, scripts, APIs inteiras. Tudo a partir de um simples prompt.

"Carakas!" É o que muita gente pensa ao ver isso funcionando pela primeira vez.

Estamos entrando em uma nova era no desenvolvimento de software a era do “Vibe Coding”, onde ideias viram código com o poder da linguagem natural e da inteligência artificial.

Esse termo ainda não existia quando gravamos o vídeo, mas achamos importante destacá-lo aqui, porque ele define perfeitamente o momento que estamos vivendo. Uma revolução onde programar é menos sobre sintaxe e mais sobre criatividade, colaboração e fluidez entre humanos e máquinas.

🎥 Confira o vídeo completo no YouTube:
👉 youtube - Explorando a AI Moderna

O impacto disso é gigantesco

Chatbots se tornaram mais naturais e úteis;
Tradutores automáticos se aproximaram da fluência humana;
Criadores de conteúdo têm ferramentas poderosas para acelerar e escalar a criatividade;
Desenvolvedores escrevem códigos com apoio de assistentes como GitHub Copilot ou Cursor AI.

Quando gravamos o episódio, o cenário da inteligência artificial já era impressionante. Mas, como sabemos, nesse universo tudo evolui rápido e desde então muita coisa mudou.
Hoje vivemos uma verdadeira corrida tecnológica o mercado foi inundado por modelos cada vez mais potentes como o Claude 3.5 Sonnet, o avanço acelerado do Gemini e do GPT-4o, e surgiram ferramentas como o Windsurf, que transformam qualquer projeto em uma conversa natural com seu código.

Além disso, as IDEs também entraram no jogo o ecossistema JetBrains, incluindo o GoLand, já conta com assistentes de IA integrados isso mesmo, nativos na própria IDE. E embora haja um custo para usar esses recursos, o mais importante é que o primeiro passo foi dado: a programação está deixando de ser apenas sintaxe e se tornando diálogo, contexto e intenção.

Por isso, esse post vai além do conteúdo do vídeo. É um resumo expandido, com reflexões atualizadas sobre a era em que vivemos uma era em que a inteligência artificial deixou de ser suporte e passou a ser protagonista no processo criativo e técnico do desenvolvimento de software.

Dilemas Éticos e o Poder das Máquinas

A ascensão da IA levanta dilemas que não são meramente técnicos — são profundamente humanos:

Privacidade e vigilância Sistemas de reconhecimento facial já são usados para monitorar multidões. Onde está o limite?

Viés algorítmico: IAs treinadas em dados humanos herdam nossos preconceitos. Já houve casos de discriminação racial, de gênero e econômica amplificada por algoritmos.
Autonomia de decisão: Devemos permitir que uma IA decida quem recebe um transplante de órgão, um crédito bancário ou mesmo atire em um campo de batalha?
Desemprego tecnológico: Quais profissões vão desaparecer? E como preparar as próximas gerações para um mundo onde a IA será ubíqua?

Essas perguntas não têm respostas fáceis. Por isso, a ética da IA se tornou um campo de estudo urgente, envolvendo engenheiros, filósofos, sociólogos e legisladores.

IA x Ser Humano - Complemento ou Substituição?

A IA pode simular inteligência, mas não consciência, empatia ou intuição. Pelo menos por enquanto.

Imagine um médico e uma IA analisando um mesmo exame: o algoritmo pode encontrar padrões invisíveis ao olho humano, mas só o médico entende o histórico emocional do paciente, suas crenças, angústias e contexto social. A inteligência humana é situada, afetiva, imperfeita — e é isso que a torna essencial.

Por isso, o ideal não é que a IA substitua humanos, mas potencialize nossa capacidade. A colaboração entre homem e máquina é o futuro mais promissor.

O Papel das Big Techs - Quem controla a IA?

Empresas como OpenAI, Google DeepMind, Meta, Amazon e Microsoft estão travando uma corrida pelo domínio da inteligência artificial.

Essas corporações:

Investem bilhões em P&D;
Controlam os dados usados no treinamento dos modelos;
Definem os padrões e os limites do que é possível fazer com IA.

Isso levanta questões importantes

A IA está concentrada demais nas mãos de poucos?
Como garantir a transparência e o acesso democrático a essas tecnologias?
A sociedade civil está representada nessas decisões?

A discussão sobre IA aberta vs. fechada (como Hugging Face vs. OpenAI) está só começando — e será decisiva para o futuro.

Casos Reais e Aplicações Incríveis da IA

🩺 Medicina, com diagnósticos de câncer, doenças cardíacas e degenerativas com precisão superior à de especialistas, além de apoio em cirurgias, análise de exames em larga escala e tratamentos personalizados com base em dados genômicos;

⚖️ Justiça, por meio da análise automatizada de jurisprudências, decisões e petições judiciais para apoiar juízes e advogados, acelerando processos e promovendo mais consistência nas decisões;

🌱 Agricultura, com sensores, drones e modelos preditivos que monitoram clima, solo e pragas, otimizando colheitas e reduzindo desperdícios com agricultura de precisão;

📚 Educação, através de tutores personalizados com LLMs que se adaptam ao estilo de aprendizado de cada aluno, promovendo inclusão, engajamento e avanços no ensino remoto;

🎨 Música e arte, com algoritmos que compõem trilhas sonoras, criam ilustrações, pintam em estilos específicos e até escrevem roteiros, ampliando o potencial criativo humano;

💼 Negócios, com IA aplicada ao atendimento ao cliente, análise preditiva de comportamento de mercado, detecção de fraudes, automação de processos e suporte à tomada de decisão;

🚗 Mobilidade, com veículos autônomos, gerenciamento inteligente de tráfego, assistentes de direção e planejamento logístico em tempo real com base em IA embarcada;

💻 Programação, com geração de código a partir de linguagem natural, assistentes inteligentes integrados às IDEs, automação de testes, refatoração e até geração de documentações técnicas;

🧬 Computação molecular, com IA acelerando a descoberta de novos medicamentos, simulações de proteínas, análise de interações moleculares e projetos de engenharia genética de altíssimo nível;

🏭 Indústria e manufatura, com manutenção preditiva, controle de qualidade automatizado por visão computacional e otimização da cadeia de suprimentos em tempo real;

🛰️ Espaço e ciência, com modelos de IA auxiliando em missões espaciais, análise de imagens astronômicas, descoberta de exoplanetas e simulações de física de partículas;

🛡️ Segurança cibernética, com detecção proativa de ameaças, respostas automatizadas a ataques e análise de vulnerabilidades com base em padrões de comportamento e anomalias.

A IA está saindo dos laboratórios e impactando a vida real, em escala.

O Futuro da Inteligência Artificial o que vem por aí?

Entre as tendências mais promissoras (e também mais desafiadoras), estão:

IA Generalista (AGI), uma IA que aprende de forma ampla, com múltiplas habilidades.
IA Explicável (XAI), algoritmos que mostram como tomam decisões — essencial para áreas críticas como medicina e justiça.
IA Criativa, geração de roteiros, livros, vídeos, jogos e conteúdo 100% inédito.
IA Autônoma e Agentes Inteligentes, sistemas que tomam decisões e interagem com APIs, sistemas e pessoas em tempo real.

Além disso, a IA quântica, a fusão com biotecnologia e o surgimento de interfaces cérebro-máquina indicam que estamos só no começo.

Considerações Finais - Oportunidade ou Ameaça?

A Inteligência Artificial não é boa nem má por natureza ela é reflexo de quem a cria, de como é treinada e de para que é usada. Assim como o fogo pode aquecer ou destruir, a IA pode empoderar ou oprimir.

Por isso, precisamos:

Educar a sociedade sobre IA desde cedo;
Criar regulações transparentes e democráticas;
Incentivar a diversidade nas equipes de IA;
Manter o ser humano no centro das decisões tecnológicas.

O futuro da IA ainda está em construção, e todos nós engenheiros, educadores, artistas, políticos, pais e filhos temos um papel vital nesse processo.

Quer ir além?

Se você se interessa por Inteligência Artificial e quer acompanhar conteúdos aprofundados, tutoriais, estudos de caso e análises de ferramentas, fique ligado aqui no canal e nas nossas redes.

A revolução já começou. A pergunta é: você vai ser espectador ou protagonista?

Se você quiser a experiência completa em vídeo, assista ao episódio no YouTube:
🎥 Confira o vídeo completo no YouTube:
👉 youtube - Explorando a AI Moderna

Workloads: CPU-Bound and IO-Bound

Jefferson Otoni Lima — Sat, 01 Mar 2025 22:43:21 +0000

What is a Workload? And why are we talking about it?

Could it be to better understand when to use concurrency in Go❤️?

The answer to this question is yes 😁 and not just for Go, but for any technology that deals with parallelism and concurrency 😁.

A workload refers to the amount of work an application needs to perform. In other words, a workload is the set of tasks or operations an application must execute to meet its requirements👊🏼.

Workloads can be distributed across multiple processes or threads to improve application performance. For example, if an application has a CPU-intensive workload, it can be broken down into smaller parts that run in parallel across multiple cores.

Workloads can also be distributed across multiple machines to enhance application scalability. For instance, if an application has an I/O-intensive workload, it can be distributed among several servers to improve user request handling capacity.

Therefore, we can say that a workload is the amount of work an application needs to process, and it plays a crucial role in choosing the right approach for concurrency or parallelism. Proper workload distribution can significantly improve performance and scalability.

Concurrency in Go is incredibly powerful yet simple—this was the intention of the engineers who designed Go. Many problems can be solved far more efficiently using concurrency, and this is where Go shines. That’s why Go has become a God when it comes to backend concurrency.

Because of this, problems in this domain can be solved with high efficiency while using very few computational resources.🚀

Example of a Worker in Go:

Every Go program starts by defining the package and importing the necessary libraries.

package main

import "fmt"
import "time"

This function is our Worker, which runs concurrently as a goroutine while the rest of the code continues execution.

Let's break down the parameters and understand channels, which are the mechanism for safely passing values between goroutines:

jobs <-chan int: This is an input channel (receive-only).
results chan<- int: This is an output channel (send-only).
result2 chan string: This is a bidirectional channel, meaning that inside the function, you can both send and receive values through it.

Worker Function in Go

func worker(id int, jobs <-chan int, results chan<- int) {
    for j := range jobs {
        fmt.Println("worker:", id, "started  job", j)
        time.Sleep(time.Second)
        fmt.Println("worker:", id, "finished job", j)
        results <- j * 8
    }
}

Here, we initialize our program by declaring the channels.

We launch multiple goroutines of our worker to distribute the workload efficiently.

In this case, we are spawning three concurrent workers.

Main Function: Spawning Workers and Distributing Workloads

func main() {
        jobs := make(chan int, 100)
        results := make(chan int, 100)

        // Launching 3 worker goroutines
        for w := 1; w <= 3; w++ {
                go worker(w, jobs, results)
        }

        // Sending 5 jobs to the workers
        for j := 1; j <= 5; j++ {
                jobs <- j
        }

        close(jobs)

        // Collecting results from the workers
        for a := 1; a <= 5; a++ {
                <-results
        }
}

Go is designed to handle concurrency efficiently and safely.

Concurrency is achieved through goroutines, which are small pieces of code that can run concurrently but not necessarily in parallel.

Goroutines are lightweight in terms of resources, meaning that thousands of them can be created in a single program without degrading performance.

The Go runtime decides whether a goroutine runs concurrently or in parallel across multiple CPU cores, depending on resource availability and the number of physical cores available.

Communication Between Goroutines

Communication between goroutines is done through channels, synchronization mechanisms that allow safe data transfer between goroutines. This enables goroutines to work together, sharing data and cooperating to achieve a common goal.

Concurrency in Go’s net/http Package

The net/http package works concurrently, scaling requests and distributing computational resources more effectively.

If you're interested in benchmarks on this topic and comparisons with different programming languages, check out this link:

👉 benchmark.

Here, you can see the power of net/http when abstracted by the Quick framework (quick), developed in Go, which utilizes net/http.

It’s also compared against Elixir, a functional and concurrent programming language.

Understanding Workloads in Concurrency

When talking about concurrency, it is important to highlight different types of workloads, as they act as a compass to help us determine the right balance when solving concurrency-related problems.

A thread can handle two types of workloads (Workloads):

✅ CPU-Bound

✅ I/O-Bound

CPU-BOUND

This type of workload never puts a thread into a waiting state.

It is constantly performing calculations. A thread computing pi to the eighteenth power, for example, would be CPU-limited.

(Fun fact: Emma Haruka Iwao is a Japanese computer scientist and Cloud Developer Engineer at Google. In 2019, she calculated the most precise value of pi ever recorded, reaching 31.4 trillion digits.)

For CPU-bound workloads, parallelism is needed to maximize simultaneous execution. However, simply increasing the number of goroutines will not help and may even degrade performance.

This happens because of the latency cost (the time spent) in moving goroutines in and out of the OS thread.

I/O-BOUND

In this type of workload, threads enter waiting states.

A good example is network requests or system calls.

A thread that needs to:

Access a database
Perform synchronization events (mutex, atomic)
Communicate over a network

…will have to wait, making it an I/O-bound workload.

For this type of workload, parallelism is not necessary to achieve concurrency—a single physical core is often enough to efficiently handle multiple goroutines.

Goroutines enter and exit waiting states as part of their workload.

Having more goroutines than physical cores can speed up execution since the latency cost of moving goroutines between OS threads is not creating an additional bottleneck.

Instead, work is naturally interrupted, allowing another goroutine to utilize the same physical core instead of letting it remain idle.

CONCLUSION

The Go programming language provides powerful and easy-to-use tools for handling concurrency, making it an excellent choice for high-performance and scalable applications.

Understanding when to use parallelism across multiple physical cores vs. when simple concurrency on fewer cores (or a single core) is sufficient is essential.

Go offers various patterns to balance these workloads, and in some cases, you may need a combination of both approaches.

Want to dive deeper into this topic? Check out this post:

👉 Simplifying Complexity: The Beginning

Hope you like it!! 🚀😃

Getters e setters muito conhecido em “Java” é comum o seu uso em Go?

Jefferson Otoni Lima — Fri, 08 Sep 2023 04:33:27 +0000

Antes de iniciarmos temos que definir alguns conceitos importantes que a pergunta nos força a refletir.

Os conceitos de "getters" e "setters" são fundamentais para a programação orientada a objetos (OOP) e estão intimamente ligados ao princípio do encapsulamento, um dos pilares da OOP. O encapsulamento envolve a restrição do acesso direto a alguns dos componentes de um objeto e a provisão de métodos públicos (como getters e setters) para manipular esses componentes.

Poderíamos dizer que a origem ao conceito de getters e setters se da com a criação do paradigma de programação orientado a objeto e elas emergiram na década de 1980 e evoluíram rapidamente. No entanto, linguagens como Smalltalk, uma das primeiras linguagens orientadas a objetos, já tinham conceitos que permitiam o encapsulamento de propriedades de objetos. Mais tarde, linguagens como C++ e Java popularizaram o uso de métodos específicos para acessar e modificar propriedades privadas, que se tornaram conhecidos como getters e setters.

Quando referenciamos ao getters e setters eles não são um "padrão arquitetural", eles são mais um padrão de design ou uma prática de desenvolvimento que facilita o encapsulamento. No entanto, eles são usados em muitos padrões de design e arquitetura. Por exemplo, no padrão de design "Bean" em Java, o uso de getters e setters é padrão.

Getters e setters permitem o controle sobre como um atributo é acessado ou modificado. Eles podem incluir lógica adicional, como validação, ou podem ser usados para criar atributos somente leitura e é este o motivo de sua utilização independente da linguagem de programação que venha utiliza-lo.

Sua utilização também podem ser vistos como verbosos, especialmente em linguagens onde a definição de cada getter e setter pode exigir várias linhas de código a mais. Além disso, o uso excessivo de getters e setters pode ser um sinal de que pode está fazendo muito ou violando o princípio da responsabilidade única.

Enquanto o conceito de encapsulamento é fundamental para a programação orientada a objetos, a forma como esse encapsulamento é implementado, seja através de getters e setters ou outros mecanismos, varia entre linguagens e frameworks.

Olha o exemplo feito em Smalltalk a primeira linguagem de Programação Orientada a Objeto como é escrito:

Object subclass: Pessoa [
    | nome idade |

    Pessoa class >> new [
        ^super new initialize
    ]

    Pessoa >> initialize [
        nome := ''.
        idade := 0.
    ]

    "Getters"
    Pessoa >> nome [
        ^nome
    ]

    Pessoa >> idade [
        ^idade
    ]

    "Setters"
    Pessoa >> nome: umNome [
        nome := umNome.
    ]

    Pessoa >> idade: umaIdade [
        idade := umaIdade.
    ]
]

Agora confira como é instânciada e chamado os métodos.

| jeff |
jeff := Pessoa new.
jeff nome: 'jeffotoni'.
jeff idade: 35.

Transcript show: jeff nome; cr.
Transcript show: jeff idade printString; cr.

No java teríamos algo assim:

public class Pessoa {

    private String nome;
    private int idade;

    public Pessoa() {
        this.nome = "";
        this.idade = 0;
    }

    // Getter para nome
    public String getNome() {
        return nome;
    }

    // Setter para nome
    public void setNome(String nome) {
        this.nome = nome;
    }

    // Getter para idade
    public int getIdade() {
        return idade;
    }

    // Setter para idade
    public void setIdade(int idade) {
        this.idade = idade;
    }
}

Agora olha como fica sua instância:

public static void main(String[] args) {
        Pessoa jeff = new Pessoa();
        jeff.setNome("jeffotoni");
        jeff.setIdade(35);

        System.out.println("Nome: " + jeff.getNome());
        System.out.println("Idade: " + jeff.getIdade());
    }

E em Go ?

Sabemos que Go não é orientado a objeto não da forma que conhecemos como Java, C++ ou C#. Para mais detalhes pode ler o meu post sobre este assunto clicando neste link: Go é orientado a objetos ?

Go não suporta classes e nem heranças ele não foi construído para um designer de paradigma orientado a objeto. No entanto, Go oferece recursos que permitem aos desenvolvedores alcançar objetivos semelhantes ao da programação orientada a objetos, principalmente através de structs e interfaces que também tem um comportamento diferente do que conhecemos nas linguagens de programação Java, C++ ou C#.

Em Go temos struct, uma struct é uma coleção de campos, que podem ter diversos tipos. Elas são comparáveis aos registros em algumas outras linguagens. Uma struct define um tipo de dados que agrupa variáveis relacionadas.

Logo abaixo uma struct pública e com campos públicos em Go.

type Pessoa struct {
    Nome  string // público
    Idade int    // público
}

Então, o que temos até o momento é uma forma de fazer polimorfismo utilizando "interface", encapsulamento de métodos e disponibiliza-los de forma dinâmica muito semelhante ao "Duck typing". E para complementar a grande maioria dos patterns possíveis a serem feitos em Go usam interface, dentre eles: Abstract Factory, Adapter, Builder, Bridge, Composite, Prototype , Decorator.

Logo abaixo um exemplo de utilização de interface, struct e método Go para facilitar nosso entendimento em nosso exemplo da struct Pessoa.

package main

import "fmt"

type Apresentavel interface {
    Apresentar() string
}

type Pessoa struct {
    Nome  string
    Idade int
}

func (p Pessoa) Apresentar() string {
    return fmt.Sprintf("Olá! Meu nome é %s e eu tenho %d anos.", p.Nome, p.Idade)
}

type Estudante struct {
    Pessoa
    Curso string
}

func (e Estudante) Apresentar() string {
    return fmt.Sprintf("Meu nome é %s, eu tenho %d anos e estudo %s.", e.Nome, e.Idade, e.Curso)
}

Em nosso exemplo acima tanto Pessoa quanto Estudante implementam a interface Apresentavel. A função main demonstra polimorfismo, pois tanto pessoa1 quanto pessoa2 são tratados como tipos Apresentavel, mas seus comportamentos são diferentes.

Confira nossa função main logo abaixo:

func main() {
    var pessoa1 Apresentavel = Pessoa{"Silver Gama", 28}
    var pessoa2 Apresentavel = Estudante{Pessoa{"jeffotoni", 21}, "Ciência da Computação"}

    fmt.Println(pessoa1.Apresentar())
    fmt.Println(pessoa2.Apresentar())
}

Caso queira executar e brincar basta clicar no neste link Polimorfismo em Go.

Em Go, a visibilidade de membros de uma struct (ou funções em um pacote) é controlada pela primeira letra do identificador. Se começar com uma letra maiúscula, é permitido ser exportado ou melhor acessada fora do pkg Go (equivalente a public em linguagens como Java); caso contrário, é unexported (semelhante a private) ou seja não poderá ser acessado fora do pkg Go.

Em nosso exemplo acima se criarmos um pacote as a primeira letra maiúscula do nome da nossa struct e seus respectivos campos isto significa que nossa struct é pública e poderá ser instanciada ou acessada de forma externa.

Go não tem uma sintaxe específica para getters e setters como algumas linguagens OOP. Em vez disso, você simplesmente usa métodos. Por causa das convenções de nomenclatura em Go, getters e setters normalmente não são prefixados com "Get" ou "Set" e podemos fazer da forma que convier e conforme a necessidade do projeto e cenários, porém alguns desenvolvedores preferem manter a sintaxe por uma melhor prática pois são poliglotas e conhecendo de OOP pode utilizar da mesma sintaxe para facilitar a legibilidade e o entendimento do seus códigos Go.

Antes de mostrar a abordagem com getters e setters vamos ver a abordagem mais direta e bem prática de como fazemos em Go.

package main

import (
    "fmt"
)

type Pessoa struct {
    Nome  string
    Idade int
}

func main() {
    jeff := Pessoa{}
    jeff.Nome = "jeffotoni"
    jeff.Idade = 35

    fmt.Println("Nome:", jeff.Nome)
    fmt.Println("Idade:", jeff.Idade)
}

Para acessar o Código basta clicar no link: Struct em Go.

Neste exemplo, Nome e Idade são campos exportados da struct Pessoa. Isso significa que você pode acessar e modificar esses campos diretamente, como demonstrado na função main, e quando criado um pacote em Go também isto é importante dizer.

Esta abordagem é mais direta e é frequentemente preferida em Go quando não há necessidade de lógica adicional ao definir ou obter o valor de um campo.

Só para reforçar, se criar um pkg em Go irá conseguir fazer import deste pkg em seu projeto e fazer a chamada da sua struct igual o exemplo do main acima.

Quando usar Getters e Setters em Go?

Só para reforçar estamos utilizando do conceito "getters e setters" não é obrigatório o seu uso com nomes específicos e nem sua obrigatoriedade para encapsulamento em Go você tem a liberdade de escolha, repetindo: "getters e setters é um padrão de design ou uma prática de desenvolvimento que facilita o encapsulamento".

Quando necessitar de validações, lógicas adicionais ao acessar ou modificar os campos, quando precisar fazer isto temos um bom motivo em deixar nossos campos da struct private ou seja com a primeira letra minúscula e criarmos métodos sejam eles com interface ou não, para fazer todo o controle e também podemos deixar a struct private para que todo seu controle seja feito pelo seu pkg.

Aqui temos duas abordagens diferentes campos da struct private e struct private.

Aqui o exemplo de uma struct publica que pode ser exposta e campos privados sendo controlados por métodos em Go:

type Pessoa struct {
    nome  string
    idade int
}

Agora observe nossos métodos como ficariam:

// Getter para nome
func (p *Pessoa) Nome() string {
    return p.nome
}

// Setter para nome
func (p *Pessoa) SetNome(nome string) {
    p.nome = nome
}

// Getter para idade
func (p *Pessoa) Idade() int {
    return p.idade
}

// Setter para idade
func (p *Pessoa) SetIdade(idade int) {
    p.idade = idade
}

Aqui temos getters e setters para os campos nome e idade da struct Pessoa. Eles são implementados como métodos da struct.

Olha aqui nossa função main utilizando nossos métodos:

func main() {
    jeff := &Pessoa{}
    jeff.SetNome("jeff")
    jeff.SetIdade(30)

    fmt.Println("Nome:", jeff.Nome())
    fmt.Println("Idade:", jeff.Idade())
}

A outra abordagem seria deixar a struct private desta forma não consegue acessar a struct diretamente somente através de métodos. Nesta abordagem temos uma função que faz o papel de um construtor. Em linguagens de programação orientadas a objetos, como Java, C++ ou C# construtores são métodos especiais que são usados para inicializar uma instância de uma classe. Esses construtores permitem definir valores iniciais, alocar recursos, ou realizar outras tarefas de inicialização necessárias para o objeto.

Go, sendo uma linguagem que não é tradicionalmente orientada a objetos, não tem um conceito embutido de "construtor" como essas linguagens. No entanto, é comum em Go criar uma função que serve o mesmo propósito que um construtor em outras linguagens. Esta função geralmente começa com "New" (mas vai de projeto a projeto não é regra) e retorna uma instância da struct.

Confira o exemplo abaixo de como ficaria nossa função construtora e os métodos getters e setters.

type pessoa struct {
    nome  string
    idade int
}

Agora confira nosso "construtor" como ficaria:

func New(nome string, idade int) *pessoa {
    return &pessoa{nome: nome, idade: idade}
}

Nossos métodos ficaram assim:

// Getter para nome
func (p *pessoa) Nome() string {
    return p.nome
}

// Setter para nome
func (p *pessoa) SetNome(nome string) {
    p.nome = nome
}

// Getter para idade
func (p *pessoa) Idade() int {
    return p.idade
}

// Setter para idade
func (p *pessoa) SetIdade(idade int) {
    p.idade = idade
}

Agora vamos ver como fazemos a instanciação e chamamos isto em nosso main.

Confira o código abaixo:

func main() {
    jeff := New("jeffotoni", 35)
    fmt.Println("Nome:", jeff.Nome())
    fmt.Println("Idade:", jeff.Idade())
}

Gostaria de rodar o código completo click neste link: Go e construtor "New".

E as vulnerabilidades ?

Ao exportar structs e seus campos em Go (ou seja, torná-los públicos, começando com uma letra maiúscula), estamos permitindo que outros pacotes os acessem diretamente. Isso pode levar há algumas reflexões que irá precisar fazer quando estiver desenvolvendo seus pacotes em Go.

Encapsulamento Quebrado

Uma das principais preocupações é o potencial para quebrar o encapsulamento. Quando você exporta um campo, qualquer código fora do pacote pode alterá-lo diretamente. Se existir uma necessidade no meio do caminho ou seja não foi percebido antes de criar o pacote e precisar colocar ou criar uma lógica interna ou invariáveis que precisam ser mantidas, o acesso direto pode levar a estados inconsistentes ou inválidos, em outras palavras poderá quebrar seu pacote.

Manutenibilidade

Se outros pacotes começarem a depender diretamente dos campos exportados, pode ser difícil mudar a estrutura interna da sua struct no futuro. Qualquer mudança pode quebrar o código que depende dela.

Segurança

Em alguns casos, pode haver preocupações de segurança acredito que muito poucos mesmo. Por exemplo, se um campo exportado contiver informações sensíveis, ele poderia, em teoria, ser lido ou modificado por código mal-intencionado em outro pacote mas para isto ocorrer você precisaria instanciá-lo no pacote de alguma forma.

Escondendo Detalhes de Implementação

Ao exportar campos, você está expondo detalhes de implementação que talvez preferisse manter ocultos. Esconder detalhes de implementação pode tornar seu código mais fácil de usar e menos propenso a erros isto é fato.

Validações

Se certas validações ou lógicas devem ser aplicadas ao definir valores em sua struct, exportar campos diretamente contorna essas validações, a menos que você dependa de métodos de setter.

Conclusão

Só para reforçar utilizei do conceito "Getters e Setters" que é um padrão de designer para abordar como poderíamos encapsular nossas structs em Go, relembrando que não é obrigatório é somente uma prática de desenvolvimento que é bem comum dos desenvolvedores que veem de java para Go.

Ao projetar structs e pacotes em Go, é importante ponderar cuidadosamente as vantagens e desvantagens de exportar campos. Em muitos casos, a decisão dependerá das necessidades específicas e trade-offs do projeto.

Enquanto o Go certamente permite e, em alguns casos, incentiva o uso direto de campos exportados para simplicidade, há situações em que usar getters e setters é benéfico. O uso de getters e setters em Go, como em muitas outras linguagens, está relacionado a práticas de encapsulamento e controle sobre como os dados de uma struct ou tipo são acessados e modificados.

Espero que tenha gostado do resumo e uma breve introdução do que podemos fazer em Go quando o assunto é getters e setters. Qualquer observação, dica, melhoria etc.. no conteúdo por favor só enviar para melhora-lo ainda mais.

Proxies e API Gateway: Uma Profunda Jornada através do Tempo e Código

Jefferson Otoni Lima — Tue, 29 Aug 2023 12:50:40 +0000

Desde do inicio da era digital para web, a maneira como os sistemas se comunicam passou por várias transformações. Na última década, particularmente a partir da metade dos anos 2000, vivenciamos um bum na utilização de APIs (Interfaces de Programação de Aplicativos). As APIs permitiram que aplicações independentes se conectassem e compartilhassem dados de forma fluida e segura, dando origem a uma onda de inovação e interconexão sem precedentes.

Na virada do milênio, em 2000, Roy Fielding apresentou uma tese de doutorado introduzindo o conceito de Representational State Transfer (REST) como um estilo arquitetural. Esta proposta foi incorporada ao protocolo HTTP

A natureza simples, porém poderosa, do REST começou a ganhar destaque ao longo da década, mas foi realmente nos anos 2010 que vimos uma adoção massiva do REST, levando ao declínio de padrões anteriores, como o SOAP. O protocolo REST, que utiliza padrões da web como HTTP e JSON, promoveu uma maior aceitação e implementação devido à sua simplicidade, até o presente momento, continua sendo o padrão dominante para serviços expostos na web.

Com o sucesso e a proliferação das APIs RESTful, a web começou a mudar. Empresas como Twitter, Facebook e Google amplamente adotaram e promoveram o uso de suas APIs, possibilitando a criação de uma infinidade de aplicações de terceiros e integrando-as em ecossistemas muito maiores.

A Era dos Proxies Reversos

O gerenciamento de tráfego na web para atender a grande demanda de APIs como citamos acima, teve que passar por uma série de transformações significativas ao longo das décadas. Em 1995, o Apache foi lançado e rapidamente se estabeleceu como o servidor web padrão, dominando a cena da internet no final dos anos 90 e início dos anos 2000. Entretanto, com a evolução das linguagens de programação e a necessidade de servidores de aplicação, em 1999 foi apresentado o Apache Tomcat, projetado para executar aplicações Java em ambiente web. Esta era também testemunhou o surgimento e a popularização das APIs, culminando na proliferação dos serviços baseados em nuvem.

Com essa rápida escalabilidade, houve a demanda por soluções mais performáticas e adaptadas às novas cargas de trabalho. Em 2004, o NGINX foi introduzido como uma alternativa leve ao Apache, e, com sua capacidade de lidar com um grande número de conexões simultâneas, viu seu pico de adoção nos anos 2010, superando muitos de seus concorrentes. Essa rápida ascensão e mudança no cenário tecnológico pressionaram os proxies reversos tradicionais a evoluir, enfrentando desafios adicionais e complexos apresentados pela era moderna da computação em nuvem com a gigante Amazon Web Services (AWS) iniciando em 2006 a pioneira e em seguida veio a Google Cloud Platform (GCP) em 2008 em 2010 Microsoft Azure.

Apache

Apache, surgindo nos primórdios da web, é mais do que um simples servidor. Com o mod_proxy, o Apache não apenas roteava o tráfego, mas também proporcionava balanceamento de carga. Esta capacidade inicial formou a base para o desenvolvimento subsequente de API Gateways.

A Apache Software Foundation, fundada em 1999, tem sido um farol de código aberto, e o servidor Apache é um testemunho disso.

Grandes empresas como IBM, Nokia e Salesforce usaram Apache em algum momento, evidenciando sua robustez.

Nginx

Nginx foi uma revolução. Sua arquitetura orientada a eventos permitiu que ele se destacasse em ambientes de alto tráfego.

Criado por Igor Sysoev em 2002, foi concebido como uma resposta às limitações percebidas no Apache.

Empresas como Netflix, WordPress e Zappos confiam no Nginx para servir bilhões de solicitações por dia.

Nginx trouxe um design orientado a eventos, tornando-o mais eficiente em ambientes com alto tráfego. Rápido e leve, ele logo se tornou uma escolha popular para proxy reverso, balanceamento de carga e cache de conteúdo.

Quando falamos que o Nginx ele é um proxy de "camada 7" ou um "proxy de aplicação", estamos nos referindo à sua capacidade de tomar decisões com base no conteúdo das mensagens HTTP/HTTPS. No entanto, com as capacidades de balanceamento de carga de TCP/UDP, ele também pode operar na camada 4 (camada de transporte).

Envoy

O Envoy é um servidor proxy de alto desempenho projetado para aplicações modernas orientadas a serviços, como microserviços. Foi originalmente desenvolvido pela Lyft, e posteriormente foi doado para a Cloud Native Computing Foundation (CNCF). Desde então, tem ganhado considerável tração e tornou-se uma parte central de muitas infraestruturas modernas de TI.

O Envoy foi introduzido pela primeira vez em 2016 pela Lyft para lidar com seus desafios específicos em escala, relacionados à decomposição de sua monolítica aplicação em microserviços.

O Envoy e o NGINX são ambos servidores proxy reversos de alto desempenho, e, em muitos cenários, podem ser usados de forma intercambiável. No entanto, eles têm origens e focos um pouco diferentes.

Linguagem Go e proxies reversos

A linguagem Go é conhecida por sua eficiência e capacidade de lidar com concorrência, o que a torna ideal para o desenvolvimento de proxies reversos e servidores web. Foi criada no Google por Robert Griesemer, Rob Pike e Ken Thompson e foi anunciada ao público em 2009. Desde então, ela ganhou uma adesão considerável no mundo do back-end.

A Concorrência Nativa em Go é usando goroutines, que são mais leves do que threads tradicionais. Isso permite que os desenvolvedores escrevam programas que lidam eficientemente com muitas tarefas simultâneas, tornando-a ideal para aplicações de rede, como proxies reversos, que podem precisar gerenciar muitas conexões simultâneas.

O Desempenho em Go é algo fascinante, é uma linguagem compilada, o que significa que o código é transformado diretamente em código de máquina. Isso garante que os programas escritos em Go tenham um desempenho comparável ao de linguagens como C e C++.

A Simplicidade e Legibilidade usada em Go foi projetada com uma sintaxe clara e um conjunto mínimo de recursos. Isso promove a escrita de código limpo e fácil de entender, facilitando a colaboração e a manutenção.

As Bibliotecas Padrão em Go são Robustas e muito poderosa, especialmente para tarefas relacionadas à rede e I/O. Isso facilita a construção de servidores web e proxies reversos sem a necessidade de bibliotecas externas.

A Distribuição Estática dos binários em Go é feita por padrão. Isso significa que, ao compilar um programa, todas as suas dependências são incluídas no binário final. Isso torna a distribuição e a implantação de aplicações Go extremamente simples, sem a necessidade de gerenciar dependências no ambiente de produção.

Aqui estão alguns proxies reversos escritos em Go:

.Caddy

Além de ser um servidor web, o Caddy é amplamente reconhecido por sua configuração automática de TLS. Lançado em abril de 2015.

.Traefik

Traefik é um proxy reverso moderno e um load balancer que facilita a implantação de microserviços. Lançado em 2014.

.GoProxy

É um proxy reverso simples escrito em Go, que pode ser usado para roteamento e balanceamento de carga. Foi lançado por volta 2013.

.Fabio

Fabio é um load balancer e proxy reverso rápido que se integra diretamente com o Consul para roteamento dinâmico e lançado em 2015.

Camada OSI ou TCP/IP

Proxies podem atuar em diferentes camadas do modelo OSI ou TCP/IP, dependendo da funcionalidade e design específicos da solução. No entanto, a maioria dos proxies reversos modernos, incluindo o NGINX e muitos escritos em Go, são projetados para operar primordialmente nas camadas de Transporte e Aplicação.

Modelo OSI (Open Systems Interconnection):

O Modelo OSI (Open Systems Interconnection) é um framework conceitual usado para compreender as interações de redes complexas. Ele divide as funções de comunicação de rede em sete camadas distintas, cada uma com um conjunto específico de responsabilidades. O propósito desse modelo é guiar os desenvolvedores de produtos e protocolos para que eles possam interoperar com produtos e protocolos de outros fabricantes. Em 1984 o modelo OSI foi formalmente aprovado.

Modelo TCP/IP

O Modelo TCP/IP, também conhecido como Modelo de Referência da Internet, é um framework mais simples e prático que o OSI, usado para descrever redes de computadores. Ele tem quatro camadas e foi desenvolvido junto com os protocolos que ele descreve, tornando-o extremamente relevante e aplicável ao mundo real da Internet. Em 1983 ARPANET migra oficialmente para o TCP/IP, solidificando sua posição como o conjunto padrão de protocolos para a Internet.

Modelo OSI:

Camada de Transporte (Layer 4)

O Proxies que operam nesta camada são frequentemente chamados de "proxies de camada 4" ou "load balancers de camada 4". Eles tomam decisões de roteamento baseadas principalmente em informações da camada de transporte, como endereços IP de origem e destino e números de portas. Um exemplo é o balanceamento de carga TCP/UDP.

Camada de Aplicação (Layer 7)

O Proxies que operam nesta camada são frequentemente chamados de "proxies de camada 7" ou "load balancers de camada 7". Eles tomam decisões de roteamento baseadas no conteúdo das mensagens na camada de aplicação. Para o tráfego HTTP/HTTPS, isso pode incluir o host, URL, cabeçalhos HTTP e até mesmo o corpo da mensagem. Estes proxies podem inspecionar, modificar e tomar decisões baseadas no conteúdo do tráfego.

Modelo TCP/IP:

Camada de Transporte

O Correspondente à Camada de Transporte no modelo OSI.

Camada de Aplicação

Inclui as funções das camadas de Aplicação, Apresentação e Sessão do modelo OSI. Proxies que operam aqui podem inspecionar e tomar decisões baseadas no conteúdo das mensagens.

A Ascensão dos API Gateways

Essa rápida adoção das APIs levou a novos desafios. À medida que as organizações começavam a oferecer múltiplas APIs, surgiu a necessidade de um sistema centralizado para gerenciar, monitorar e garantir a segurança dessas interfaces. Além disso, com a escalada de microserviços nos anos 2010 e 2020, o tráfego interno entre serviços em ambientes de nuvem também precisava ser eficientemente roteado e gerenciado.

O termo "API Gateway" tornou-se proeminente principalmente na década de 2010 com a ascensão dos microserviços e da computação em nuvem. Antes disso, as APIs existiam, e as organizações as usavam, mas o conceito de um "gateway" dedicado para gerenciar essas APIs, especialmente em uma arquitetura de microserviços, era menos comum.

A necessidade de um API Gateway surgiu de vários desafios associados ao desenvolvimento e operação de microserviços, incluindo:

Roteamento e Descoberta de Serviço

Como direcionar uma chamada de API para o serviço correto em um ambiente onde você tem muitos serviços.

Limitação de Taxa

Proteger os serviços de serem sobrecarregados por demasiadas chamadas.

Autenticação e Autorização

Verificar quem está fazendo a chamada e o que eles têm permissão para fazer.

Transformação de Requisições e Respostas

Converter entre diferentes formatos ou versões de API.

As primeiras soluções de API Gateway começaram a aparecer no mercado por volta de 2010-2012. A ascensão da computação em nuvem e plataformas como a AWS também desempenharam um papel fundamental na popularização do conceito. Por exemplo, em 2015, a AWS lançou o Amazon API Gateway, um serviço totalmente gerenciado para criar, publicar, manter, monitorar e proteger APIs.

No entanto, é importante notar que, embora o termo "API Gateway" tenha ganhado popularidade durante esse período, o conceito fundamental de intermediar e gerenciar chamadas de API não é novo e tem raízes em tecnologias anteriores, como os Enterprise Service Buses (ESBs) e soluções de integração.

API Gateways Kong

Um dos primeiros e mais notáveis API Gateways de código aberto a ganhar reconhecimento no mercado foi o Kong. Foi lançado em 2015 pela empresa Mashape (agora conhecida como Kong Inc.).

O Kong foi desenvolvido inicialmente como uma camada em cima do servidor NGINX e utilizou sua capacidade de processamento para lidar com o tráfego de API. Com uma arquitetura modular e suporte a plugins, o Kong ofereceu desde o início uma variedade de funcionalidades como limitação de taxa, autenticação, registro, transformações de solicitações/respostas e muitas outras.

Seu código aberto e capacidade de extensão rapidamente o tornaram popular entre as comunidades de desenvolvedores e operações, e ele desempenhou um papel significativo na definição do mercado de API Gateway.

Existiram outros produtos e ferramentas antes do Kong, mas muitos deles eram proprietários ou não eram estritamente API Gateways na definição moderna. O Kong é frequentemente reconhecido por popularizar o conceito e fornecer uma solução robusta e de código aberto para a comunidade.

O Kong foi desenvolvido principalmente em Lua, utilizando o framework LuaJIT (Just-In-Time Compiler para Lua). Ele é construído em cima do servidor NGINX, aproveitando a capacidade de processamento de alta performance do NGINX com a flexibilidade do Lua através do módulo ngx_http_lua_module, que permite a execução de código Lua dentro do contexto do NGINX. Esse design permite ao Kong ser altamente extensível através de plugins.

API Gateways desenvolvidos em Go

O KrakenD é uma API Gateway de alto desempenho que ajuda a agregar, transformar e filtrar os dados antes que eles cheguem ao cliente, otimizando assim o consumo de APIs.

O Gloo é uma API Gateway e proxy reverso baseado no Envoy. É otimizado para casos de uso centrados em microserviços, funções e aplicações em contêiner. Criado pela Solo-io, Gloo é um "Next Generation API Gateway" e ingress controller. Ele foi projetado para ajudar a conectar, proteger e controlar o tráfego de serviços em ambientes de microserviços e aplicativos monolíticos.

O Tyk é um API Gateway de código aberto e gerenciamento de API que também oferece uma versão comercial. Ele oferece muitos recursos avançados, incluindo quotas, limitação de taxa, e autenticação.

API Gateways CLOUD

As principais provedoras de nuvem têm suas próprias soluções de API Gateway, otimizadas para integrar-se perfeitamente com seus respectivos ambientes e serviços de nuvem. Tornou-se um grande negócio e a criação de produtos voltados ao gerenciamento e escala quando o assunto é desenvolvimento de APIs.

Amazon Web Services (AWS)

Na AWS usamos API Gateway Este serviço permite que os desenvolvedores criem, publiquem, mantenham, monitorizem e protejam APIs de forma escalável. É capaz de processar milhares de chamadas de API simultaneamente e suporta APIs RESTful e WebSockets. Também se integra facilmente com outros serviços da AWS, como AWS Lambda.

Google Cloud Platform (GCP)

A solução Apigee Adquirida pela Google em 2016, a Apigee oferece uma plataforma de gerenciamento de ciclo de vida completo para APIs, permitindo análises, desenvolvimento de portal de desenvolvedor, e outras características avançadas-Cloud Endpoints: É uma solução mais leve que a Apigee e é mais integrada com o ambiente de nuvem da Google. Permite que os desenvolvedores criem, implantem, protejam e monitorem APIs dentro do GCP.

Microsoft Azure

A solução Azure API Management: Esta é a solução da Microsoft para o gerenciamento de APIs na nuvem Azure. Ele fornece ferramentas para criar, gerenciar e analisar APIs, e também permite a criação de portais para desenvolvedores e outros recursos avançados.

Estas soluções diferem em características e capacidades, mas todas têm o objetivo comum de fornecer ferramentas robustas para o gerenciamento, proteção, e análise de APIs em ambientes de nuvem cada um com suas particularidades e características.

Conclusão

À medida que adentramos na era da digitalização, a conectividade entre sistemas e aplicações continua a se expandir em complexidade e escala. No centro desta revolução digital, os proxies e API Gateways emergem como componentes críticos para garantir que as comunicações sejam ágeis, seguras e eficientes.

As soluções modernas de proxies, como o Envoy, e os API Gateways construídos em linguagens de alto desempenho como Go, são peças de uma engrenagem bem maior e que vivenciou toda evolução contínua desta tecnologia. Eles não apenas atendem às necessidades atuais, mas também são projetados com flexibilidade para se adaptarem às mudanças futuras.

O uso crescente de microserviços, contêineres e soluções de nuvem amplifica ainda mais a necessidade de proxies eficientes e API Gateways robustos. Eles não só permitem a integração eficaz de múltiplos serviços, mas também oferecem segurança, balanceamento de carga, rate limit, transformações de requisições, autenticações e muito mais.

Enquanto olhamos para o futuro, é evidente que a demanda por proxies e API Gateways só aumentará. Assim, seja você um desenvolvedor, arquiteto ou entusiasta da tecnologia, é fundamental manter-se atualizado sobre estas ferramentas e práticas. Afinal, eles serão os pilares que sustentarão a próxima geração de aplicações e sistemas interconectados.

GoLang — Simplifying Complexity “The Beginning”

Jefferson Otoni Lima — Fri, 26 May 2023 19:54:43 +0000

There are countless programming languages and each one was born with a purpose: “solve problems”. Languages are tools and we will have to know how to use them at the right time. Speaking “as a developer” the more polyglot you can be the better it will be for your professional career and for a better understanding and understanding of the diversity of this ecosystem.

The goal of this post is to introduce what the Go language is and why it is so powerful. Introducing some concepts and important points about the Go language that are often mistakenly expressed in several articles found on the internet and discussion groups of programming languages. I believe that the weaknesses and problems generated by several other programming languages over these decades made Go become what it is today. And to explain how this is possible we will go back to the beginning of everything, where everything began.

package main

func main() {
    println("Hello all folks!")
}

Less is exponentially More

The Go development team says that its creation is an attempt to make programmers more productive. Improving the software development process on Google. The first goal was to create a better language to address the challenges of scalable concurrency, ie software that handles many concerns simultaneously, an example would be coordinating a thousand back-end servers sending network traffic all the time.

Keeping the Go language small allows for more important goals. Being small makes Go easier to learn, easier to understand, easier to implement, easier to re-implement, easier to ** debug**, easier to tweak, and easier to evolve. Doing less allows for more. It's an expression used by the Go development team: “Do Less. Enable More” would be the balance between the universe of existing problems and what Go can help solve such problems well. Go explicitly wasn't designed to solve every problem instead they've done enough for us to create our own custom solutions with ease, but making it very clear that Go can't do everything.

Go was designed by Google in 2007 to improve programming productivity in an era of multicore, network machines and large codebases. The designers wanted to address criticisms of other languages in use at Google, but keep their useful features.

The creators Rob Pike, Ken Thompson and [Robert Griesemer](https:/ /de.wikipedia.org/wiki/Robert_Griesemer) kept the syntax of Go similar to C. In late 2008 Russ Cox joined the team and helped move the language and libraries from prototype to reality.

The Go language was released in 2009 with the purpose of facilitating problem-solving in areas such as network layers, scalability, performance, productivity, and most importantly, concurrency. Rob Pike himself stated that "Go was designed to address a set of software engineering problems we faced when building large server software".

Go was influenced by various programming languages and different paradigms, including Alef, APL, BCPL, C, CSP, Limbo, Modula, Newsqueak, Oberon, occam, Pascal, Smalltalk, and Crystal. It is evident that they used the best of what they had and created something new and lean, with the minimum necessary to solve the proposed problems without losing its simplicity. I believe this can be called innovation. Go innovated by breaking the paradigms of programming languages and implementing something new in a simple and very powerful way.

Controversies

Several features that are present in other modern programming languages were deliberately left out in Go, going against the trend. These features include immutability declarations, pattern-matching data types, generics, exception handling, inheritance, method overloading, and many other points. All of these features were criticized and pointed out to the creators of Go, who responded: "These omissions were simplifications that contribute to Go's strength." There are many things in the Go language and libraries that differ from modern practices, it was a decision made by the Go development team: "Sometimes it's worth trying a different approach."

Everyone is invited to help and contribute if they wish, they can submit proposals for new features and anything related to the language's ecosystem. The Go source code is available on GitHub. The documentation on how you can contribute to the language is provided here.

Goroutines instead of threads

One of the main goals of the Go programming language is to make concurrency simpler, faster, and more efficient.

Goroutines are lightweight and take advantage of all available processing power. Goroutines exist only in the Go runtime virtual space and not in the operating system.

A goroutine is a method/function that can be executed independently along with other goroutines. Each concurrent activity in the Go language is generally called a goroutine.

One of the most relevant and important points is the work with concurrency, which innovated by breaking the traditional model of threads and its usage by creating a new model, the goroutines, in Go. Goroutines are responsible for performing asynchronous executions in Go. They are very powerful and a simple machine with 1GB of RAM could run thousands of them.

Goroutines are part of making concurrency easy to use. Goroutines can be very cheap: they have little overhead beyond memory for the stack, which is only a few kilobytes. To make stacks small, the Go runtime uses resizable and bounded stacks. A newly launched goroutine gets a few kilobytes, which is almost always enough. When it's not, the runtime increases (and shrinks) the memory to store the stack automatically, allowing many goroutines to live in a modest amount of memory. The CPU overhead averages three cheap instructions per function call. It is practical to create hundreds of thousands of goroutines in the same address space. If goroutines were just threads, system resources would run out at a much smaller number.

The design of Go was heavily influenced by C.A.R. Hoare's 1978 article "Communicating sequential processes".

Simultaneity in CSP Ideas

One of the most successful models for providing high-level language support for concurrency is Hoare's Communicating Sequential Processes or CSP. Occam and Erlang are two well-known languages that derive from CSP. Go's concurrency primitives derive from a different part of the genealogical tree whose main contribution is the powerful notion of channels as first-class objects. Experience with several earlier languages showed that the CSP model fits well into a procedural language framework.

The biggest difference between Go and the CSP model, besides syntax, is that Go models communication channels explicitly as channels, while the processes of Hoare's language send messages directly to each other, similar to Erlang.

In order to achieve this result, Go has once again received criticism for the adopted model. Go incorporates a variant of CSP (Communicating Sequential Processes), a formal language for describing interaction patterns in concurrent systems with first-class channels. A single-write approach was not adopted to enhance the semantics in the context of concurrent computing, as is done in Erlang, instead, they adopted something practical that resulted in something powerful, allowing for simple and safe concurrent programming, but does not prevent incorrect programming. And the created motto was: "Do not communicate by sharing memory, share memory by communicating". The simplicity and support for concurrency offered by Go generate robustness.

Concurrency is different from Parallelism

One of the famous phrases is: "Concurrency is about dealing with many things at once. Parallelism is doing many things at once." Concurrency is the composition of independent execution calculations. Concurrency is a way of structuring software and is definitely not parallelism, although it allows for parallelism. If you only have one processor, your program can still be concurrent, but it cannot be parallel. On the other hand, a well-written concurrent program can be efficiently executed in parallel on a multiprocessor. I suggest checking out this talk by Rob Pike, "Concurrency is not Parallelism".

Concurrency in Go is very powerful and also simple to code, which was the intention of the engineers who developed Go. Solving many problems is much more efficient using concurrency, and this is the power of Go, which is why it has become a deity when it comes to concurrency. Therefore, problems encompassed in this universe will be solved very efficiently and, most importantly, with very few computational resources.

When we talk about concurrency, we need to highlight that there are some patterns, which I describe below, and there are some types of workloads that will serve as our compass to determine our balance point when we have to solve problems involving concurrency.

Workloads: CPU-Bound & IO-Bound

A thread can perform two types of workloads (Workloads): CPU-Bound and IO-Bound.

CPU-Bound: This workload will never create a situation where the thread can be put into waiting states. It will be constantly performing calculations. A thread calculating pi to the eighteenth power would be limited by the CPU. (Fun fact: Emma Haruka Iwao is a Japanese computer scientist and cloud developer engineer at Google. In 2019, Haruka Iwao calculated the most accurate value of pi in the world, which included 31.4 trillion digits). This type of workload, CPU-bound work, requires parallelism to take advantage of concurrency. More Goroutines will not help and will not be efficient, potentially further delaying the workloads to be executed, due to the latency cost (the time spent) of moving Goroutines in and out of the operating system's thread.

IO-Bound: In this type of workload, threads enter waiting states. A good example would be a request for accessing a resource over the network or making calls to the operating system. A thread that needs to access a database, synchronization events (mutex, atomic), all of these examples make the thread wait, so we could say they are of the IO-Bound type of workload. In this type of workload, you do not need parallelism to use concurrency, a single physical core would be sufficient for the proper execution of several Goroutines. The Goroutines are entering and exiting waiting states as part of their workload. In this type of workload, having more Goroutines than physical cores can speed up execution because the latency cost of moving Goroutines in and out of the operating system's thread is not creating an event. Its workload is naturally interrupted, allowing a different Goroutine to take advantage of the same physical core instead of allowing it to remain idle.

Goroutine and Pattern

There are some patterns for concurrency, among them: Fan-In and Fan-Out.

Fan-Out: Multiple functions can read from the same channel until that channel is closed, this is called fan-out. This provides a way to distribute work among a group of workers to make use of CPU and I/O in a concurrent manner.

Fan-In: It is the way to read from multiple inputs and proceed until all of them are closed, multiplexing the input channels into a single channel that is closed when all the inputs are closed. This is called fan-in.

Pipeline: There is no formal definition of a pipeline in Go, it is just one of the many types of concurrent programs. Informally, a pipeline is a series of stages connected by channels, where each stage is a group of goroutines running the same function. At each stage, the goroutines:

Receive values from upstream via input channels;
Perform some function on that data, usually producing new values;
Send values downstream via output channels.

Each stage has several input and output channels, except for the first and last stages, which have only input or output channels, respectively.

To give you an idea, on a 1 CPU and 1 GB RAM machine, we can handle 5k to 6k requests per second with a simple Go API, with few lines of code, using either RPC or native TCP protocols and writing to a relational database like PostgreSQL, without crashing it and consuming an average of only 60Mb to 70Mb of memory and 8% to 15% of CPU. To achieve this, we use a "Worker Poll" that is a Fan-out.

If you want to delve further into concurrency, you can check out this link. If you want to test and see some examples, you can click here. We'll create a separate post to talk about Goroutines, which is a very detailed and interesting topic. We know that Go's support for concurrency makes it a godsend for problems that are best solved using concurrency.

Go is a compiled language, a C-like language, very focused on productivity. For simple or complex projects, Go will always be an excellent alternative, as it makes everything simpler and leaner, easy to code and maintain.

package main

import "fmt"

func main() {
    fmt.Printf("Hello, I love Go!\n")
}

There is no silver bullet

There is no solution or tool to solve all problems yet, of course. What we know is that there are countless solutions developed in various languages, each with a purpose and each with its own characteristics. For this reason, there are programming paradigms, which is a way of classifying languages based on their functionalities, making it easier to understand the context in which they will be better inserted, and, of course, giving us a view of their structure and execution of the languages.

It is becoming increasingly common for languages to support multiple paradigms. We know that there are different classes in computing when it comes to solving problems, and the closer we are to these subjects, the more comfortable we will be to choose a certain language to solve problems, and thus know which tool to use at the right time. In practice, this task is not so easy, but what we know is that the silver bullet has not yet been created to solve all problems at once with just one language, if it existed, there would no longer be P versus NP and all problems could be solved in polynomial time.

The Good Things About Go

It does not have generics;
It does not have operator overloading;
It does not have pointer arithmetic;
Thread management is not explicitly managed;
It has type inference;
Dependencies are clear;
The syntax is clean;
The semantics are clear;
Composition over inheritance;
Native GC (Garbage collector);
It has Goroutines;
Native support for concurrent programming;
First-class functions (we can pass functions as parameters);
Cross-platform;
Open Source;
Very low learning curve, meaning it is easy to learn;
Highly productive;
Solves scalability problems;
It can drastically reduce server costs;
Various problems thought from the Go perspective become much easier to handle and solve;
It has only 25 reserved keywords;
Multi-paradigm: concurrent, functional, imperative, object-oriented;
Memory Safe.

We know that various points above will be criticized, but in practice and over time, we realized that all the omitted simplifications made Go an even more powerful language.

When we didn't have Generics

When we didn't have Generics There are strong reasons why Go didn't implement Generics early in the project, and there's a discussion in the general communities about this topic. Go left out several features, including “Generics”, which in its conception would directly compromise the performance and purpose that the Go language was intended to solve.

Complainants are mainly developers who come from languages that use this feature. On November 29, 2018, the Go source code maintainers opened up the possibility to submit proposals for new features with all the details so that they can analyze them and possibly implement them in the Go 2.0 version, but we know that this happened before in March 2022 version 1.18 was released. To get a good idea, read this file by by clicking here.

In Go 1.18, the language introduced a new feature called generic types that had been on the wish list of Go developers for some time. In programming, a generic type is a type that can be used in conjunction with many other types. Normally in Go, if you want to use two different types for the same variable, you need to use a specific interface, like io.Reader, or use interface{}, which allows you to use any value. Using the {} interface can make working with these types difficult because you have to translate between several other possible types to interact with them. Using generic types allows you to interact directly with your types, leading to cleaner, easier-to-read code.

Example:

Imagine a method that receives an array of type int and prints it on the screen.

Imagine now needing to do the same with the String type and the float type, you would have to create new methods or functions several times, repeating the code.

Solution: To avoid creating several methods, only one method is created as a generic to be able to receive any type.

type iMyinterface interface {
    int | int64 | int32
    ~float64
    ~string
    ~[]byte
    MyMethod()
}

func NoGenericFuncStrs(a, b []string) bool
func NoGenericFuncInts(a, b []int) bool
func NoGenericInterface(a, b interface{}) bool

func GenericsFuncStrs[T comparable](a, b []T) bool

Note that this is only a problem in languages that need to declare types of variables or functions, etc. In dynamic languages like PHP, for example, this is not necessary. I won't say strongly or weakly typed languages because it's a bit more complex than that, and that would lead to another discussion.

In Go, we can solve all problems of this nature using reflect and other interfaces and now we have Generics to make our work even easier 😎.

Below are three examples with three proposals to solve the problem in this way, and you will be able to understand when we talk about Generics. 😊

Copying and Pasting Functions with Specific Types

package main

// Takes a slice of any type and reverses it.
func Reverses(list []string) []string {
    i := 0
    j := len(list) - 1
    for i < j {
        list[i], list[j] = list[j], list[i]
        i++
        j--
    }
    return list
}

// Takes a slice of any type and reverses it.
func Reversei(list []int) []int {
    i := 0
    j := len(list) - 1
    for i < j {
        list[i], list[j] = list[j], list[i]
        i++
        j--
    }
    return list
}

func main() {
    s := []string{"otoni","jeff","Go"}
    Reverses(s)
    println(s[0], s[1], s[2])

    i := []int{2020,2012,2009}  
    Reversei(i) 
    println(i[0], i[1], i[2])
}

Using Interface

package main

// Takes a slice of any type and reverses it.
func Reverse(in interface{}) interface{} {
    switch in.(type) {
        case []string:
        list := []string(in.([]string))
        i := 0
        j := len(list) - 1
        for i < j {
               list[i], list[j] = list[j], list[i]
           i++
           j--
            }
            return list

         case []int:
        list := []int(in.([]int))
        i := 0
        j := len(list) - 1
        for i < j {
           list[i], list[j] = list[j], list[i]
           i++
           j--
            }
            return list
    }
    return nil
}

func main() {
    s := []string{"otoni","jeff","Go"}
    Reverse(s)
    println(s[0], s[1], s[2])

    i := []int{2020,2012,2009}  
    Reverse(i)  
    println(i[0], i[1], i[2])
}

Using Generics

// https://go2goplay.golang.org/
package main

import (
    "fmt"
)

// The playground now supports parentheses or square brackets (only one at
// a time) for generic type and function declarations and instantiations.
// By default, parentheses are expected. To switch to square brackets,
// the first generic declaration in the source must use square brackets.

func Print[type T] (s []T){
    for _, v := range s {
        fmt.Print(v)
    }
    fmt.Println("")
}

func Reverse[type T](list []T) {
    i := 0
    j := len(list) - 1
    for i < j {
        list[i], list[j] = list[j], list[i]
        i++
        j--
    }
}

func main() {
        var i []interface{}
        i = append(i, "jeffotoni")
        i = append(i, " ano de 2020 ")
        i = append(i, []string{"otoni", "jeff", "Go"})
    i = append(i, []int{2020, 2012, 2009})
        Print(i)

    s := []string{"otoni", "jeff", "Go"}
    Reverse(s)
    Print(s)

    intt := []int{2020, 2012, 2009}
    Reverse(intt)
    Print(intt)
}

Composition over Inheritance

The approach adopted by Go departs from the norm and is unusual for object-oriented programming, allowing methods of any type, not just classes, but without any form of type-based inheritance, such as subclasses. This means that there is no type hierarchy. This is not a bug, not a disadvantage, nor an error, but an intentional design choice by the developers of Go. Although type hierarchies have been used to build successful software, it is the stance and opinion of the Go development team, that they preferred to take a step back instead of doing the same repetitive model in various languages.

Interfaces are implicit

Instead, Go has interfaces, which are just a set of methods and nothing more.

Example:

go

type Geometric interface {
  area() float64
  perim() float64
}

All data types that implement these methods satisfy this interface implicitly, there is no "implements" in the declaration. Interface satisfaction is checked statically at compile time, therefore, despite the decoupling interfaces, they are type-safe.

A type usually satisfies many interfaces, each corresponding to a subset of its methods. This fluidity of interface satisfaction encourages a different approach to software construction, breaking the existing paradigm.

Why aren't interfaces explicit?

Object-oriented programming provides a powerful view: that the behavior of data can be generalized independently of the representation of that data. The model works best when a behavior (set of methods) is fixed, but once you insert a subclass into a type and add a method, the behaviors are no longer identical. If instead, the set of behaviors is fixed, as in interfaces statically defined in Go, the uniformity of behavior allows data and programs to be composed uniformly, orthogonally, and safely. Type hierarchies result in fragile code. Go stimulates composition and not inheritance, using simple interfaces, usually of one method, to define trivial behaviors that serve as clear and understandable boundaries between components and eliminating the type hierarchy also eliminates one form of dependency hierarchy. The designs are not like hierarchical methods inherited from subtypes. They are more loose, organic, decoupled, independent and therefore scalable.

go

package main

import "fmt"
import "math"

type Geometric interface {
    area() float64
    perim() float64
}

type rect struct {
    width, height float64
}

type circle struct {
    radius float64
}

func (r rect) area() float64 {
    return r.width * r.height
}

func (r rect) perim() float64 {
    return 2*r.width + 2*r.height
}

func (c circle) area() float64 {
    return math.Pi * c.radius * c.radius
}

func (c circle) perim() float64 {
    return 2 * math.Pi * c.radius
}

func measure(g geometry) {
    fmt.Println(g)
    fmt.Println(g.area())
    fmt.Println(g.perim())
}

func main() {
    r := rect{width: 3, height: 4}
    c := circle{radius: 5}

    measure(r)
    measure(c)
}

Duck typing

Go supports "Duck typing", a typing style in which the methods and properties of an object determine the valid semantics, rather than its inheritance from a particular class or implementation of an explicit interface. The concept's name refers to the duck test, attributed to James Whitcomb Riley. This makes Go look like a dynamic language.

Go uses "Structural Typing" in methods to determine the compatibility of a type with an interface. There are no type hierarchies, and "Structural Typing" is an interesting alternative to classic inheritance in statically typed languages. It allows you to write generic algorithms without obscuring the definition of a type in a sea of interfaces. Perhaps more importantly, it helps statically typed languages capture the feel and productivity of dynamically typed languages.

"Duck typing" occurs at runtime and "Structural Typing" occurs at compile time. Go does not support object orientation as implemented in languages like C#, Java, or even C++, it has no inheritance and honestly, I am very happy with this, but it does offer some features such as composition and interfaces.

go

package main

import (
    "fmt"
)

type family interface {
    dados() string
}

type pai struct {
    Nome  string
    Idade int
    Cpf   string `json:"campo-x"`
}

func (p pai) dados() string {
    return fmt.Sprintf("Nome: %s, Idade: %d", p.Nome, p.Idade)
}

type filho struct {
    pai
    email string
}

func (f filho) dados() string {
    return fmt.Sprintf("Nome: %s, Idade: %d, Email: %s", f.Nome, f.Idade, f.email)
}

func mostraDados(membro familia) {
    fmt.Println(membro.dados())
}
func main() {
    pai := new(pai)
    pai.Nome = "Jeff"
    pai.Idade = 50
    pai.Cpf = "00.xxx.xxx-xx"

    filho := new(filho)
    filho.Nome = "Arthur"
    filho.Idade = 20
    filho.email = "arthur@gmail.com"

    mostraDados(pai)
    mostraDados(filho)
 }

Strong third-party library support

In the current scenario, Go has taken off as a programming language and all major, medium, and small existing players are developing their libraries, SDKs, clients, etc. in the Go language. There are thousands of initiatives and many third-party libraries. Everything contributes to this, the Go community is very strong, it grows every day, it has a very high acceptance curve, and with this, it facilitates its entry into companies and its use by developers.

The result of this is mass dissemination on the internet with libraries written in Go. There are also libraries that are abandoned, as in any other language, but functional. But the number of libraries written in Go is very, very large. Several companies are rewriting their platforms in Go, which is a trend that continues to grow. And day by day the number of tools for DevOps grows, and with this, the acceptance and increase of new adherents to Go grows in the DevOps culture and community.

After the implementation of version control VGO in Go, we now have the possibility of not needing our projects to be under $GOPATH, we can now create our projects in any directory outside $GOPATH. This feature is only possible due to version control, when we use "go mod" our project workspaces are controlled in a new way, just run the command "go mod init yourapp" and a file named "go.mod" will be created containing the location of your path and the version in which it is located. Very simple and beautiful. Every time we run our Go project, we can use the environment variable "GO111MODULE=yes|no" to determine whether we will use "go mod" or not.

Garbage collector (GC)

GCs are complex pieces of software, decades of research and implementations, and various attempts by computer scientists to make an improved and reliable GC. It is not a simple task, and due to this, there is a huge chain on the internet describing the pros and cons of a GC. What we have to take into consideration is that regardless of the result, if we didn't have a GC, we would have to build one to solve the allocation problem.

There are usually two ways to allocate memory in Go: on the stack and on the heap. Generally, developers are familiar with the stack, just write a recursive program and you will notice a stack overflow if you don't do it correctly. The heap, on the other hand, is a pool of memory that can be used for dynamic allocation.

Stack allocations are great because they only live during the lifetime of the function to which they belong. Heap allocations, however, will not be deallocated automatically when they go out of scope. To avoid the heap becoming dissociated, we must deallocate it explicitly or, in the case of memory-managed programming languages (like Go), rely on the garbage collector to locate and delete unreferenced objects.

In general, in languages with a GC, the more you can store on the stack, the better, since these allocations are never seen by the GC. Compilers use a technique called escape analysis to determine whether something can be allocated on the stack or should be placed on the heap.

In practice, writing programs that force the compiler to allocate only on the stack can be very limiting, and thus, in Go, we take advantage of its wonderful GC to do the work of keeping our heap clean.

If you want to take a look and delve deeper into the subject, check out this link written by Richard L. Hudson: https://blog.golang.org/ismmkeynote.

Some types of applications implemented in Go

Go is a general-purpose language. In this link, you can see various applications implemented in Go and their respective categories.

Some types:

. Web backend (with various frameworks available)

. Web Assembly (one of them is vugu framework)

. Microservices (some frameworks: Go Micro, Go Kit, Gizmo, Kite)

. Fragments services (Term mentioned by @jeffotoni in a microservices discussion group)

. Lambdas (FaaS example)

. Client Server

. Terminal applications (using the tview lib)

. IoT (some frameworks)

. Bots (some here)

. Client Applications using Web technology

. Desktop using Qt+QML, Native Win Lib (example Qt, Qt widgets, Qml)

. Network Applications

. Protocol applications

. REST Applications

. SOAP Applications

. GraphQL Applications

. RPC Applications

. TCP Applications

. gRPC Applications

. WebSocket Applications

. GopherJS (compiles Go to JavaScript)

Why We Love Go! ❤

Jefferson Otoni Lima — Wed, 26 Apr 2023 18:03:13 +0000

Go: The fastest growing language for backend

Go was designed by Google in 2007 to improve programming productivity in an era of multicore, networked machines, and large codebases. The designers wanted to address criticisms of other languages in use at Google, but keep their useful features. The creators Rob Pike, Ken Thompson, and Robert Griesemer kept Go's syntax similar to C. In late 2008, Russ Cox joined the team and helped move the language and libraries from prototype to reality.

The Go language was released in 2009 with the purpose of making it easier to solve problems related to networked layers, scalability, performance, productivity, and most importantly, concurrency. Rob Pike himself declared that "Go was designed to address a set of engineering problems we encountered building large server software."

Go has been influenced by various programming languages and different paradigms, including Alef, APL, BCPL, C, CSP, Limbo, Modula, Newsqueak, Oberon, occam, Pascal, Smalltalk, and Crystal. It is clear that they used what was best and created something new and lean, with the minimum necessary to solve the proposed problems without losing its simplicity. I believe this is what we can call innovation. Go broke the paradigms of languages and implemented something new in a simple and very powerful way.

package mainimport "fmt"func main() {
    fmt.Println("Hello all folks!")
}

Less is exponentially more

The Go developer team say its creation is an attempt to make programmers more productive. Improving the software development process on Google. The first goal was to create a better language to address the challenges of scalable concurrency, ie software that handles many concerns simultaneously, an example would be coordinating a thousand back-end servers sending network traffic all the time.

Keeping the Go language small allows for more important goals. Being small makes Go easier to learn, easier to understand, easier to implement, easier to reimplement, easier to debug, easier to tweak, and easier to evolve. Doing less allows for more. It's an expression used by the Go development team: “Do Less. Enable More” would be the balance between the universe of existing problems and what Go can help to solve such problems well. Go explicitly wasn't designed to solve every problem, instead they've done enough for us to create our own custom solutions with ease, while making it very clear that Go can't do everything.

Uproar in the Go community

Several features of modern languages were left out, contradicting and going in the opposite direction of other current languages, some features such as: the use of immutability declarations, pattern matching data types, generics, exception handling, inheritance, generic programming, assertion, and method overloading, and many other points. All of the above resources were criticized and pointed out to the creators of Go, who responded: "These omissions were simplifications that contributed and contribute to the strength of Go." There are many things in the Go language and libraries that differ from modern practices, and it was a decision of the Go development team: "Sometimes it's worth trying a different approach."

Everyone is invited to help and contribute if they wish. Interested parties can open proposals for new features and everything related to the language ecosystem. The Go source code is available on GitHub. The documentation on how you can contribute to the language is provided here.

Concurrency is different from parallelism

One of the famous phrases is: *“Competition is about dealing with many things at the same time. Parallelism is doing many things at the same time”.*Concurrency is the composition of independently executing calculations. Concurrency is a way of structuring software, and it is definitely not parallelism although it does allow for parallelism.

If you only have one processor, your program can still be concurrent, but not parallel. On the other hand, a well-written concurrent program can run efficiently in parallel on a multiprocessor. I suggest checking out this video of a talk by Rob Pike “Concurrency is not Parallelism”.

Concurrency in Go is very powerful and also simple to code, which was the intent of the engineers who developed Go. Solving many problems is much more efficient using concurrency and this is the power of Go, so it has become a god when it comes to concurrency. Due to this, problems encompassed in this universe will be solved very efficiently and most importantly, with very little computational resources.

The example below is a classic one when referring to concurrency, when we want to balance CPU and I/O we use this parttern Fan-out.

What is Fan-out ?

Multiple functions can read from the same channel until that channel is closed, this is called fan-out . This provides a way to distribute work among a group of workers to parallelize CPU and I/O usage.

/*
* Example Worker
* @package     main
* @author      @jeffotoni
 */

// In this example we'll look at how to implement
// a _worker pool_ using goroutines and channels.
package main

import "fmt"
import "time"

// Here's the worker, of which we'll run several
// concurrent instances. These workers will receive
// work on the `jobs` channel and send the corresponding
// results on `results`. We'll sleep a second per job to
// simulate an expensive task.
func worker(id int, jobs <-chan int, results chan<- int) {

    for j := range jobs {

        fmt.Println("worker", id, "started  job", j)

        time.Sleep(time.Second)

        fmt.Println("worker", id, "finished job", j)
        results <- j * 2
    }
}

func main() {

    // In order to use our pool of workers we need to send
    // them work and collect their results. We make 2
    // channels for this.
    jobs := make(chan int, 100)
    results := make(chan int, 100)

    // This starts up 3 workers, initially blocked
    // because there are no jobs yet.
    for w := 1; w <= 3; w++ {
        go worker(w, jobs, results)
    }

    // Here we send 5 `jobs` and then `close` that
    // channel to indicate that's all the work we have.
    for j := 1; j <= 5; j++ {
        jobs <- j
    }

    close(jobs)

    // Finally we collect all the results of the work.
    for a := 1; a <= 5; a++ {
        <-results
    }
}

Good points of Go:

Does not have Generics;
Does not have operator overload;
Does not have pointer arithmetic;
Threads management is not explicit;
Has type inference;
Dependencies are clear;
The syntax is clean;
The semantics are clear;
Composition and not inheritance;
Native GC (Garbage collector);
Has Goroutines;
Native support for concurrent programming;
First Class Functions (we can pass functions as parameters);
Multiplataform;
Open Source;
Very low Learning Curve or easy to learn;
Highly productive;
Resolves scalability issues;
It can lowers your server costs drastically;
Several problems thought from the Go perspective become much easier to treat and solve them;
It has only 25 reserved words;
Multi-paradigm: concurrent, functional, imperative, object-oriented;
MemorySafe.

We know that several points above will be criticized, but in practice and over time we realized that all the omitted simplifications made Go an even more powerful language. For simple or complex projects, Go will always be an excellent alternative, as it makes everything simpler and leaner, easier to code and maintain.

Go is love ❤