marcus_cemes

> the w3c standards define, that browsers execute the commands they receive from the server

I'm no expert in the matter, but this seems a little convoluted to me? To me, the server does not issue instructions, per se, it returns a declarative text/binary response that describes the sturcture of the website, it is then up to the browser, that the user installed and chooses to use and may configure (and possibly configure to leak their data, even if spec-adhering behaviour of rendering the webpage should not), to attempt to understand the document and retrieve any other resources that may assist displaying the content correctly.

On the other hand, if one was to send CPU instructions back to the user, I guess it's also there choice to execute them...? Also, it's not possible to determine which resources are for display purposes (fonts), and which are for tracking purposes, the browser will blindly have to retrieve the resource, so websites have a certain responsibility to issue privacy-respecting "instructions".

I'm trying to argue both sides here, I still believe that the user chooses voluntarily to use the browser, visit the webpage and therefore parse the document and initiate any subsequent requests that the document proposes, on the other hand, this is beyond most people, they just want to view a frickin' website, so perhaps the lives of web developers should be made harder to make the lives of the average Joe, who is not an IT expert, a little easier? The architecture of the web is inherently not privacy-respecting, in order to save bandwidth (and for sake of simplicity), we only send fragments and let the browser choose what else it needs, which can be tracked.

It's like walking in a park. You choose to show your face to people, we've come to just accept the fact that by the laws of nature, we cannot prevent other people from seeing our face (unless you use a mask, but then you make them very uneasy), we leak data that others can remember and use to identify us later.

Well, yes, to my understanding. If you add lang="ts" to the script block, you can write normal TypeScript code for the component logic, and it will also check props that you are passing to child components in the template. It's like renaming the file from ".jsx" to ".tsx". It might not be perfect, but I haven't encountered any problems with it so far.

It might interest you that Wikipeida chose Vue to modernise its frontend in the future [1]. Different frameworks offer different benefits and different downsides.

React is not the end-all, nor will it ever be, as long as there are interesting new projects coming out, and neither is Vue or Svelte. My website uses React, but personally I would rather use Vue or Svelte in the future.

[1]: https://phabricator.wikimedia.org/T241180

Well, good news for you, it does! Very well, in fact. Svelte itself is written in TypeScript.

I'm not sure about "$some.prop = avalue", but props are declared as exports of your component [1], and they can be given types. Perhaps you're refering to "$$props"? The only time I've hacked into the component variables is to check whether slot is set.

[1]: https://svelte.dev/tutorial/declaring-props

I was initialy excited to try learning Elm, until I saw some of the drama on the GitHub issues and a blog post about leaving the Elm ecosystem after having a bad experience with the project leads (I think [1] was the post).

I've since put it in my little red box of "hot but you'll be better off staying away from", depsite the numerous podcasts praising the incredible effort and design that went into the language. Has anyone got any thoughts on this?

