Announcement

Collapse
No announcement yet.

Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • sinepgib
    replied
    Originally posted by Sergey Podobry View Post
    No, it's pure market from the lowest to top level positions. Now we're short of software developers (and especially good ones) that's why their salaries are high. If (or when) there will be more developers than available jobs the salaries go down.
    Or we realize we don't need as many developers. The financial bubble is bursting, and IT will be one of the most affected areas because it's one of the most overly pumped up ones. We're already seeing that with hiring freezes and mass layoffs from the bigger companies, everything else that doesn't have a clear use will follow. That's the all time compromise between "boring" lower paying but stable jobs in the real economy vs "edgy" high paying ambitious jobs with potential of making you very rich, those also have the potential of not delivering on the high ambitions and leaving you on the street. On recession, most companies take a conservative approach and stop going for the bold-but-not-yet-profitable ventures, which are a big part of IT right now. Salaries will go down soon, even before the market gets flooded by new programmers.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by cynic View Post
    10ms probably was a typo (it was supposed to be 100ms).
    I made the claim, it was not a typo: https://go.dev/blog/ismmkeynote
    The math is completely unforgiving on this.

    A 99%ile isolated GC latency service level objective (SLO), such as 99% of the time a GC cycle takes < 10ms, just simply doesn’t scale. What matters is latency during an entire session or through the course of using an app many times in a day. Assume a session that browses several web pages ends up making 100 server requests during a session or it makes 20 requests and you have 5 sessions packed up during the day. In that situation only 37% of users will have a consistent sub 10ms experience across the entire session.

    If you want 99% of those users to have a sub 10ms experience, as we are suggesting, the math says you really need to target 4 9s or the 99.99%ile.

    So it’s 2014 and Jeff Dean had just come out with his paper called ‘The Tail at Scale’ which this digs into this further. It was being widely read around Google since it had serious ramifications for Google going forward and trying to scale at Google scale.

    We call this problem the tyranny of the 9s.
    Originally posted by cynic View Post
    Secondly, I've been fighting with the Java GC for the last 20 years, so I think I know a thing or two on the matter.
    But don't worry: I'm not going to waste your precious time on this, since all that you wrote was arrogant insults with 0 technical content.

    Have a nice day.
    The quarrel I've seen with some Java programmers is that they see as "bad" a GC without many knobs and that sacrifices throughput so hard for latency.
    In reality it's just a matter of use case. Real time requires low latency, period, that's the top priority. Go is focused on soft real time nowadays.
    Besides, knobs don't usually scale, you need someone with a real deep understanding of how GC does its job to tune them correctly, which doesn't abound, and they often don't really translate when you switch computers. Keeping it simple in the end forces reasonable defaults on you, at the expense of flexibility.

    Leave a comment:


  • c117152
    replied
    Originally posted by arQon View Post
    * Even a mediocre C/C++ dev can become proficient with Rust in a few weeks at most...
    First off, don't put c and c++ in the same boat. C is easier than python. It just takes a lot of math background and formal education in algorithms and data structures to get comfortable with manual memory management. And this is backed by Intel's own stats on how long it takes them to bring their fresh recruits to a proficient level when (cherry) picked off uni.

    Having said that, consider the following:

    1. Even a mediocre English literate can become proficient in *phonetically consistent language script* in a few weeks at most. How many *years* do you think it takes a *phonetically consistent language* literate to become equally capable going in the other direction?

    2. Even a mediocre hanzi literate can be come proficient in latin script in a few weeks at most. How many *years* do you think it takes a latin script literate to become equally capable going in the other direction?

    That is, there's plenty of examples of really shitty languages that dominate not because of their merits or even despite of their faults, but actually BECAUSE of their faults. That is, when you raise the barrier of entry to compiler developers and make it hard for devs to simply throw away 5+ years of their professional careers when making future product choices, not only does having a shitty broken language isn't a problem, it's the very feature that lets you vendor lock.

    Leave a comment:


  • Sergey Podobry
    replied
    Originally posted by arQon View Post
    Okay - in that case, this idea that "Salary depends on supply and demand in the market" is actually fairly wrong.
    No, it's pure market from the lowest to top level positions. Now we're short of software developers (and especially good ones) that's why their salaries are high. If (or when) there will be more developers than available jobs the salaries go down.

    So if there are 5 Rust jobs and 100 suitable candidates you (as a Rust developer) are in a bad situation. Rust may be a super cool language. But the industry is not ready for it.

    Leave a comment:


  • cynic
    replied
    Originally posted by arQon View Post

    That comment is so hopelessly wrong that it took me several minutes to even understand what (I *think*) you were actually trying to say, but even if so it's still wrong, just in a more normal way.
    It doesn't help that you changed the context from what I was actually replying to, so maybe reading the post would have helped.

    > Of course there might be extreme load situation where it is not sufficient, but your question is wrong anyway.

    Two quick points: first, you mean you don't have the experience to understand the question; and second, it was rather obviously rhetorical.

    Yes, "load" - not "extreme load" or other attempts to hedge - is one of the reasons why "10ms" obviously isn't, and can't be, guaranteed, or even close to it.

    Anyway: I'm going to interpret your statement as attempting to say that what you think is that "When Go runs GC, it tries to do so in slices of not more than 10ms", right? If so, there may be some point in continuing with this. If that wasn't it then lets get out of here before wasting any more time on this.
    Man, firstable stay cool.

    10ms probably was a typo (it was supposed to be 100ms).

    Secondly, I've been fighting with the Java GC for the last 20 years, so I think I know a thing or two on the matter.
    But don't worry: I'm not going to waste your precious time on this, since all that you wrote was arrogant insults with 0 technical content.

    Have a nice day.

    Leave a comment:


  • arQon
    replied
    Originally posted by Sergey Podobry View Post
    Oh, it seems the correct term is "supply and demand".
    Okay - in that case, this idea that "Salary depends on supply and demand in the market" is actually fairly wrong. (Sorry: there are going to be some terms in this that are likely to be awkward for you as a non-native speaker. I'll try to keep them to a minimum).

    The "supply and demand" principle is sort-of mostly true for simple commodities - food, for example - and it's pretty much where we, as children, get our first piece of understanding about economics. It becomes a lot less true as the *fungibility* of the commodity declines. To try and put that more concretely:

    Say you have a bushel of wheat. That wheat is fundamentally *completely interchangeable* with any other bushel of wheat. Likewise for a pound of gold, or a gallon of oil, etc etc. You can get it from place A, or place B on the other side of the world, and for all practical purposes it doesn't matter at all: at the end of the day, it's all wheat.

    Not all commodities work like that though. A bottle of this year's wine from Chile, aged in a plastic drum for 10 days, costs $3. A bottle of wine from Chateau Pretentious 1949 though might cost $50,000 (even though it will almost certainly be even less drinkable).

    People, depending on their role etc, can also span a similar spectrum. Staffing a McJob is very much like the wheat case: the company cares very little about *who* fills that job, only that they have *somebody* to do the work. The same mentality is what drives Amazon to consider its warehouse staff etc to be utterly disposable, and so on.
    Now take a look at what Amazon pays its VPs, whose "work" is arguably just as mentally demanding, and infinitely less so physically. (Or, if you prefer, a politician - a job which can be done by someone who didn't even manage to graduate high school).

    The "supply" of people capable of being an Amazon VP is nearly infinite. The demand for people to fill that job is extremely small. By your reasoning, there's an argument it should pay less than being a warehouse worker.
    Take a look at nursing in almost every country in the world: the demand is enormous, the supply is tiny, and yet nursing salaries are nearly always terrible.

    Say a consultant gets paid $200K for six months work to turn a failing project around. It ships on time, and generates $1B in revenue in its first year. Was the consultant overpaid, underpaid, both, or neither? How about if the company had hired 5 entry-level developers instead, none of whom had the specific knowledge that saved the project?

    Developers are not bushels of wheat, and aren't thought of as such by even the lowest-tier outsourcers etc. (Despite how often they're *treated* as if they were once they're in a job). It's only at the very lowest levels of development that you can think of them as being fungible. The "supply" isn't "people as raw body count", it's "people who can get *this job* done".

    How that relates to the "my language is better than yours" garbage earlier in this thread is... well, I can't answer that, because there wasn't anything like enough relevant information in that post, unsurprisingly. But, for example:
    * If you're hiring for a Rust project, it's pretty much guaranteed that the project is new, comparatively small, and comparatively simple. You're also hiring for a language that nobody has much experience with. All of those are good reasons to, as a hiring manager, be a *lot* more willing to take on junior staff for it and train them up.
    * Rust is "safe", so why pay for the sort of expertise required to get a C/C++ developer whose code isn't going to bring down production because they missed a race or overwrote 30MB of already-freed memory?
    * Rust is the current fad, so I can probably get good developers at a discount.
    * Even a mediocre C/C++ dev can become proficient with Rust in a few weeks at most. How many *years* do you think it takes a Java/Go/Rust/web developer to become equally capable going in the other direction?

    And that's just off the top of my head. In short, things are a lot more complicated than a one sentence basic principle from 6th grade; and certainly far more complicated than a random list of languages with just a single number next to them that was pulled from thin air with no context.

    Some advice for you that will have value for your entire life: any time someone tries to offer you a massively-simplified "answer" to a complex question, you should be very wary of it. There are only two possible reasons for them doing so: either they don't understand it in the first place, or they are trying to deceive you. Either way, it would be a mistake to trust them. gl.

    Leave a comment:


  • MartinN
    replied
    Originally posted by kpedersen View Post
    Carbon is a close superset of C++. This might actually have a chance of succeeding C++.

    It is basically Rust with a C and C++ compiler bolted on. No need for creating / maintaining bindings or marshalling data via the FFI.
    Question-why develop a brand new language? Why not solve FFI between Rust and C++ at the ABI level plus any mods/extensions to Rust's syntaxes that will enable easier migration away from C++? GOOG would be in a unique position to tackle this via the ABI.

    I would love to hear a technical explanation of why Rust-C++ FFI can't be solved at the ABI level almost entirely, if not entirely...

    Leave a comment:


  • neoe
    replied
    Originally posted by coder View Post
    You don't like Rust because of Firefox? Explain how its obsolescence or whatever else you don't like about it is the fault of the language.
    It means 'If Firefox becomes not that awesome, Rust can gone without my needs'.
    BTW, I don't like Rust because it's verbose in grammar and concept, which seems to me is 'much pay less gain', making my programing experience crippled which is not acceptable, especially when I use the language not for job but for self innovation.

    Leave a comment:


  • coder
    replied
    Originally posted by Sergey Podobry View Post
    For non-atomic operations writing to a cacheline is completely asynchronous. That's why they are fast.
    But writing to a cacheline manages to ensure exclusivity without having to lock the CPU bus. And it also signals all CPUs in the system. Two things you indicated made atomics so bad.

    There's something else we're glossing over, which are solutions like Intel's HLE. Granted, they withdrew it for security reasons, but it's a way to implement atomics without blocking the core, in the typical case. ARM also added atomic instructions to ARMv8.1, which can also potentially run without blocking.

    I'm not arguing that atomics can't be costly, but it has to be seen it in terms of both how you use them and relative to the cost of memory allocation or garbage collection. If they're used judiciously, their overhead is typically a non-issue. Furthermore, the factors which make atomics more expensive will tend to cause you pain, even if you aren't using them.

    Leave a comment:


  • MartinN
    replied
    Originally posted by phoronix View Post
    Phoronix: Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

    In addition to Dart, Golang, and being involved with other programming language initiatives over the years, their latest effort that was made public on Tuesday is Carbon. The Carbon programming language hopes to be the gradual successor to C++ and makes for an easy transition path moving forward...

    https://www.phoronix.com/scan.php?pa...ccessor-To-CPP
    I chalked off developing Fuchsia instead of using something like Genode/seL4 as their Linux successor on Android devices as a better/more optimal technical approach than what Genode/seL4 could provide...rather than pure hubris/NIH syndrome/desire for control and greed...

    Now I realize my assessment of Google was off-they have become legends in their own mind who would rather reinvent the wheel than contribute resources to develop/tweak Rust further to their needs as well the community's...

    I am quite confident there's a perfectly valid reason in some executive at Google's mind for throwing resources at Carbon.... and heck, given Google's size, this may in fact outlast similar efforts by Shuttleworth to sustain Mir...which ironically, is now resting in Mir (peace), after Mark realized FOSS doesn't care about what he thinks.....

    So, I hope this is merely a pulse/temp check of the dev community by Google....and that Carbon rather quickly fossilizes into petrified sh..I mean, carbon.. Google is healed from NIH and focuses on making Rust a premier player, a first class citizen at Google, on their ChromeOS, Android and Fuchsia platforms rather than reinvent Rust badly.

    Of course, Carbon may very well be the next great thing since sliced bread...so I apologize in advance for my brainfart, if that's the case.

    G'day Bruce.
    Last edited by MartinN; 27 July 2022, 03:45 AM.

    Leave a comment:

Working...
X