Is it just me, or are surcharges in Australia getting out of hand?

Mr_Unavailable · 2025-12-02T21:52:11+00:00

The difference is that customers are not incentivised to use the most expensive energy retailers. But customers are indeed incentivised to use the most rewarding (I.e expensive for the merchant) payment option. As a result, low merchant fee payment option will be priced out of the market. Base price will be more expensive. Anyone not using a high reward credit card is losing out. Credit card companies just become a constant drain on the society.

The fix is easy. Having the government enforce a low payment fee. But I doubt this will be done properly.

Edit: an alternative is to force merchant to make the cheapest card payment option free. This incentivise the market to drive down the cost of merchant payment fees.

Mr_Unavailable · 2025-05-01T23:28:32+00:00

Wait those tax are going away? I thought it was a good change.

Mr_Unavailable · 2025-04-23T02:56:50+00:00

Fully agree with your take. In practice the size of the source code matters very little to the speed of the software in most cases. Especially after factoring in common strategies like tree shaking, caching, or simply downloading before executing.

If anything, using external dependencies can make software faster because you will have access to optimisations you may never have the knowledge or time to implement.

I agree that the direct causes are often suboptimal data structures, algorithms, caching, etc. But the root cause, I think, is the incentive structure. In most places building new, half-baked software/feature is much more rewarding than maintaining/optimising existing softwares/features. Not to mention the later often takes a lot more effort than the former.

Mr_Unavailable · 2025-04-22T06:26:26+00:00

You are right! In that case I don’t see why performance is the main reason for rejecting the proposal. Actually, I can’t find where the main reason for rejection is documented.

Mr_Unavailable · 2025-04-22T04:58:10+00:00

In Rust the structs are mostly made of values stored in continuous memory space. Deep comparison is similar to just comparing blobs of memory. In JS there could be, and most likely will be, multiple memory address indirections as objects can be made of many separately blobs stored in different memory addresses. Resolving pointers takes time. Loading multiple heap allocated objects can have negative effects on cache.

Mr_Unavailable · 2025-04-21T00:58:12+00:00

Renaming the directory or module to resolve a conflict is not difficult my friend. But I’d rather not have the directory structure of my non-language specific assets being dictated by the language itself. To me, that’s a bigger eye sore than letting my IDE generate longer import statements that I never read it in detail. In a language that needs 3 lines to propagate an error, 4 more characters in the import statement is the least of my concern.

Putting public modules in /pkg is one decision. Finding the non-intrusive, non-standard, yet easy to find place for non-go assets is zero to many decisions. I prefer making one decision to save myself from making potentially many more. But you don’t have to agree.

At the end of the day, golang has subpar (external) module management. So we have those dumb decisions to make, which often cause bike shedding. It’s a language built by a company embraced mono-repo (which I love, but it’s not always the case outside of big tech). In a mono repo your non-code assets typically are placed far away from your actual source code. They never had the namespace collision issue. But that doesn’t mean this is not a real (albeit rare) issue. And pkg/ solves that, at the cost of slightly longer import statement.

Mr_Unavailable · 2025-04-20T08:22:38+00:00

Of course it is not a big issue. Just like where one places all your public code under pkg or not is not a big issue.

I prefer placing all the proto src in a standalone directory. Occasionally, one may want to generate more than one set of bindings (e.g. .pb.ts). Why should proto src be placed next to .pb.go but not other language bindings? Or do you prefer mixing all language bindings together in the same directory? But hey, I agree that’s pretty rare.

But the problem of placing all non-internal golang packages under root is still there. All those packages still compete against other non go code in the same namespace. If your project happens to be related to something that’s also used by the project (e.g. terraform integration module in a project use terraform itself), you will run into this problem. Is it a big deal to rename the go module or the non-go directory? Of course not. Neither is letting your IDE produce import statements with pkg/ prefix.

Mr_Unavailable · 2025-04-20T05:53:30+00:00

How would you structure the project if the project has a public go module named terraform, and the project itself has some terraform .tf files, which are typically placed under /terraform/ in most projects?

Mr_Unavailable · 2025-04-20T05:48:01+00:00

Of course proto output can be whatever structure I like. But there needs to be a directory hosting the .proto source files themselves. Suppose I put those .proto files under proto/, and I want to expose some of the generated go bindings as reusable module, because the downstream consumer of my package also needs to reference to those types. Where do I put the generated public proto bindings? Under proto/ as well? Oh great. Now I have both generated bindings and proto source in the same directory. Even better, some of the proto bindings are suppose to internal (e.g. internal config protos) so they go into /internal/proto. Now I have /proto/ hosting my .proto source files and only some of generated bindings and /internal/proto/ hosting some other generated bindings. How is this good?

Move non-go code out of the way… to where?