[1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

> Amazing projects like esbuild, SWC, and bun solve the first half of the problem, emitting JS from TS, but they skip the critical type-checking phase completely due to complexity.

I love the idea behind it, but I'm also wary of now potentially having yet another tool that only solves "half of the problem". Could this potentially be contributed/merged with SWC in the future, seeing as it's also Rust-based?

> One worry that I have with async rust is that the executors are so complex that the "baseline complexity" starts rather high.

I completely agree, however I like that you have the option to swap out the executor for your own if the situation requires it, which I think concerns a very small number of applications. In other languages with a baked-in runtime you would be left trying to come up with workarounds to make it play nicely.

Sounds like a lot of mental work just to log in. Or... Try a self-hosted password manager, or one that generally has a much better reputation?

I like the ligatures in Fira Code. I find the arrows, boolean operators and the pipe symbol "|>" a lot easier to read as symbols instead of three seperate characters. I can understand why some people would dislike them. I'm not sure about merging together regular letters, although I haven't actually ever noticed this.

In my mind it depends on where you are on the spectrum, the hardcore programmers that are one with the code and want to see every letter in a terminal editor and those that stray more towards the designer and practical side of programming. Just do what works for you, and get burned, otherwise you don't learn but endlessly follow "best practice" advice.

Same here, I've been using PotPlayer with MadVR for years on Windows. HDR, resolution and framerate matching worked beautifully, long before Windows had proper support for HDR. Even now, some HDR content just looks wrong in other media players.

MadVR know their stuff, they recently announced a very expensive home theatre video processor [1].

[1]: https://madvrenvy.com/

From Google's response:

> If you are unsure what Android version you are on, confirm you are running Android 10 or above

My Xperia X is still on 8.0.0, it only got a few months of updates before they just silently stopped sending them, displaying that my "device is up to date!". This is a widespread problem in the Android market, in comparison, my iPad Air 2 is still getting updates 8 years after release. Google keep saying that they want to work on this, but realistically, is it ever going to happen?

Does anyone know how Python/Django compares to something like Elixir/Phoenix?

That's great! I very briefly went through the introductory docs, but otherwise I just dove right in. The language is really simple, the tough part is wrapping your head about immutability.

There's an awesome repo with examples in pretty much every language [1], I go there afterwards to learn how other people did it. It's amazing to see so many different ways of approaching the problem. My solutions are also public [2], but bear in my I'm still only a few days in to learning Elixir!

If you do want to try attacking AoC with Elixir, I suggest you research and understand these concepts, it's more than enough to get you going:

- Pattern matching. The "=" sign is _not_ an assignement, it's trying to fill the shape of the variables on the left with the stuff on the right.

- The pipe operator "|>", the return value of the previous function is implicitly as the first paramter of the next function, it makes it easy to build chains.

- There is no "return". Use small functions with `case` statements, or function overloading. The last value in a function is implicitly the return value, like in Rust.

- Enum.map(), filter(), reduce(), zip(), chunk(), these functions largely get you through the manipulation of data. The first three are very popular in JS.

- Immutability. There's no mutating data, hence why you need reduce() for example.

- There are no loops, instead, get used to doing recursion. hd(), tl() are useful for this.

- Anonymous functions `fn a, b -> a + b end`, there is also a shorthand form `&(&1 + &2)`, and you can also pass functions by reference `&sum/2`

- The "/1", "/2", ... after a function is the arity, it's not scary, it just means the number of paramters that it takes.

- Function overloading is amazing, it's like pattern matching. If you provide constants in the function declaration, it will only be called if those constants match:

```

def factorial(0), do: 1

def factorial(n) when n > 0, do: n * factorial(n - 1)

```

I find the above really elegant. It's correct, the special case for "0" is very explicit, and if you try a negative number, Elixir will simply be unable to match the given problem to a function definition (n < 0), which makes more sense than throwing "BadArgument" errors/exceptions.

If you really want to just solve problems, I advise sticking with Python, there's nothing wrong with it. Most languages also provide a lot of functional concepts, I'm sure Python is no exception (with some libraries). Be prepared that functional languages require you to think differently, but it is really fun to do things in a functional way!

Good luck!

[1]: https://github.com/Bogdanp/awesome-advent-of-code

[2]: https://github.com/MarcusCemes/advent-of-code-2021

I will never forget the first time I started IEx from within a Phoenix project, and found that I had a live shell into the running application, while the Phoenix development server was running and reachable from the browser, all with hot code reloading... No need to create a dummy REST endpoint to try running a function.

My mind was blown.

I understand, but a lot of my refactoring is within functions to simplify and improve legibility once they work, renaming variables with generic names from "result" or "data".

It's a lot faster to do a cheeky F2, knowing that it's not a blind find/replace but a static code analysis with the ability to understand variable shadowing. Definitely not a show stopper though, and it feels more old-school, where every letter you type is more meaningful, if that makes sense.

And a huge +1 for José Valim and the whole community behind him!

After seeing Elixir pop up so many times on Hacker News these last few months, I deicded to give it a go for the Advent of Code.

It's been pretty amazing actually, it takes a little getting used to, but it really feels like a language that was designed in every way possible to be ergonomic and productive. I'm still not sure whether it's easier to read purely functional code over a few mutable variables and simple loops, especially with a lot of filter, reduce, scan, zip, etc.

It's been pretty amazing so far, I haven't gotten further than IO.inspect()ing yet. The language server is still leagues even behind something like Rust analyzer (even renaming symbols is still a work in progress), but it's amazing that such a language already has one of the leading web frameworks (Phoenix), and despite being very network orientated, it's also excellent at solving AoC problems that involve a lot of clever manipulation of strings, binary, integers, and the sorts!

I've used LaTeX for the duration of my Bachlor studies. The results are superior to Word, but that's just about where the benefits end. It's a nightmare to use and I don't see how investing time to learn it will benefit me in the long run.

It's burning electricity (that could in an ideal world be renewable, maybe one day) to provide a service to the network, therefore making it more secure by providing additional processing capacity that is controlled by a good actor, making it harder for a bad actor to get 51% of the pie. It is a waste, but there are also a lot of other sources of wasted resources/energy that we could tackle first and get larger returns from.

You get compensated for your service, it may seem like a lottery, but if you do it for a long enough time, you'll get fairly steady returns as in theory it should be random and proportional to your hashrate.

I don't mine, and I think it's definitely overhyped at the moment, but maybe it will settle in the future and actually provide a useful service to us folk. It doesn't seem to be going away for now, and it is really easy to send money to friends and family, whether they're nextdoor or in another country.

I'm glad that they're trying to make their voices heard, but I hope this doesn't have any long lasting effects on the Rust community/ecosystem as a whole. We all (mostly) want to see Rust succeed, but we're struggling on our way there.

There are a lot of companies on the edge about investing into Rust in my opinion, there are a lot of reasons for, but it also generally just feels so unstable and easy to rock.

Being at the centre of controversies, such as the one with actix-web, gives it a bad reputation even outside Rust circles.

Shoutout to Elixir/Phoenix for a (performant) backend.

I pay $5 a month for 5 family members on 1password. I use it every day, it's as important as my credit card.

Every other subscription based service seems to target the $10 range, even if you use it only a few times a month. Theese costs add up, I understand the concerns of unexpected bills in pay-as-you-go, but it's also a lot easier than commiting to much more than you need. I don't have any movie-streaming subscriptions, but how is someone supposed to keep up with Netflix/Disney/HBO/Amazon Prime and the lot?

I've heard good things about https://gohugo.io/ (written in Go) and https://elderguide.com/tech/elderjs/ (uses Svelte), I've never used them though

I find it fascinating that there are people still using script tags. I have personally become so tied to npm and typescript that it feels that I'm programming in a completely different language and ecosystem, with a build process and IDE-like type checking and linting, a more procedural data-oriented C-like paradigm.

I've never touched the old JS guts, `module.exports`,the prototype chain, ... Babel (and later TypeScript) allowed me to live in ESM land from the beginning. I expect any tool/library to be available using exclusively on npm, in reality, I've been constantly fighting with it over the past few years.

I usually get a shock when I see libraries still offering minified bundles that assign to the global namespace, to me this seems like outdated practice, but I guess that this is still really prevalent in JS, even in 2021. I sometimes want to go back to it, with the amount of configuration and boilerplate necessary to set up a project with npm, Prettier, ESLint, Typescript, Webpack/Parcel/Rollup, SPA vs MPA, React vs Vue vs $SPAFRAMEWORK, it was a lot easier back in the day.

I think the biggest failure in the JS system is the lack of standardisation, it's so versatile that almost anything is possible. A number of different module systems were invented to solve the initial growing pains (the first would literaly replace a `require()` function call with the contents of the given file), and we never escaped them as they became the foundations of Node.js/npm. Then we needed a non-blocking variant, so we just called it `import()`, it returns a promise. Then we wanted proper imports, so we invented the `import ... from ...;` ESM syntax. We made a named import and default import variant (with most bundlers offering a compatibility layer with CJS-type exports, so imports now have a hidden `__esModule: true` key...). In order to stay compatible with legacy CJS, we also added the `import * as ... from ...;` syntax as an escape hatch?

When TypeScript came along, in order to be compatible with JS it became common practice to distribute compiled TS code along with the source code, with an adjacent declaration `.d.ts` file to provide type information. The source code was never leveraged in any way, and so people just stopped shipping the `src` directory, only `dist` and a `package.json`. It makes debugging a pain, but compiling TS libraries would have been tricky, considering the widely varying different feature flags (async, DOM, ...) and strictness options. Perhaps Deno will help with this to some regard. The great thing about Go or Rust (or any other language, really) is that you import source code, not illegible compiled code (unless you're dynamically linking). I believe that Rust is especially good in this regard, it remains compatible with older code by requiring crates to specify a Rust "edition".

Why are we in this mess in this first place?

And why has it remained so darn popular?

Correct me if I'm wrong, but:

- GC pauses, Rc<T> does not, it's simply a deallocation by the last reference holder

- Rc<T> still has predictable memory allocation/deallocation, GC is not guaranteed to run until needed

- More efficient memory use, no need to keep track of allocated objects

- The rest of the Rust language is a pleasure to use (imo)

- Python is slow for certain applications, and not concurrent

- Kotlin is kind of more niche than Rust, it's very popular in the Android community, like C# is popular on Windows

Just my 2 cents, I love progamming in all languages. There are some use-cases where a high level language is absolutely the way to go. For others, Rust provides much more control with a handy escape hatch. Absolutely don't go wrapping everything in Rc<T> like a madman, only when the reduced complexity is more beneficial than dealing with references/lifetimes.

Yes, I completely see your point. I really enjoyed using Koa on its own (still in production), and have recently come to respect Fastify after listening to a JS Party podcast with the author. I'm seriously considering going with a lightweight library, as satisfying as annotating routes with decorators is, I'm not sure the benefits out outweight the problems its caused. But I'm also a fan of not having to re-invent the wheel every time I want to make an application...

There's nothing wrong with old-school, but I do feel a dagger going through me when I see `var Protocol = module.exports = function () {` as a function declaration in a modern codebase. My TS code looks very similar to Rust or Go code. The fact that such syntax is possible is paretly why I want to move away, even if it does show just how versatile JS really is.

I'm a bit more worried about dropping an ORM. I've also tried knex + objection for my own website, but still feel it's not quite there. Pure SQL scares me, especially with TypeScript. It feels like a lot of boilerplate for different entities and very little safety in case of mispelt SQL queries, but I respect the power and simplicity of SQL.

I'm not sure Docker gets much love outside of the cloud. Writing a Dockerfile is wonderful, actually reploying and running them is a whole different story... It's a very practical tool, but I'm not sure it can live up to the academic status needed to teach it.

Valuable to students, yes. But it all requires solid reasoning and justification, and that's perhaps harder for a student :D

Thanks for those, I agree. Although I think the term invest you used is very applicable, there'll definitely be a larger barrier to entry.

I don't think they've every heard of Rust and it is a relatively minor project for a small section of the uni. As much as I would love to jump on the Rust bandwagon, I feel more confident that Node.js would be a more "justifiable" choice. It might be easy to understand well written Rust code, but trying to implement something new will need an understanding of lifetimes and memory management.

I would love to see Rust in the web spotlight, it shares blood with C/C++, but it has real potential in higher level abstractions as well. It would be great to have a solid go-to web framework, like Phoenix or Rails, we'll have to wait and see. Good luck with your own endeavour!

Too true. I'm just wondering whether an ecosystem with better design and first-class developer tooling (unified linting, formating and compiler and native module system) might be easier than having to learn the Node.js/TS/Prettier/ESLint stack, even if pointers and memory management might seem a bit scarier at first.

Being a mechanical engineer student myself, I can see where you're coming from, however, I have to respectfully disagree.

It's true, most professionals use off-the-shelf solutions, the Office/Adobe suite, or other proprietary software like Catia, Autodesk, the likes. I have been nothing but frustrated by these options. I have dealt with gigabyte Illustrator files, as the inexperienced user accidentally embeds all linked media. I have been increasingly frustrated with "made up marketting terms" when saving Adobe proprietary formats, or OneNote's "invisible formatting language". I make a new line, then remove it, and whoops, the whole paragraph has been reformatted, all the equations are no longer in italics (despite this, I still use it for all of my study material, it's fantastic)! It helps to have a Markdown-like mental model when dealing with word processors, you understand the data hierarchy, which is at the end of the day underneath all of that GUI, most people I know who use Word make an absolute mess of the document because they have no idea how to have a consisent layout, they add new-lines, paragraphs, tables, fonts and indententations all over the place and then get frustrated when they don't get the desired results.

While Markdown may not be the best format with the most features, it has a fantastically consistent layout and it's easy to understand the hierachy of information. There is no obligation to use the terminal, you can open it in any visual editor. Also, I would not call the fact that it's plain text instead of XML/binary a limitation but rather a feature, not a "remenant of the 1970s".

There is something amazingly refreshing about knowing that what you see is what you get, I can't stress this enough. Instead of using buggy program that manipulates a mess of an XML file, you describe the layout from scratch and that gets "compiled" to a PDF. This is why programmer source code is written as text, and not in Word, for example, it's just plain information that any compiler can work with to achieve any sort of complexity. There is no hidden document metadata, there is no hidden bloat from [insert proprietary software here] having upgraded the document format several times over the years until it eventually corrupts something (I'm looking at you Premiere Pro, every major version requires you to upgrade your saved project, making a new copy "just in case", it's impossible to go back, and I've had it break several times). It's a single source of truth that describes a behaviour, and the compiler can get better over the years and generate better and better executables from that same code as it improves.

This is the worst argument ever, but it's still an important one: it's free, and works on any OS. There are definitely advantages to using off-the-shelf software, I myself am a heavy user, but I cringe every time I have to work on a messy document with other students, recently I had to work with another student that has macOS and could not get Word to open the document and display equations without converting them to images...

I find the Markdown/Word comparison similar to my experience with Docker and Windows, for those that are familiar with it. Windows, macOS and Linux (although Windows is the worst offender) get bogged down with bloat over time, dnagling files, layers of abstraction, derived from complexity. How many times I wish I could start from a base image, and add/remove (software) features as I go, like building a new Docker image, without losing data.

You bring up scientists, granted, not everyone uses it, but I believe LaTeX is more comparble to Markdown than to Word. It has a text-based source format that gets transformed and rendered as a PDF, but it's way, way too complex for the majority of use cases. If there's a better alternative to Markdown, I'd be glad to try it out, but for now it's my main choice for the long-term storage of information.

No worries, I've always been more interested by the technical aspect more than the creative aspect of filmmaking, hence my interest in programming. It's a personal project, I've been making films since the age of 11, although I haven't been able to do much since I started my Bachelor degree...

I encode H.264/AAC for compatibility, usually 2-pass at 8Mbit/s for FHD content or around 30Mbit/s for UHD, 256-320 kbps for AAC. This gives a size of 1-4 GB per video. My Dad worked in broadcast, gave me those figures 10 years ago, I generally stick by them for any work I'm proud of!

You are right, that bitrate absolutely isn't necessary :D , and there are better codecs too. I don't have more than 17 films at the moment, the whole backend costs me about 4 euros a month on Hetzner with an attached 32 GB of block storage, no bandwidth costs (300Mbit/s max), single-core running Node.js and Nginx.

I make films during travel and events, and share them with friends and family who were there and for who it has some intrinsic value. They're mostly personal, not just for consumption. Short compilations that I would like to keep for the future, like old photos. Hence why people watch (and hopefully rewatch!) them on a TV and don't mind the wait.

Buffer-less streaming is absolutely not a priority (although nowadays I think it's more expected, people have shorter attention spans, despite the hours of work that goes into a short travel film). It's a very niche case, but would have cost me at least $50 in bandwidth alone with the big three. It's not going to break the bank, but it's also unnecessary.

You don't usually notice the drop in quality on YouTube or Netflix, until you actually try working with high quality source footage (high-bitrate from a dedicated camera, not phone footage). Then it's very noticeable (purple/green flickering on even surfaces from chroma subsampling, I'm guessing), and makes you sad when you realise what everyone is missing!

If you're still curious, my website is still live. I beg you not to judge, I started making short films very young and never got very good at them either (I'm studying nanotech & engineering, no film career for me)!

https://mastermovies.uk/glacier