In Canada, it seems like there’s a large and growing number of remote jobs available at US software firms through employer-of-record startups like Deel and Remote. Canadian software engineers are surprisingly cheap, relatively speaking, especially when you hire outside the Toronto area.
Economic realities mean there’s quite a bit of downward pressure on CAD right now, so this is likely to continue to be a good deal on both sides for quite a while.
I’m still getting approached by recruiters for Canadian-based remote roles like it’s 2021.
I'm a Canadian resident already working for a US company. I've been out of the job-hopping game since COVID so curious what recruiters and platforms to start poking around on? LinkedIn, etc?
My advice is to check LinkedIn for listings but don’t apply that way. “Easy Apply” lowers application friction so effectively that every posting gets ~1000 applicants of which few are actually qualified. I don’t think I ever heard back on a LinkedIn-submitted application even for jobs where I had rare and directly applicable experience.
In the last six months I’ve been hired once after applying (on the website of the company itself) to s job posting I first saw on LinkedIn. I was poached shortly after via inbound from recruiter on LinkedIn
I’ve used Placemark for well over a year to build custom map-based graphics for torontoverse.com. There are a lot of web apps in this space now, and always QGIS, but I personally felt Placemark struck the right balance between simplicity and power.
Curious to understand what you are suggesting here. What’s a better story for polymorphism than duck typing? What would (better?) null-safety look like in Go?
I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher.
Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both systems, as both operated side by side for a while, Go was inevitably faster for engineers.
Lack of a "default" stack for nearly anything. The stdlib is great but the ecosystem isn't. Which web framework? Does it come with a logger? If not which logger? Do the third party libraries I want to use work with my logger/have a mechanism to provide one via an interface or am I shit out of luck? This goes for so many more things though, cache libraries, data structures (because Go stdlib collections are a joke). Contrast to Java here you have a relatively minimal set of very long-lived deps for all of these "basic" things. Ecosystems like Spring, the slf4 facade, Apache etc provide the foundation that most Java programs sit on and that has no alternative in Go land.
Go module transition was also hot garbage. It's better after sure but going through it was worse than Java 8-9 or to Java 11+ both of which were "difficult" transitions for Java but vastly less disruptive for me personally at least.
Then take all of this stuff and multiply it by the number of teams you have if you don't have a central team doing library choices and laying down architecture guidelines - which we eventually got but not before all the Go codebases had turned into by and large unmaintainable messes.
IMO Go is high velocity only in the simplest sense, it's very easy to pump out shit tons of code. With a big team of mediocre developers this is even more true. The problems all come later. Big change in requirements? Good luck with that.
Had a team try to go crazy functional with Go and now they have immutable data everywhere and allocations are completely destroying the throughput of the Go GC? Good luck fixing that. etc.
The velocity eventually moves from it's strength to it's achilles heel once the codebases are big and bad they are really hard to fix.
I get that most of these problems are "big company" problems and maybe in smaller teams with a stronger hiring bar you won't run into these or maybe not at the same severity but they severely impacted my view of how well the language scales to large teams and codebases.
Teasing this apart I see a few things: a) logging, b) modules rollout and c) missing frameworks.
I’ve never had a logging issue in large systems. Explicit error return (as you know, on every function) allows you to log in your code, not lean on only libraries that support your interface.
Modules rollout was part of growing up. But, you won’t get Go 1->2 upgrade issues as we have 100% backward compatibility on version upgrades. Moving to the latest version of Go is trivial and simply unlocks new features.
Too many allocations for Go is going to be too many allocations for JVM too. This seems like an problem isolated to that team.
I’ve done Go at both a three engineer startup and at Google and I can’t help but notice none of these are really the type of problem that crop up later.
Though I still don't see a standard web stack. "stdlib is enough" is only true for people that don't need their hand held and/or can organise good standards across teams.
If it was just me or people I know are good writing the software that works. At Google it probably works because of aforementioned hiring bar. At the average large-ish company? Not something I like leaving to chance because I have usually ended up disappointed.
Even it's latency is outclassed by ZGC and Shanandoah.
The GC monoculture is great from a simplicity and out of the box experience but there is a very good reason to a) want multiple different GCs tuned for different workload types and b) have competition so that the best designs can be found rather than having to fight to be the only implementation.
Huh, Go also does not allocate ten times more more memory like Java. So even if Go's GC is 1/10th performant as Java (and it isn't) it will be equally better Go applications.
Java's GC improvement is relentless because Java's applications are relentless in memory allocation.
Being on endless Java memory/perf issue prod calls I can say Java GC improvement, performance tuning is cottage industry in itself. Meanwhile end users keep suffering but at least Java devs get to tune GC to their heart's content.
I’d love to see you elaborate on this. Anecdotally, my experience was the exact opposite. Is there some documentation making this point?
In the course of optimizing I came to know the various JVM GC algos (concurrent mark/sweep, parallel old, etc) by the corresponding memory graph alone. I never, ever had to debug similar latency in the Go stack.
Both of those are only picked for low sized heaps with few cores, probably within a container. Were these micro services?
G1 is the default for larger heaps and multiple cores, and ZGC and Shenandoah (low latency GCs) have to be manually turned on AFAIK.
OP said:
>Java doesn’t slow down the allocation rate, it tries to keep up with the churn.
This is incorrect. ZGC will block a thread when it cannot give a thread any memory, because it can't collect and free memory at the pace needed. Google "allocation stall" for this. ZGC can achieve very low latencies akin to Go's GC, I don't know if the throughput is higher or not. Multiple cores and some GiB of heap space is when ZGC will shine.
No web framework, the standard library is enough. log/slog is in the standard library now, and is compatible with zap, which seems to work with everything.
>IMO Go is high velocity only in the simplest sense, it's very easy to pump out shit tons of code. With a big team of mediocre developers this is even more true. The problems all come later. Big change in requirements? Good luck with that. Had a team try to go crazy functional with Go and now they have immutable data everywhere and allocations are completely destroying the throughput of the Go GC? Good luck fixing that. etc.
I doublt things would go better for teams trying to go full OO in haskell, or full functional in Java.
The stdlib really isn't enough unless you want num_teams x session handling implementations etc.
> I doublt things would go better for teams trying to go full OO in haskell, or full functional in Java.
That is the beauty of Java, no one does this.
They don't feel like they need, should or will get approval to.
Go is pretty much the wild west because "the std lib is enough" attitude permeates everything. Build your own datastructures, build your own anything really.
I can understand why many people find that attractive and hate Java as a result, sometimes Java feels more like Lego and less like programming but it does create predictable reliably constructed software that is generally easy to clean up even if it's done a bit poorly.
Which is something I value because I often end up in the code janitor role and/or being air-dropped in to get a project back on schedule or drastically cut down the defects etc.
I write a lot of Go and I can’t tell you how much this warms my heart.
Compatibility probably isn’t much fun for the language team, always having to keep one foot firmly in the “distant” past. But for those of us that have to maintain large Go systems it’s such a gift.
I worked on the Go compiler for a couple of years, and it wasn't a big deal. We just thought carefully about things, and dealt with a lot of rejection of ideas. If we couldn't make it fit, it wasn't right, and we'd try again. If we still couldn't make it fit, we probably didn't have a good handle on the problem, and it was right to stew on it longer.
Frankly, I truly appreciated working with people who thought carefully and tried to make sure the right ideas were in. I appreciated Russ being a BDFL, Ian, Rob, and Rob. I'm glad I did it, and it made me a much better engineer.
He usually goes by JM Fortier on YouTube and I think he’s great. He’s a real inspiration to me, for sure. He’s very open and has a lot of stuff up there on various channels about the development of his market garden.
He’s great if you want to garden as a business, but if you have a bit more flexibility and time, I’d recommend permaculture as a sustainable and lower cost starting point. Bio—intensive farming like Fortier advocates is great but more expensive to start.
Just to be pedantic, I’ll point out that’s literally “transparent” matter and we use the term “dark” which is really more appropriate for something that absorbs EM radiation because it also implies the mystery of the holes in our knowledge. English is great.
Hiawatha is more than just a leader he’s essentially a religious figure to the Haudenosaunee who historically reside in roughly the area around Lake Ontario.
It is definitely in bad taste to take a meaningful symbol from an existing marginalized culture and use it to brand your open source project because you think it sounds cool. But, this is something that was not widely recognized as bad until very recently, especially outside North America, and obviously this already happened a lot in the past so I don’t think it reflects badly on the authors or contributors at this point. That said the name should change and, at bare minimum, that cartoon has to go.
It’s a great idea, though, for us all to learn the real story of Hiawatha, the Great Peacemaker, Jigonsaseh, Tadodaho and the origins of the Five (now Six) Nations. It’s not an exaggeration to say that it helped inspire the structure of the early USA. It’s also a refreshing alternative take on power and leadership from what we are usually shown in the West. One of the world’s great cultural treasures, I really think.
Very interesting piece of history right there. Just out of curiosity, what is your thought on the feather logo used by Apache? Is that something that needs to go as well?
