7 ms·

I might actually be more excited about Val as a C++ successor than I am about Herb Sutter's excellent CppFront... Admittedly, all I know about it is from the t

• pjmlp 3y ago
  Listen to the last two episodes of ADSP Podcast with Sean Parent, regarding Val. Adobe Research labs is seriously sponsoring its development. https://adspthepodcast.com/ https://adspthepodcast.com/
• marcodiego 3y ago
  > Statically compiled. Statically typed. Interops with C++. Memory safe. Typesafe. Data-race-free. So it is for C++ what rust is for C?
  • tialaramex 3y ago
    Val has a similar but different strategy to the big problem as Rust. In Rust the reference semantics are lifetime checked (hence all the talk about a "borrow checker") but in Val there are no reference semantics. In Rust there are some things you can't (safely) do because the checker can't see why they're ok. Val guesses that, with appropriate language features in place, you can extend that to everything and still have a useful language but now you don't need to teach this complicated and difficult feature. Because Val is young it's not yet obvious whether this is basically always better, or whether it's too limited.
    • _a_a_a_ 3y ago
      The a typing feature[1] in the language Eiffel was based on the assumption of the author that the typing holes it apparently introduced could be statically detected. It turned out he was wrong after the language was released IIRC. I guess you have to be pretty certain of something before basing a language around it. On top of that being a generally shite language doomed Eiffel. [1] IIRC again, you could cancel features in subtypes, so "all birds can fly" but "penguins are birds but can't fly". That would break the Liskov Substitution Principle, which Bertrand Meyer thought he could deal with but apparently couldn't.
      • pjmlp 3y ago
        May many languages be as successful as Eiffel is. Eiffel Software is still in business, whereas many others hardly reach any audience.
        • Tozen 3y ago
          Very true. So many languages people haven't heard of. It's like if not in the top 10 or 20, some think they don't matter. In regards to Eiffel, always felt that hindrance to wider adoption was more about the licensing. Still, they are in business and in use.
        • mardifoufs 3y ago
          I know it is used in education in some parts of Europe. But now I'm wondering, is it used in production? Or rather, does it have a niche or an industry where it is more widely used? I'd be curious to know what software is written in Eiffel! (Mainly to get an idea of what Eiffel source code looks like, beyond toy examples)
  • KingLancelot 3y ago
    [dead]
  • sharts 3y ago
    I thought it was that Go is to C what Rust is to C++? This seems like another animal altogether.
    • jacquesm 3y ago
      Rust is very much aimed at the same space of Go where Go can be used to replace C. I'd argue Rust is more aimed at the C space than the C++ space because of its accent on systems programming.
• zem 3y ago
  c++ interop always seems like some sort of magic power, given how few languages achieve it.
  • speed_spread 3y ago
    To be fair, I don't think even C++ is very good at C++ interop.
  • Scarbutt 3y ago
    What language has C++ interop?
    • nicwilson 3y ago
      D does. Not source compatible, but mangling and ABI for linking. And D can generate headers for `extern(C++)` declarations defined in D
    • zem 3y ago
      i've come across carbon (google's c++-next language), clasp (common lisp with an llvm backend), felix (compiler generates c++), and maybe a couple of others i'm forgetting. also some languages have packages that deal with c++ interop to varying extents - see this discussion: https://www.reddit.com/r/ProgrammingLanguages/comments/huhy8i/is_there_a_programming_language_that_can_use_c/ https://www.reddit.com/r/ProgrammingLanguages/comments/huhy8...
    • elcritch 3y ago
      Nim does as well. You can use the C++ backend and wrap a decent bit of C++. The imports aren’t automatic so you need to define the FFI, but you can call templates, implement virtual methods, call constructors, etc. NimForUE takes advantage of this: https://youtu.be/Cdr4-cOsAWA https://youtu.be/Cdr4-cOsAWA
    • macshome 3y ago
      Swift just added C++ interop in version 5.9. https://forums.swift.org/t/c-interoperability-in-swift-5-9/65369 https://forums.swift.org/t/c-interoperability-in-swift-5-9/6...
