alexvitkov

I didn't say they are scraping. What I meant is that YOU should, if you're considering this at any serious scale.

Honestly, if I have to choose between working on the codebase of the average enterprise VMWare client and dragging some boxes around in a "no-code platform", I'm taking the boxes.

The price here is absurd - scraping unnamed big tech search engines costs $0.00, with the caveat of a slightly higher barrier of entry.

Perfect opportunity to start transitioning from 20,000 VMs to the actual amount needed for most reasonable use cases - 0.

They're a pain in the ass all around. Spectre allowed you to read everything paged in (including kernel memory) from JS in the browser.

To mitigate it browsers did a bunch of hacks, including nerfing precision on all timer APIs and disabling shared memory, because you need an accurate timer for the exploit - to this day performance.now() rounds to 1MS on firefox and 0.1MS on Chrome.

This 1MS rounding funnily is a headache for me right as we speak. On a say 240Hz monitor, for video games you need to render a frame every ~4.16ms -- 1ms precision is not enough for accurate ticker -- even if you render your frames on time, the result can't be perfectly smooth as the browser doesn't give an accurate enough timer by which to advance your physics every frame.

Yes, which is why if you're serious you will exclusively use the terminal to protect your computer from even the passing chance of being exposed to a so called "image file".

In all seriousness, compilation and model training are lossy processes and erase a lot of the context needed to understand the output (and with model training we don't fully understand it even with access to the training data). Images aren't necessarily derivative of anything, so the analogy breaks down here.

Neat! But if we're sticking to the source code analogy, the matrix multiplier probably maps closer to a CPU or an interpreter - I wouldn't say every Java program is open source because you have an open-source JVM.

Please don't call model weights source code. Code is something you can (usually) read and understand, if anything weights are closer to a very obfuscated compiled binary - although even that can be analyzed by a good enough reverse engineer.

"Open Source" models are the latest in a long series of attempts to take advantage of FOSS's reputation without actually releasing something that adheres to the principles.

They keep changing the syntax and they've pulled out major features out of the language, that's a non-starter for me.

Too bad :)

Facebook trained the model on an Internet's worth of copyrighted material without any regard for licenses whatsoever - even if model weights are copyrightable, which is an open question, you're doing the exact same thing they did. Probably not a bulletproof legal defense though.

> Because the harsh truth is that none of those things are actually big issues that would justify learning slightly different syntax.

The syntax has nothing to do with it, you already know the syntax. I'm fairly confident most people reading this comment can program in this language right now, without opening the docs.

The reasons I won't be using it are:

1. It's a source to source transpiler - even when done nearly perfectly, these always introduce problems. Debugging TS is never 100% seamless. Debugging minified JS is annoying, even with a sourcemap.

2. Go code tends to be very simple and "un-abstract", so the problems with the language's syntax and typesystem aren't bad enough to justify a wrapper.

3. I don't want to be an early adopter of programming languages. This may be harsh, but I won't consider a language until it reaches at least #50 in popularity someone is paid to work on the tooling full time. Hobbyists enjoy solving interesting problems like language design, but don't particularly enjoy the "gruntwork" some of which is critical - a comprehensive test suite, a fuzzer for the compiler, an LSP/IDE/editor plugins, a good standard library...

There have been a lot of promising one-man projects such as this one, that get abandoned when the lead developer moves on. You don't want to be stuck holding the bag with a large codebase in a zero user language.

If I have a group of N people who I individually don't trust not to use mike1234 as a password, I wouldn't trust them as a collective either - at least until N gets impractically large.

This has always boggled my mind - If you don't trust me to pick a decent password and maintain my own machine, why in God's name would you trust me to write code or deploy/maintain company infrastructure?

The downside is that you're now heap allocating at least one object for every state, and I'm willing to bet that each QState has an associated std::vector-style list of actions, and that each action is also its own object on the heap.

If you can afford to do things like this you can most likely use something other than C++ and save yourself a lot of headaches.

Going off my SSH logs, it's more or less correct, statistically speaking.

> The native alphabet for most Southern Slavs would be Glagolitic

That's a bit of an exaggeration, the Glagolitic script was only ever used by scholars, the earliest Cyrillic writings are not not even 50 years older than the Glagolitic.

You're right that the Cyrillic is indeed way closer to the Greek alphabet than the Glagolitic, despite being named after Cyril. I'm not complaining about the "forsaking of culture", I just found it interesting that I was being "mono-cultural" for disagreeing with the existence of a few weird Unicode code-points that themselves are a direct result of someone's attempt to move towards a "mono-culture".