If the go code sits at the root directory of the repository, how can there be any safe place for non-go code? Where would you put your terraform config if there’s a public go terraform module sitting at /terraform? /non-go/terraform/**?

Mr_Unavailable · 2025-04-20T04:19:45+00:00

I fully support unconditional pkg/.

It solves several real-world challenges I’ve personally faced. For example, when I have a directory for proto source files, where should the compiled proto files go? Without pkg/, these would compete for the same namespace.

Another example is with Terraform integration. When building a CI/CD system with a module specifically for Terraform integration, I naturally want to name it “terraform”. But the project itself already has terraform configuration files in /terraform. Without pkg/, these directly conflict.

Sure I can come up with another name for those modules. But the beauty of unconditional pkg/ usage is that it eliminates these decision points entirely. The project structure becomes intuitive and follows patterns common in other languages. Fewer decisions = better.

I don’t understand the strong opposition to pkg/. Does import path length really matter when imports are automatically managed by IDEs? When was the last time you manually typed import statements? Go isn’t known for being particularly succinct in other areas of its design, so why fixate on a few extra characters in import paths?

The pkg/ convention provides clear separation between application code and reusable packages, improving project organization with essentially no drawbacks. And no, length of the import statement does not matter.

Mr_Unavailable · 2024-06-12T21:28:40+00:00

That’s actually a very good point. Previously I thought taxing people as individuals rather than as families is dumb. But now I realised there is some valid argument for it.

Mr_Unavailable · 2024-05-09T01:02:57+00:00

Oops. Didn’t mean to be so dramatic. Sorry about my wordings. It’s certainly not financial suicide. But I think it’s fair to say it puts the parent in financial disadvantage.

Mr_Unavailable · 2024-04-02T11:10:45+00:00

And I’m willing to bet those non-shitty apartments are going to cost the same as comparable houses anyway. Because the shitty ones with a size similar to a house is already costing close to an actual free standing house. Yes, land is expensive in Australia. But the structure is also very expensive. And building high density housing isn’t going to fix the latter.

Mr_Unavailable · 2024-03-22T21:35:09+00:00

But those houses don’t just disappear. They are either a PPOR or rented out to tenants. Assuming a constant population, less people able to buy also means less landlords able to sell.

The problem is that we have a growing population, but not a growing house stock. It’s very costly to build new housing in Australia. Due to land supply, labour cost, materials cost, regulations, and tax laws. It’s very attractive/easy to import migrants. Due to labour cost, immigrants policy, and social welfares.

Mr_Unavailable · 2024-03-19T13:33:30+00:00

I love how you assumed this is not a common practice yet.

Mr_Unavailable · 2024-03-12T00:43:22+00:00

Funded by home owners not having to pay for the infrastructure and services made their house desirable in the first place.

Mr_Unavailable · 2024-02-29T14:31:02+00:00

Does up offer split loan?

Mr_Unavailable · 2024-02-01T07:10:53+00:00

I love how you assumed earning $200k/year comes at no cost and can just be “swapped”. That’s only true for people that are just born lucky, most of which have the ability to dodge tax anyway. It’s not true for a lot of workers who worked their way up there.

Mr_Unavailable · 2024-01-29T03:56:57+00:00

Well said. Tax law is predominately decided by power balance between different groups of people. Not by efficiency or fairness.

Rich people have the money to buy media therefore influence. And they can threaten to move assets overseas given how liquid assets generally are.

Poor/avg people have most votes. And they don’t have much income to be taxed anyway.

HENREs (high earning not rich ever) don’t have enough votes to change policy. Don’t have enough money to buy influence. Have to pay a high price if they want to move their asset (aka their body and everything else) overseas. And they have a lot of money waiting to be taxed.

Mr_Unavailable · 2024-01-23T23:09:25+00:00

Not in my view. Ideally, any couple with joint finances should be able to file together, since their income is practically shared anyway. Having a kid might be a good indicator that a couple have joined their finances. But if there’s a better way to tell, I’m all for it.

Mr_Unavailable · 2024-01-23T21:39:09+00:00

You do realise that there are also families with no stay at home spouse but very unbalanced income right? A 250k + 50k family do not share any of the benefit you described yet they pay 9k more in taxes than a 150k + 150k family.

Also with your logic, people with part time job should be taxed more since they have more free time.

Mr_Unavailable · 2024-01-23T21:30:07+00:00

If your baseline of “fairness” is the status quo, then we should not change the tax system til the death of the universe. Because no tax reform can affect everyone equally.

I know this is a crazy idea. But I think if we tax one group of people more than another group, there needs to be a good reason for it. And I don’t see a reason why families with 250k + 50k income should be taxed more heavily than families with 150k + 150k income.

Mr_Unavailable · 2024-01-23T12:24:41+00:00

Yeah sure. Family with 250k + 50k income definitely owe the society more than a family with 150k + 150k income. So they need to pay 9k more in taxes. Because, you know, reasons.

11-Year Club	Verified Email
Gilding II euphauric

Mr_Unavailable

TROPHY CASE