288 karma · joined December 20, 2010
https://www.latitude.sh/pricing/c2-small-x86?gen=gen-2
hetzner doesn't even have specs this low from what i can tell!
https://www.hetzner.com/dedicated-rootserver/#cores_threads_...
I believe we juggle 7 (plus or minus 2) things in our short term memory. Maybe short term memory could be a tool!
We also don't have the knowledge of the entire internet in our heads, but meanwhile we can still be more effective at strategy/reasoning/planning. Maybe a much smaller model could be used if the only thing it had to do is use tools and have a basic grasp on a language.
Just wanted to ask the question - do you think frontier has provided more or less value to the world than gpt-4?
isn't this what abstractions are for? you summarise the key concepts into a new input window?
why do you think that?
Having a type system in place makes minor refactoring possible in this nightmare scenario.
I have been in the situation of poorly written ruby codebases and I can tell you 100% that I would prefer to have a poorly written java codebase with its static types. I prefer ruby as a language but man when it's bad, it's terrible. Just trying to work out the intent of a function when multiple types are passed in as the same argument over the codebase is pure hell.
they are doing an underwater cable to supply energy to singapore
I think you'd like apple silicon macs.
Australians are also fairly trustworthy
I guess it depends how you define mainstream, but in Rust, Rayon has a work stealing scheduler too.
On the other hand, it has existed in Erlang for decades, and Elixir takes full advantage of it.
As for my 2c, I would say Rust is a better choice than Go in terms of the first language to learn. The main reason for this, is it is easy to embed in other languages. When I get to a problem that is too slow in a higher level language, eg. Python or Elixir, Rust is a great way to solve this problem. Just have a look at polars (https://www.pola.rs/).
My previous answer is that good code makes it easy to discover intent.
But I think the semantics are important too - for example in scala we use monad transformers to treat futures (async code) much like lists. But the problem with this approach is it's not clear without inspecting the type signature if you're doing something that has a high algorithmic complexity eg. spawning threads or not.
I think the best language i've ever read for semantics is elixir.
But i think the lack of static typing makes it harder to code review, especially on github. Maybe Gleam is the answer?
What language do you like?
I believe it does 128 bits per instruction, but I'm still struggling with rust w/ asm.
Along my journeys, however, I found this repo https://github.com/WojciechMula/sse-popcount/ which has tons of competing simd implementations for both intel and arm.
This is fine but relying on an IDE for code reviews really sucks. I'd much prefer to be able to do it on github. And it sucks for any language which infers types :( Scala is in particular awful for reviewing on github
> But at this point it's established, mature technology
I have to disagree. Day to day I maintain a variety of node.js, scala and kotlin services. By far, the most gotchas have been from the node.js services.
Simple things like validating incoming payloads are made ridiculously complex. You can get a library to do that, but which do you use? And then most of them don't export the typescript type signature so you don't get any type safety unless you re-define the type in typescript.
Let's say you want a tiered caching library? I've spent weeks of my life debugging concurrency issues because the memory store shared objects whereas the redis store didn't (because they were serialised and sent to redis). That's on the most voted caching library for node.
The quality of node.js libraries in general is far below that of scala/kotlin, and the maintenance cost is way higher. You can't easily tell if signatures for the apis of the libraries you import have changed as well. The ecosystem is still moving very fast, and while I agree that es6+ makes it a much better language, it causes its own issues when interacting with older code/libraries.
Expressive as the language may be, in production systems it leads to poorly understood code because of all the ways to do simple things, and the gotchas associated (something i believe it shares with scala).
> The multi process concurrency model is sometimes a pain in the ass and sometimes just want you want.
Give elixir a serious go and see if you ever say this again. Concurrency should be managed, much like garbage collection has been for 30 years.