What I'm complaining against, if anything, are overly complex standards. This is just one of what's probably 100 different quirks that you should be aware of when working with Unicode text, and this one could've been easily avoided by just not including a few useless characters.

Bringing up "monoculture" here is hilarious, as this whole situation is a direct consequence of a people attempting to enforce just that by replacing their native Cyrillic alphabet with the Latin one.

My native language also happens to use a Cyrillic alphabet and has letters that would translate to multiple ones in the Latin alphabet:

  ш -> sh
  щ -> sht
  я -> ya

Somehow we manage to get by without special sh, sht, and ya unicode characters, weird.

So taking the first character of a word and uppercasing it is wrong because you'd get "dzen" -> "DZen".

I really wish the Unicode consortium would learn to say "No". If you added a three-letter letter to your alphabet, you can probably make do with three lettets in your text files.

There's so many characters with little to no utility and weird properties that seem to exist just to trip up programs attempting to commit the unforgivable sin of basic text manipulation.

These are programs, not shell commands.

Those are real and well understood benefits, and they're the reason Reddit won. The costs of moving a community from a forum to Reddit are nowadays mostly understood as well, unfortunately they weren't as obvious back then.

When GUI programs mishandle filenames with spaces, IME it's usually because they spawn a subshell in a naive way (system("rm " + filename)).

To mishandle spaces you have to split an input w/ filenames by whitespace, which is not that common of an operation outside of a shell.

If you want simple shell scripts to work, make an actually good shell language without all the footguns.

The filesystem is way more important than /bin/sh and and any complexity added there will trickle down to all programs, not just shell scripts.

It's not worth adding hacks on the FS to patch defects in poorly written shell scripts (which are being replaced en masse with python/nodejs/even weirder yaml files/systemd units/etc... anyways)

It doesn't really matter whose fault it is, the end result is that your users have bad experience on your website.

It's not, it wouldn't make sense to have 100,000 tokens just for the first 100,000 numbers. There's a playground [1] where you can see how LLMs tokenize a string.

12345678987654321 is tokenized on various models like so:

  GPT4                123-456-789-876-543-21
  GPT3                123-45-678-98-765-43-21
  Llama-2, Mistral    1-2-3-4-5-6-7-8-9-8-7-6-5-4-3-2-1

[1] https://huggingface.co/spaces/Xenova/the-tokenizer-playgroun...

I wonder if we'll get better performance on arithmetic tasks if we let LLMs generate digits backwards, e.g. 12345+11111=<rev>65432</rev> where the rev tags are special tokens.

The reason being that there's less context needed to do it this way, for addition at every step there's only 3 digits that need to be considered and they're already in the token stream.

I haven't seen Windows fuck up the EFI partition or delete the other entries in a while now. After installing it the machine will usually boot directly into it, but it should be just a toggle in the firmware to switch back to GRUB.

> Don't use operator overloading for unrelated operations

This disn't stop with <iostream>, they keep doing it - the latest example I can think of is std::ranges operations being "piped" with |.

That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!"

C/C++ are the only widely used languages without a popular npm-style package manager, and as a result most libraries are self-contained or have minimal, and often optional dependencies. efsw [1] is a 7000 lines (wc -l on the src directory) C++ FS watcher without dependencies.

The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui [4] have been some of the most pleasant ones I've ever worked with.

At this point I'm convinced that new package managers forbidding transitive dependencies would be an overall net gain. The biggest issue are large libraries that other ones justifiably depend on - OpenSSL, zlib, HTTP servers/clients, maybe even async runtimes. It's by no means an unsolvable problem, e.g. instead of having zlib as a transitive dependency, it could:

1. a library can still hard-depend on zlib, and just force the user to install it manually.

2. a library can provide generic compress/decompress callbacks, that the user can implement with whatever.

3. the compress/decompress functionality can be make standard

[1] https://github.com/SpartanJ/efsw

[2] https://github.com/nothings/stb

[3] https://github.com/jkuhlmann/cgltf

[4] https://github.com/ocornut/imgui

When their patents include things like "a character stepping on a moving surface and moving along with it [1]", yes, it's litigious.

[1] https://automaton-media.com/en/news/20230808-20590/

can you show an example how? I can't find a case where std::ignore compiles inside a structured binding declaration.

https://godbolt.org/z/sjefeGvPf https://godbolt.org/z/8a7Ps4KdW