• Buttons840 3y ago
  Sounds like we're trusting a lot to the compiler. Will this lead to me making a small change which breaks an optimization in some distant code and ruins performance?
  • swsieber 3y ago
    I believe rust is sort of similar in that apart from the references, it's very heavy on the move semantics. And IIRC, sometimes it's doing extra memcpys. But I don't know if Rust is explicitly targeting const reference passing. That said, if you're all in on it I imagine that the front-end could pretty aggressively target that, much like how rust uses no alias.
    • saghm 3y ago
      By default, non-references in Rust are passed by move, although you can derive `Clone` on types composed of all `Clone` types and then explicitly call the `.clone()` method to copy things. The only types that will be copied by default are the ones that implement `Copy` in addition to `Clone`, which in the standard library is on primitives like integers and characters but overall is used fairly sparingly. References need to be specified as mutable if mutation is needed (i.e. `&mut T` instead of just `&T`). Using immutable references is also encouraged from the borrow checking rules; having a second reference (either mutable or immutable) alive at the same time as a mutable one is a compiler error, but using multiple immutable references at the same time is fine. (Pointers are the same way, but not really used much outside of bridging with unsafe Rust, since they can be null and therefore can't be dereferenced outside of `unsafe` blocks).
      • SkiFire13 3y ago
        I think OP was referring to the fact that implementation of moves can sometime (more often than desired I would add) do memcpys. e.g. if you have a struct of ~100 bytes and you move it, it will probably emit a memcpy to write it in the receiving function's stack. AFAIK this happens because addresses are kinda considered observable, and not doing these copies could thus be observable and potentially break some weird code. I don't think Val would have the exact same problem because it doesn't have the concept of addresses/pointers.
• moonchrome 3y ago
  does this mean your object tree is acyclic since you can't have references ?
  • Buttons840 3y ago
    Val will have statement level unsafe annotations (not even full unsafe blocks), according to the podcast linked in a nearby comment. Linked lists will be tricky or impossible to do safely, like in Rust.
    • stouset 3y ago
      I’ll have to see about this, but I don’t really like that. Yes, you can replace a block of unsafe calls with a bunch of individually unsafe-annotated lines. But a good model of unsafe to follow is that whatever unsafety you expose within a block should be brought back within safety requirements when you exit the block. Put differently, an unsafe block should act as unit-safe and not leak unsafety. If all you get is statement-level unsafety, you have no way to indicate at what point you’ve re-upheld safety guarantees.
• humanrebar 3y ago
  > ...interops with C++... Does it? With what qualifications? Requires C++ that uses clang modules or something?
  • Conscat 3y ago
    What are you quoting? EDIT: I assume you meant to copy "ìnterops with C++". The answer is that it basically doesn't right now, but they intend for it to in the future somehow. https://accu.org/journals/overload/30/172/teodorescu/ https://accu.org/journals/overload/30/172/teodorescu/
    • humanrebar 3y ago
      Sorry, yeah. Autocorrect. I fixed it. And if that's a goal, fine, but if there isn't interop yet, we should be hesitant to describe Val as having C++ interop. Especially since C++ interop probably requires some compromises, such as requiring modular C++ in some form.
• yeputons 3y ago
  > You just pass by value, return by value everywhere, all day long. I cannot efficiently mutate or even store references in structs anymore. That seems to be a show-stopper if you want to have any non-trivial or non-standard data structures in the program. Granted, they are hard to get right, so maybe it's a feature.
  • cvoss 3y ago
    It seems you would have to use the `unsafe` escape hatch for data structures such as linked lists, and externally verify that the implementation is correct. Which is better than the status quo of C++ where you are always in needed of externally verifying safety. As for the safety mechanisms discouraging non-standard data structures, the language designers probably would consider that a feature, rather than a bug. I am curious whether the use of a broken unsafe construct can break the safety guarantees of safe constructs, or if the unsafety is contained no matter what.
    • bobbylarrybobby 3y ago
      https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
  • adastra22 3y ago
    I just learned about Val today, but Rust has similar constraints. To write to a particular variable requires having ownership or a mutable reference, which only one part of the program can have at once. Since you can't have two mutable references in different parts of the program or in different threads, you need some sort of atomic encapsulating data structure to mediate access. Something like a mutex. Newbies to Rust have a lot of trouble learning how to get the borrow-checker to accept their code, but what these restrictions are doing is syntactically ensuring there are no deadlocks or data races. It is presumably a similar story with Val. If Val actually handles this differently, I'd love to know.
    • bobbylarrybobby 3y ago
• winrid 3y ago
  In a lot of cases won't the C++ compiler just inline methods and remove the copies anyway...?
  • fractalb 3y ago
    Inlining functions and copy elision are two different things. If you inline a function without copying it's args, then it'll change the value of the original argument: Copy semantics lost!
    • winrid 3y ago
      Right. I wonder if copy elision can be ignored if functionality is verified to be the same? I'm just a hobbiest c++ dev so sorry for ignorance :)
• TOGoS 3y ago
  > You just pass by value, return by value everywhere, all day long This is actually how I've been writing PHP programs for years, passing arrays around like I just don't care.[3] I think the PHP interpreter is smart enough to actually only copy-on-write, but I admit I've never profiled these programs. But anecdotally, I've done some pretty complex stuff[1] this way and it never caused noticeable performance problems. [1] Complex as in 'wow I sure am making the computer process a lot of data, parse some DSL character-by-character, dynamically generate SQL and massage the results into some arbitrary structure for EACH PAGE LOAD, geez'. Not as in 'print hello world, but using Laravel', which somehow manages to be about 30x as computationally expensive[2]. [2] quip about how 'web artisans' spend the time between page loads brewing coffee using their CPU as a heating source while thinking deep thoughts. But I digress. [3] Back in the PHP 4 days, objects, too, acted as if stored in variables rather than just pointed-to by them. Not that anyone expected language design excellence from Rasmus et al, but strikes me as a missed opportunity when they changed object variables to having reference semantics to have 'value, variable reference, or pointer-to-value' be a property of variables orthogonal to the type of value they store/reference. e.g. $a = $b; // Copy $b's value into $a $a = &$b; // $a and $b are now the same variable $a = *$b; // $a points to the same object as $b, but unlike $a = &$b, the variables themselves are not linked
• matheusmoreira 3y ago
  > Interops with C++ Doubt. I simply don't believe any other language out there is capable of interoperating with C++. Even C++ compilers have broken binary compatibility, different versions of the same compiler even.
  • freilanzer 3y ago
    Clasp might be such a language, it seems. https://github.com/clasp-developers/clasp https://github.com/clasp-developers/clasp
• synergy20 3y ago
  cross platform build tools similar to cargo or go build are important to me. battery included stdlib that also has network and gui is super attractive too