davidkunz

> Go’s type system allows preventing both issues in a rather elegant way.

Proper enums would be elegant, not this.

Aliens discovered: 0

"The World's leading Alien Hunter"

Thank you Bram for giving us software we can love and putting a :smile on our faces.

I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.

They should've called it Vicuna v2.

Fantastic language, hoping this will lead to increased adoption!

It's called BlazingMQ but not written in Rust?!

Great work, Stability!

Note: It's "Llama 2", not "LLaMA 2", they changed the capitalization.

They used ChatGPT-0301, it can't beat GPT-4.

Me too, the articles are great and I'm excited about the future of Vale.

The "compressed" knowledge is fixed. But reasoning can create new knowledge, that's what humans do all the time.

If the output of prompts can be improved with "think step by step", "tree of thoughts", etc., one can produce high quality training data with the LLM itself which the next iteration of that model can use. Rinse and repeat.

In JavaScript, primitive types are passed by value, objects are passed by reference. But you won't have data races since JavaScript code is executed in a single thread.

I had a hard time with closures when doing async programming. Is that something one should avoid?

They mixed up million with billion.

> the target size for the new model is 1 trillion parameters. Meanwhile, the target size for the free & public versions of ChatGPT is just 175 million in comparison. That's a 5.7x increase in number of the parameters.

Did nobody notice?

Just put "written in Rust" in the title, done.

> our 770M T5 model outperforms the 540B PaLM model using only 80% of available data on a benchmark task.

That sounds too good, can someone more knowledgeable comment?

It'll be great if they'd build language servers via the language server protocol, that would be editor agnostic.

> 'quasi-stochastic information compression'

Isn't that what we humans do? We try to find patterns to discover underlying mechanisms. That's information compression.

S - Spaghetti: Weave a tangled web of code, just like a master chef crafting a delicious pasta dish. Complex code is the key to intrigue and job security.

P - Precarious: Make sure the code is fragile, such that any minor change could lead to a cascade of issues. This keeps everyone on their toes and ensures that only the bravest dare to modify it.

A - Ambiguous: Write code that leaves others guessing about its purpose and functionality. Code should be a puzzle to solve, and the more obscure, the better.

G - Gratuitous: Don't be afraid to add unnecessary features and lines of code. After all, more code means more functionality, and who doesn't like more functionality?

H - Haphazard: Consistency is overrated. Embrace the chaos and develop without a plan, jumping from one idea to the next as inspiration strikes.

E - Entangled: Ensure that all components of the project are intricately connected, like a delicate lattice of spaghetti noodles. This guarantees that every change will have far-reaching consequences and keeps the team on high alert.

T - Time-consuming: Write code that takes a long time to understand, modify, and debug. The longer it takes, the more valuable it must be.

T - Tangled: Never refactor or simplify. The more convoluted the code, the more creative it appears, and the more impressed your colleagues will be.

I - Impenetrable: Write code that is difficult to test and verify, so that only the most determined and adventurous developers will dare to attempt it. This maintains a sense of exclusivity and mystique around your work.

This is great, thank you!

Usability suggestion: It should be possible to scroll horizontally in code blocks while still generating. Currently that doesn't work (at least for mobile).

I use nvim-dap[1] in combination with jester[2] (by me) to run and debug Jest tests in my project, it works perfectly.

[1]: https://github.com/mfussenegger/nvim-dap

[2]: https://github.com/David-Kunz/jester

Looks like I'll be doomscrolling through massive code bases.

> Today LLMs have not been demonstrated to be capable of synthesizing novel code.

They are capable of doing that (to some extend). Personally, I've generated plenty of (working) code to solve novel problems and I'm 100% sure that code wasn't part of the training set.

That already happened.

https://youtu.be/akceKOLtytw

Or even older:

https://m.youtube.com/watch?v=jH-6-ZIgmKY

Plugins I would like to see:

- Compiler/parser for programming languages (to see if code compiles)

- Read and write access to a given directory on the file system (to automatically change a code base)

- Access to given tools, to be invoked in that directory (cargo test, npm test, ...)

Then I could just say what I want, lean back and have a functioning program in the end.

From my experience, most time is spent in the generate-copy-paste-compile-error cycle. Especially for strict/strongly-typed languages, checking for programming errors can be done by a machine, so this process can be automated (not for logical errors, of course).

The steering wheel could invoke :earlier xs (when rotated by x to the left) and :later xs (to the right). We'd have a time machine.

I agree. I love Nim, it's such a great language but I try to stick to Rust because I have a feeling that's where the industry is headed. And Rust will improve over time, maybe at some point it will be more pleasant to use.