From an employer's perspective: Why hire someone if they're going to be remote? Then I might as well hire someone from Brazil. Almost the same culture, 1/8th the price.
What's the difference for me as an employer if someone is remote from 10km away or 5000km away?
It's great that you feel like you're more productive at home, but it's still capitalism with supply and demand, and there are much cheaper remote employees with exactly the same webcam stream.
> What's the difference for me as an employer if someone is remote from 10km away or 5000km away?
There is not - hence there are about 1.5 million software developers in the United States and approximately 1 million just in India alone. Probably another million in other countries across the world (I have 26 on my team working from the Balkans for US company).
already at present there are more devs working offshore than onshore and that trend will continue to grow
You would get laughed out of the room if you limited your customer base to only those within commuting distance of your office, but for some reason with employees, the model is different? You want the broad market TAM but the local employee control.
Certainly, if you think you can hire in Brazil, why have you not attempted to do so yet? The only way for you to know for sure if this model would work is to attempt it. I do wonder if the US is going to begin to tariff goods coming in from outside of the country, if they will also start to look at offshore labor to penalize economically.
Offshore labor is already penalized: For tax purposes under Section 174, costs for US devs must be amortized over 5 years, while costs for offshore devs are amortized over 15 years.
And yet, many firms continue to offshore to Central America, South America, Eastern Europe, and India for technology labor (Africa as well for ML/AI data labeling). Lots of room for policy to run here.
I work at a firm where Brazilians took over engineering management and I see the end results of VERY poor engineering culture and a tribal knowledge is rampant. Sloppy engineering and a lack of empathy in user experience and insular thinking, as they are isolated from current approaches to scale, toil elimination prevalent in Silicon Valley approaches.
I cannot agree less, C++ is the best and always will be. You youngsters made up this new dialect that can also compile with the C++ compiler. This is like people putting VS Code in dark mode thinking they're now also working in the Terminal like the Gods of Binary.
I expect they are thinking of the "Safe C++" proposal P3390. This proposes to provide the syntax and other features needed to grant (a subset of the future) C++ the same safety properties as safe Rust via an equivalent mechanism (a borrow checker for C++ and the lifetime annotations to drive it, the destructive move, the nominative typing and so on).
Much as you might anticipate (although perhaps its designer Sean Baxter did not) this was not kindly looked upon by many C++ programmers and members of WG21 (the C++ committee)
The larger thing that "Safe C++" and the reaction to it misses is that Rust's boon is its Culture. The "Safe C++" proposal gives C++ a potential safety technology but does not and cannot gift it the accompanying Safety Culture. Government programmes to demand safety will be most effective - just as with other types of safety - if they deliver an improved culture not just technological change.
That sounds significantly more like C++ trying to be a dialect of Rust, rather than the other way around. I don't think that was the GGP's main gripe.
But more importantly, Safe C++ is just not a thing yet. People seem to discount the herculean effort that was required to properly implement the borrow checker, the thousands of little problems that needed to be solved for it to be sound, not to mention a few really, really hard problems, like variance, lifetimes in higher-kinded trait bounds, generic associated types, and how lifetimes interact with a Hindley-Milner type system in general.
Not trying to discount Safe C++'s efforts of course. I really hope they, too, succeed. I also hope they manage to find a syntax that's less... what it is now.
I don't think Safe C++ has a Hindley-Milner type system? I think it's just the "Just the machine integers wearing funny hats†" types from C which were passed on to C++
In K&R C this very spartan type system makes some sense, there's no resources, you're on a tiny Unix machine, you'd otherwise be grateful for an assembler. In C++ it does look kinda silly, like an SUV with a lawnmower engine. Or one of those very complicated looking board games which turns out to just be Snakes and Ladders with more steps.
But I don't think Safe C++ fixes that anyhow.
† Technically maybe the C pointer types are not just the integers wearing a funny hat. That's one of many unresolved soundness bugs in the language, hence ISO/IEC DTS 6010 (which will some day become a TR)
No, Safe C++ does not have that type system. I was just trying to emphasize the amount of, let's be honest, downright genius that had to go into that lifetime specification and borrow checker implementation.
For C++, it'll be about cramming lifetimes into diamond-inheritance OOP, which... feels even harder.
Safe C sounds like a much, much more believable project, if such a proposal were to exist.
> Why not just use the Chrome render engine directly from Rust?
This is what projects like Tauri (in Rust) and Wails (in Go) are doing[0][1]. Utilizing Webview to develop applications, but they still don't support mobile, Tauri mobile is in beta.
Basically Tauri and Wails are on one side (HTML/CSS) trying to approach cross platform by supporting mobile platforms, while Flutter and Kotlin Compose Multiplatform started from the other side.
So it depends on your needs, web-first or mobile-first, and what platforms matter to you. So far Flutter is in the lead offering the most polished experience when it comes to supporting all platforms (Web, desktop, iOS, Android).
They used to be based on Skia but now they have their own renderer (Impeller). That said rendering is only a small part of a UI toolkit, there's a ton of other stuff e.g. how to interact with system libraries, integrate with UI paradigms (e.g. tray icons, gestures, responsiveness, widgets).
There's too much infrastructure on top of the render engine to replicate. Flutter is backed by Google and has a fairly large ecosystem of community packages.
See Freya - which uses Skia - the render engine Flutter used until a while back.
Github is empty, only forked projects and courses.
This is like? Want me to build your house: I've taken a masonry course online.
Show me at least 4 walls that you've built and if your specialty is walls and these are your demo walls they better be state of the art, all best practices, explain why you used which technique for which wall.
Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production.
I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling.
Enums I honestly never used in Go also not the not-type-safe ones.
But I'm also someone who used interfaces in Go maybe I think 4 times only in years and years of development.
I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed either whether you think it could have provided any benefit when used appropriately.
For example, and option type with enums combined can ensure return values are checked by providing a compile time error if a case is missing (as expressed in the first few examples of the readme).
I know it can, the compiler can do one more "automatic" unit test based on the type checking system.
But they decided not to add enums because it conflicted and overlapped too much with interfaces.
I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go.
I personally agree with the Go team on how they argue and for me it would be a step back if they listened to the herd that does not take all sides of the story into consideration but just keeps pushing enums.
Try/catch is just a really bad thing all "hacky solution" alarm bells go off for me if you want to change error handling to giant try/catch blocks.
> But they decided not to add enums because it conflicted and overlapped too much with interfaces.
I'm very curious now about how it might conflict and/or overlap with interfaces.
To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as:
type DayNames enum {
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
}
...
func isFunDay (dow DayNames) {
// This must fail to compile, because there is an unhandled enumeration
switch {
case Sunday: ...
case Monday: ...
case Tuesday: ...
case Thursday: ...
case Friday: ...
case Saturday: ...
}
...
}
...
isFunDay (0) // Compile failure
var x int
isFunDay (x) // Compile failure
And I don't see how that conflicts or overlaps with interfaces.
I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec.
I largely agree with your sentiment. Go’s simplicity is what makes it such a useful tool for me. It’s worth protecting, and that means setting a very high bar for proposals that add new things to the language.
However, 2 things I would be enthusiastic about if it got included in the language:
- having ‘?’ As syntactic sugar for ‘if(err != nil) …’. Would make code more easily readable, and I think that is a benefit for programmers trying to keep things simple.
- Sum Types. I’ve had a few cases where this would’ve been very useful. I consider the ‘var state customtype = iota’ a bit too easy to make mistakes with (eg exhaustive checking of options).
Like generics, I hope that when that happens, they take a very deliberate approach on doing it.
I actually really have a disrespect for them. I'm in a constant fight against developers that want to translate code in almost the same code but "only using language features from the Advanced book".
I also wanted to add that I used inheritance only ONCE in all my years of writing Python in all other millions of lines of code inheritance was not the best solution.
This is my daily struggle as a CTO. People using waaayy too many "fancy" features of languages making it totally unreadable and unmaintainable.
It's their ego they want to show off how many complex language features they know. And it's ruining my codebases.
This is a nice humblebrag. Why does it matter that you are a CTO for this comment? It doesn't. It would better written as: "This is my daily struggle with my team."
It's one thing to want your devs to produce readable code -- as a former CTO I also spent significant effort in teaching people that -- but it's completely another to be a curmudgeon and directly disregard valuable programming tools like the sum types.
Not sure why you are conflating both. Also inheritance was known to be the wrong tool for the job at least 15 years ago, maybe even 20. Back then people wrote Java books that said "prefer composition over inheritance" so your analogy didn't really land.
Everyone who uses sum types in production code agrees they reduce bugs.
reply