Hacker Newsnew | past | comments | ask | show | jobs | submit | mertyildiran's commentslogin

Well if the fundamental constants or hidden variables of the universe are shifting because of his comment then it can change the outcome.


Terrance, Reinmann and Hebert walks into a bar...


Funny that it says "written with human assistance" instead of saying "written with AI assistance". So we're assistants to the machines that we have created.


In the same way that the driver is the assistant of a car?


train engineer an assistant of a rail-following machine


Kubeshark (formerly Mizu) is an observability and monitoring tool that captures all the network traffic inside a Kubernetes cluster, including ingress, egress and across containers and pods.

Kubeshark can even capture and display the encrypted (TLS) traffic using various Linux kernel technologies. It supports a wide variety of application layer protocols and RPCs like gRPC, GraphQL, etc.

Kubeshark is open-source and free to use. It has a large userbase.

We recently renamed the project from "Mizu" to "Kubeshark". Please give Kubeshark a shout-out. It's a carefully crafted tool by a handful of Kubernetes enthusiasts for Kubernetes enthusiasts!


Can you talk about the problems it solves for your users? What are the use cases, and why would someone want to use this tool?


Traffic mapping naturally. A core pattern within Zero Trust and Cyber Security.


What does Zero Trust have to do with traffic mapping?


Visibility and analytics is a key component of zero trust... but the comment above seems to forget that the core concept of zero trust is about any person, device, or application trying to access a network cannot be trusted until authenticated and verified... this should mean using strong identity (e.g., x509) and authentication-before-connect, not trusting or allowing network identity such as IP/DNS/ports.


Love it, already shared it on Slack :)


Great name!


First of all, thank you for your comprehensive review. I learned a lot of things from this review. For example; I didn't know the existence of the Library of Babel.

Yes, I agree with you on the fact that in the current state of LDCA, there is no meaningful evolution. I tried create a supervisor script[1] to achieve such evolution based on comparing stdout. But comparing stdout does not give me a stochastic picture of error/loss. So instead in the following days or months, I'll try to create a system that checks the values in the registers at the end of the program execution. It will pick the best offspring to go with and eliminate other offsprings.

Yes, I'm basically trying to create Artificial Life with this project. Any contributions to this project are welcomed. Feel free to open PRs and issues on GitHub to discuss and contribute.

[1] https://github.com/mertyildiran/ldca/blob/master/simulate.py


Yes, you are correct. The very intuitive approach we took on decision making is the key point of the language.

I came up with this idea of designing a language with no "if" after dealing with various untestable codebases for years. They were literally untestable because of the technical debt caused by the extensive amount of "if" usage in the function bodies, especially the guard clauses makes it 1 "if" minimum for almost every functions. So at the end I have exhausted because of the if(s) and decided to create a language that forces you to have minimum technical debt.


I'm still not convinced it doesn't just sweep the complexity under the rug. Ultimately you still need to branch unless you only want the language to do pure mathematical computation or something like that. Only now every branch needs to be hidden in a function call.


I have a large Elixir project with less than 10 branches (if then else) and they were written by other developers. Conditional logic is done either in pattern matching in function definitions (and some guard) or case/cond or with/else.

I guess case/cond can be implemented with the return mechanism of Chaos. Maybe it's going to feel weird, maybe not.

There is no pattern matching and I got the feeling that's going to complicate things but again, it can be emulated to some degree but the return mechanism. Instead of

  def a(0), do: "a"
  def a(1), do: "b"
  def a(_n), do: "c"
Probably we'll be writing

  str def a(n)
    num x = n
  end {
    x == 0 : "a"
    x == 1 : "b" 
    default: "c"
  } 
Having to define that x variable feels like a waste of code and reasoning on x instead of n (the argument of the function) is a pity. Maybe the function body can be empty. I didn't install the language.

I wonder how that scales on real world cases, for example matching the internals of some complex data structure.


Pattern matching is still branching. An elegant way of expressing it, but it is branching none the less.


I am now wondering what the benefit of Chaos' approach is. Chaos is making some pretty substantial tradeoffs. Going with conventional pattern matching (as part of the declaration) isn't such a big leap.


Thanks a lot for finding the way Chaos language handles the decision making, interesting.

There are a lot of alternative keywords, especially for type safety and function definition related keywords, with the purpose of attracting programmers from other programming languages and making them feel at home. At least that was the intention.


No language I have ever worked with allowed a codebase with intermixed keywords for defining a function. In terms of feelings, it's as alien as it can get.


The language at an early development stage. So "How immutable should variables be?" is open to discussion. You might want to open an issue and propose this in the issues section: https://github.com/chaos-lang/chaos/issues


Reassignment is mutation. It's really not... on a spectrum of mutability. JavaScript const objects allowing mutation of internal data is vaguely on that spectrum, even though it's misleading and confusing. Literally reassigning a variable isn't even up for debate.


Everyone says strings in java are immutable, yet you can still re-assign to string variables. It really is up for debate.


Java strings are immutable. Java variables with a string type are not. It's really not up for debate. You can't mutate a string in Java (you can in Ruby), but you can mutate a string variable by reassigning it.


Oh, I see the distinction now.


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: