701–710 of 869 posts
Earlier quoted context omitted.
I wonder how the Cobol market is doing?
The funny part about cobol is that even if you say you know the syntax, there is site specific implementation details/features which are even MORE critical than just the language.
Earlier quoted context omitted.
Perhaps. I note that position is being advertised by Oxford Knight, a high-touch recruitment firm. Their main modus operandi is to make contact with someone looking for a job, find out what they are looking for, and then suggest particular openings on their books to them; they would have plenty of opportunity to explain about the compensation. I think these public job listings are a bit of a cheap additional thing, a…
As a C++ developer hoping to move back to London, this side of the market is still very opaque.
For example: https://www.linkedin.com/posts/rahnpreet-sandhu-2b84a515a_co...
Earlier quoted context omitted.
The C# standard library is more consistent and powerful (batteries included, more modern). That means there is a "standard, correct" way to do most things in C# in a multi-platform way. C/C++ has massive variety here. Memory management is trivial in C#. So yeah, C# is easier to learn. Perhaps you're super smart?
I'm curious, how did you hear standard library when I said type system?
> But more to the point, people claim it's somehow harder in C++ to learn programming so either I'm super smart or they're wrong.
TBH I consider the type systems of most imperative languages to be extremely similar. The only difference worth discussing is enumerators which can hold data. C++ doesn't have these, not sure if C# has them now. Rust has them.
I'll create a new comment under yours for a more specific discussion.
Earlier quoted context omitted.
I'm really surprised at how stable and widely supported Rust's FFI is. I have several C++ projects that integrate a portion written in Rust, where the Rust project produces a .a file that is ultimately linked with clang into a larger C++ project. I definitely agree Rust has a long road to adoption in embedded/low level systems, and particularly areas with custom compilers/toolchains that rely heavily on system specif…
I agree. But I think it'll be hard to see Rust really make progress until hardware makers worldwide start really doing 'Rust First'. And the problem there, is that Rust is a bit inaccessible to many. Rust trades of absolutely everything for performance - and that's just not the trade-off we want to make in most scenarios. Even for most embedded systems - something that's easy to program, easy to read, easy to support…
Long way to go, of course.
Earlier quoted context omitted.
> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++ 1. because it is greppable and unsafe 2. because there is also static_cast and dynamic_cast 3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast. All in all, it is nice to ask, but if you do not know what you are talking about e…
Seems to be found by grep fine: % echo 'int x = (int)1.2f;' > foo % grep '(int)' foo int x = (int)1.2f; Does greppable mean something else in this context?
Earlier quoted context omitted.
Java and Python's notions of type safety are completely brain damaged. I can't imagine how things would have gone if I'd learnt them as first languages. Rust, C and C++ get that better, in my opinion (you have to consciously choose to write type safe code in two of those languages, but at least it is possible in all three). Go's thread safety is way behind Rust's. meh.
I would argue C++ type system is superior to even C# and I'm a huge fan of C#. But more to the point, people claim it's somehow harder in C++ to learn programming so either I'm super smart or they're wrong.
I can think of a few but they seem like compiler sugar only. For instance C# classes are treated as a &ClassName or std::shared (handled by reference transparently to the programmer).
Otherwise I think that C, C++, C# have very very similar type systems. They don't have alternatives to dynamic dispatch (virtual / override) like enums with value (a Rust feature). They don't have ways to add functionality to existing 3rd party classes. C# Interfaces are basically simple C++ classes with every function marked virtual.
C# feels far more dynamic with reflection and whatnot but you say type system, which is a different thing. LINQ again stacks well with C# and makes it more expressive, but doesn't change the type system.
I'd argue that '99 C++ is very similar to C in the type system, with a little sugar around classes having an implied *this and vtable mangement around virtual. Otherwise you can impl something like C++ classes using C structs.
Are you talking about C++ template programming and meta-programming? Because I personally view that as an advanced preprocessor / precompiler step that outputs large amounts of simpler C++ code without templates and doesn't change the "type system" a great deal.
Perhaps you are referring to some very modern C++ features I haven't used yet? Most likely they only brought C++ back in line with a subset of Rust / C# features.
Earlier quoted context omitted.
At a previous company our firmware was literally called by a part number. So I would regularly work on the repos 5400-520, 5400-521, 5400-524, 5400-526, etc.
Assigning a part number to firmware is perfectly normal. It's part of the Bill of Materials for the product. What is not normal is referring to that part number anywhere except on the BoM.
I made the switch to Rust and Go and the concern was never raised.
Farewell C++.
Earlier quoted context omitted.
Why not rust?
Try doing (serious) high frequency trading in rust, then come back to me.
Are you working at a more "serious" company where they only use languages with the safety level of Assembly?
Earlier quoted context omitted.
7. Fundimental underpinnings - Every other language is written essentially in C - you can often understand how their features WORK if you know C extremely well. ... I'd argue that 1,2 are covered by rust. 3 and 6 by unsafe rust. Once you have that, a transition to pure C for the full 7 makes sense, and would be trivial for a rust dev.
I'm fairly proficient in Rust and I think it has its own strengths for learning, but its own downsides too. Pros: 1. Way easier to get "live" help, I've found the barrier to ask for Rust help is lower than any other language I've ever used (and I've used a lot) 2. Way easier tooling like cargo, error messages are far better, especially with regards to generics vs templates 3. Some things are more explicit in Rust. Li…
Con (1) (Existing examples / training) is a legacy language strength in general, C++ is going to lead in this for a long time.
Con (2) (Low level data structures) I 100% agree. A toy example of a datastructure in C++ is going to be really easy to express but also dangerous to use.
I think you'd really enjoy this chapter of the Rust Docs on making your own Vec https://doc.rust-lang.org/nomicon/vec/vec.html
And you are correct (Con 2 again), it IS an advanced practice. The result of making a data-stucture the rust way is a bulletproof class anyone can use, rather than a C++ foot-gun so it's worth the effort (but less so for learning).
You might find you can make your whole module unsafe and write a very similar data-structure in rust to your C++ solution (pointers and all) and it would compile and run fine.