I agree that it is handled better in many other languages. However, Go has some weird thing with imports going on. When I tried to learn it I just could not import a function from another file. Some env variable making the program not find the path. Many stackoverflow/reddit threads condecendenly pointed to some setup guide in official docs which did not fix or explain the situation.
After an few hours or so of not making much progress in AOC day 1 I just gave up and never continued learning Go.
Writing scripts for mpv is really fun. I would recommend it for anyone especially for people who are learning programming. There is a lot of room for innovation and creativity. The development feedback loop is quick, interactive and visual.
For anyone already acquainted with emmylua/vscode-lua I'd recommend using my type declarations for mpv—need to push some commits for recent changes but it's completely functional
Exactly. Go and Rust comes to mind immidiately. Both excellent languages in my opinion crafted for the creators need. Although it's maybe not quite what Paul had in mind in 2001, but the world has changed a lot. A community project can't really outgrow these well funded big business language projects.
Does a programming language have to live vibrantly for 3 decades to be "good"? I don't think so. Use it while it's good, then move on to or create the next good thing.
The longer it lives, the more your investment in learning thoroughly it pays off. But languages also have a tendency to accumulate features until taking on a cancer-ridden look. I probably stick to a given "main workhorse" language for about a decade on average. So I would agree that if a language gets a decade of being good, it is about as good as you can expect.
And maybe it wasn't the point. But we'll never know because it was an incomplete thought. Hence the question being asked rather than just making something up
Our Independence Day is probably a special case. Clearly language is flexible enough to say all the formats, but the date format we write matches the most common verbalization.
I think lots of smart people with lots of energy have spent lots of time trying to solve this problem with respect to getting customers and keeping them. It's a hard hard problem. Subscription supporting the free-with-ads IMHO seems to be the sweet spot.
Both Svelte[0] and React[1] are the same in this regard, the key is there as an optimization and isn't required in either framework. The only difference is that React's key is on the element whereas Svelte is as part of the each expression.
I'm not sure that's a fair assumption, one of the original sells of a shadow dom was that manipulting the dom directly is extremely slow, so doing as much work away from it is faster.
Keys are also essential to retaining an element identity, which is structurally more important than performance, because 1) code may have a reference to an element and think that it relates to some data, 2) an element may have an explicit state (like focused, animating, etc).
Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.
Yeah it's not strictly necessary, but if you are updating the list (adding/removing especially), Svelte can know how to reuse elements properly if they are keyed. You also need keys for animations to work properly.
After an few hours or so of not making much progress in AOC day 1 I just gave up and never continued learning Go.