[HN Gopher] Val, a high-level systems programming language
___________________________________________________________________
Val, a high-level systems programming language
Author : cpeterso
Score : 142 points
Date : 2023-07-18 20:22 UTC (2 hours ago)
(HTM) web link (www.val-lang.dev)
(TXT) w3m dump (www.val-lang.dev)
| bsaul wrote:
| How come this page reaches top of HN ? Has anything new happened
| to this language ?
|
| I was hoping there was because i liked the idea when it was
| announced a year ago, but the page doesn't seem to show anything
| new.
| dang wrote:
| It's like the second-hand clothing store in my town that used
| to be called "New to you".
| Narishma wrote:
| So now we have V, Val, Vala, Vale. Any other language I'm
| forgetting?
| hardwaregeek wrote:
| I legitimately thought this was Vale. Rather unfortunate
| collision in naming
| germandiago wrote:
| They are trying to concentrate safe systems programming in
| permutations of V +{a,l,e}
| TiredGuy wrote:
| and you can code with them inside vi or vim!
| bibanez wrote:
| Valtown
| Buttons840 wrote:
| It will work to their advantage. Anyone learning one of these
| language is looking for "the new hotness", and will probably
| become aware of the other similarly named languages in the
| process, and will thus look them up. JavaScript did it, how did
| that turn out for them?
| coldtea wrote:
| Javascript was the only game in town in the browser for
| cross-browser support.
|
| The name didn't matter at all, it could have been named
| Fooscript and still be popular.
| porcoda wrote:
| There's also VAL, one of the 80s era languages that influenced
| Haskell (via SISAL). Alas, outside the parallel languages
| community I don't think many people are familiar with that VAL.
| xwowsersx wrote:
| Variable Assembly Language!
| kubota wrote:
| Part of me loves the advent of so many zero-cost-abstraction
| languages. The other part wishes the systems programmers would
| pick a winner already so that the already small community of
| systems programmers do not end up multifurcated into even smaller
| communities of Rust, Zig, Val, etc developers. I hope the systems
| language wars end soon in other words.
| eska wrote:
| Maybe we picked one too early and didn't have enough innovation
| in this area for too long. Bring the war :)
| djbusby wrote:
| Not even a war, right tools for the job. I don't think it's
| possible for one language to rule them all. Options are good.
| chrisco255 wrote:
| Won't happen. But all the more reason to expand wasm + wasi
| support everywhere.
| jjtheblunt wrote:
| Are those languages able to do low-level hardware things?
| tracker1 wrote:
| Not really, unless some future hardware supports such a
| beast, could be an interesting approach for AI/WebGPU
| interfaces.
|
| It's more for service-oriented applications currently...
| you pass stuff in, get stuff out.
| [deleted]
| VWWHFSfQ wrote:
| I think at this point Rust is the winner just because it's
| already overcome the incredible hurdles of being shipped in the
| Linux and Windows kernels themselves. In that regard, I doubt
| there's room for any more of these new systems languages now.
| bsaul wrote:
| I have the intuition that rust can't possibly be the winner,
| it really feels too crude regarding the way it manages
| lifetimes. It really feels like the clumsy grandparent of the
| language that will indeed solve those problems elegantly.
| lolinder wrote:
| But we made do with C for how many years? OP's question
| isn't whether Rust is as good as systems languages will
| get, the question is whether any successor language stands
| a chance of being included in the kernels.
|
| The bad ergonomics of C were never enough to get another
| language into the Linux kernel, it took a language that
| solves the number one class of security bugs. It's unclear
| that any successor to Rust will be able to show as clear a
| need.
| xwowsersx wrote:
| That's not how I read OP's question. OP was wondering
| whether a lang besides Rust can be "the winner"
| (unqualified) given that Rust has already past the hurdle
| of of being included in the kernel. It didn't sound like
| at all like their question was limited to whether there's
| room for another lang in the kernel.
| germandiago wrote:
| Same opinion here. Let us look at Val and Vale.
|
| There is also Carbon and CppFront but those are more of C++
| evolution than new-born things.
| nullc wrote:
| Can you really have a systems programming language where the
| runtime cost is not apparent from the code and stable?
|
| Having some code suddenly gain a gigantic copy in an inner loop
| because of a far away change seems like a risk in val.
| corysama wrote:
| 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 two presentations below. But,
| from what I can tell...
|
| Statically compiled. Statically typed. Interops with C++. Memory
| safe. Typesafe. Data-race-free.
|
| The elevator pitch I give when describing it goes like this:
| Imagine you were starting a new C++ project and didn't really
| care about performance (spoiler: perf comes back in the end). So,
| you decide to not bother using pointers or references anywhere.
| You just pass by value, return by value everywhere, all day long.
| If you ignored the obvious perf problems of passing around maps
| of vectors of objects by value, wouldn't it be nice? you don't
| have to worry about side effects or data races or anything. And
| yet, the data is not immutable. You can go ahead and mutate it
| all you want worry-free because the data is all completely local
| to your function.
|
| Well, turns out the Val folks have figured out that by
| eliminating pointers and references from the language, the can
| get the compiler to automatically pass-by-const-reference and
| return-value-optimization under the hood such that it preserves
| both the performance and the semantics that you want at the same
| time.
|
| Val: A Safe Language to Interoperate with C++ - Dimitri Racordon
| - CppCon 2022 https://www.youtube.com/watch?v=ws-Z8xKbP4w
|
| https://cppcast.com/val-and-mutable-value-semantics/
| Buttons840 wrote:
| 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 wrote:
| 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.
| bmacho wrote:
| Maybe we should tell the compiler somehow that we don't want
| to pass a value, but a reference. For example we could use a
| * or a & symbol.
| zem wrote:
| c++ interop always seems like some sort of magic power, given
| how few languages achieve it.
| moonchrome wrote:
| does this mean your object tree is acyclic since you can't have
| references ?
| pjmlp wrote:
| 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/
| marcodiego wrote:
| > Statically compiled. Statically typed. Interops with C++.
| Memory safe. Typesafe. Data-race-free.
|
| So it is for C++ what rust is for C?
| tialaramex wrote:
| 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.
| AnimalMuppet wrote:
| > Because Val is young it's not yet obvious whether this is
| basically always better, or whether it's too limited.
|
| This is sound wisdom. It's not always obvious at the
| beginning what the limitations are going to be, and what
| the opportunities are going to be. If it's a promising
| direction, pursue it, even though it won't always work out.
| _a_a_a_ wrote:
| 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.
| mr_00ff00 wrote:
| It's brought up every time, but the only thing I don't like about
| Val is that Vale and V are two other systems languages that are
| also new. Those three can so easily be mixed up because of
| naming.
| epage wrote:
| Had to go to the link to confirm whether this was the
| projection language or the region language.
| jgilias wrote:
| There's also Vala. A somewhat different niche, but one more
| similarly named language.
| hcarvalhoalves wrote:
| Do these terms ("subscript", "projection") have a deeper meaning
| - maybe from another discipline - or are these terms arbitrarily
| chosen to explain the abstractions of the language?
| samstave wrote:
| May you plz ELI5 'High-level' ?
|
| I'm just pointing out that there are several idioms,
| nomenclatures, slang, blah blah that when stated "high level" is
| condescending and making it that "i dont need to explain myself
| to you!!"
|
| But yet, you DO have to explain yourself
| [deleted]
| cloudmike wrote:
| My emotional journey with Val having just learned about it today:
|
| Oh neat, a new systems language, probably nothing but let's take
| a peek. Docs look legit. Hmm some thoughtful ideas in here around
| ownership. Syntax makes sense. But is it different enough to
| justify its own existence? Who makes it?
|
| Oooh, Dave Abrahams is working on it. We crossed paths at Apple
| and I remember his Crusty talk about Swift. It was great, loved
| the strong opinions, but Apple sadly removed it years later
| because it had some outdated advice. Wait, he's at Adobe now? So
| is this an Adobe language?
|
| Conclusion: keep an eye on it, will watch the linked talks, wait
| and see.
| zzo38computer wrote:
| Good:
|
| - It uses "0o" instead of "0" prefix for octal numbers.
|
| - Underscores to separate groups of digits in numeric literals.
|
| Not good:
|
| - It uses Unicode.
|
| - It does not have a "goto" command.
|
| - There are no macros.
|
| - Perhaps, the name is too similarly than the other programming
| language, maybe?
|
| This isn't everything that can be commented about it; I have not
| examined it completely yet.
| extasia wrote:
| I've never liked macros... What attracts you to that feature,
| I'm curious?
| andrewstuart wrote:
| Anyone got an opinion on Embedded C++, a C++ subset/dialect?
|
| https://en.wikipedia.org/wiki/Embedded_C%2B%2B
| gpderetta wrote:
| Ah yes, the languages that eschews namespaces and
| static,reinterpret_cast, major sources of issues on embedded
| platforms.
| cynicalsecurity wrote:
| _Sounds great, but why another language?_
| zamalek wrote:
| Really interesting concepts here, especially subscripts (which
| neatly solve an issue that RAAI semantics or lambdas are usually
| hacked into solving).
|
| Is my reading of overloads correct? Identically-named methods are
| supported, but only for different argument labels and/or calling
| conventions?
|
| Rust convinced me that dispatching based on argument types is a
| poor idea, because Vec::new(10) could only be understood by
| reading the documentation at least once - whereas
| Vec::with_capacity(10) is abundantly clear. Val seems to gain
| these benefits (assuming that it doesn't dispatch based on type)
| without the drawbacks.
| germandiago wrote:
| What about generic code?
| adamwk wrote:
| You're correct; Since argument labels are really part of the
| function name, you can say all function names must be unique
| sesm wrote:
| This part is exremely confusing: https://tour.val-
| lang.dev/bindings#lifetime Why a value declared with `let` has a
| lifetime? Is it because they want to avoid copying objects and
| data structures?
| dang wrote:
| Related. Others?
|
| _Val, a new programing language inspired by Swift and Rust_ -
| https://news.ycombinator.com/item?id=31788527 - June 2022 (19
| comments)
| xmonkee wrote:
| This is one of the better (and better looking) landing pages I
| have seen for a programming language. Very good copywriting too.
| andrewstuart wrote:
| edit: these comments are general, not directed at Val.
|
| A humble suggestion to anyone coming up with a new language.
|
| _Please_ make it as familiar as possible.
|
| For example, do you really need to come up with some new syntax
| for defining a function, or specifying types and returns?
|
| If you want people to use your new language, reduce the cognitive
| load - do things the same as other languages and be different
| only where you must.
|
| Every time you come up with some completely alien programming
| construct, you have set a barrier to learning. Coming up with a
| new language should, for the most part, be an exercise in copying
| the best of how other _extremely popular_ languages do things,
| and on top of that build in the necessary differences that make
| your language special.
|
| Also, less is more. For example, one of the reasons Rust is so
| complex and intimidating is it has six sublanguages
| https://gist.github.com/brendanzab/d41c3ae485d66c07178749eae...
| the expression language unsafe runtime language
| safe runtime language compile time language
| the type language the trait language the macro
| language the attribute language
|
| Whereas Zig goes the other direction and attempts to make
| everything programmable in the one core language, even ditching
| macros entirely. https://ziglang.org/learn/overview/. In Zig you
| can write compile time code in the same language and same code
| base.
|
| I put forward these suggestions not as a language edxpert - I am
| far from it - instead I put them forward as a frustrated learner
| wanting to do new things and looking at new languages and
| thinking "shit, I already work with three of four languages plus
| any number of subtechnologies on a given system, I just don't
| have time/headspace to learn a programming language with six sub
| languages".
| cobbal wrote:
| This syntax looks almost exactly like Swift, which is also
| where it borrows its semantics from.
| pkkm wrote:
| I disagree. Syntax is the thing everyone loves to comment on
| because of the bikeshed effect, but it's probably the quickest
| aspect of a new language to learn. If you're already creating a
| new language and have the opportunity to fix some things that
| make older languages harder to remember, parse, or type, why
| not take it?
| JonChesterfield wrote:
| Alternatively, where the semantics are different to existing
| languages, try to make the syntax different too. Languages
| which look the same as existing ones and behave differently are
| pretty rough going for newcomers and anyone programming in
| multiple languages.
| macintux wrote:
| One reason I prefer Erlang to Elixir is that I appreciate the
| fact that Erlang syntax is very different, and I feel like it
| helps me _think_ in Erlang. I don't think about Python or
| Ruby.
| andrewstuart wrote:
| I probably should have said "did you really need the syntax
| _and the behavior_ to be different? "
|
| My point is not so much about syntax, it is about
| _unnecessarily_ doing things in a conceptually different way.
|
| If different behavior at a given point is core to what makes
| your language special then sure thing, make it behave
| different, but implementing some different behavior without a
| significant payoff only makes your new language harder to
| grasp.
|
| Presumably you are making a language because you have some
| core concepts or beliefs you want to bring to life - all I'm
| saying is - make that happen, and make the rest as familiar
| as possible for most programmers.
| _a_a_a_ wrote:
| I never get this argument. The syntax is important for
| consistency, but in another sense is trivial. It's the smallest
| thing about a new language that you have to learn, I don't
| understand why people get hung up on it.
| stusmall wrote:
| I often find people get very hung up on it because they don't
| have much else to talk about. The look and feel of the syntax
| is the least important part of a language but its also the
| easiest to complain about.
| corysama wrote:
| Reminds me of Bjarne Stroustrup talking about how every time
| they add a new feature to the language, it's unfamiliar to
| anyone so everyone wants it to be REALLY LOUD AND OBVIOUS.
| "Stand back! I'm going to use a LAMBDA here!" But, after a
| short time, the new features are so common and familiar that
| everyone starts complaining about how loud they are. "Why is
| the syntax for lambdas so noisy! [](){}! Gah! Can we at least
| make the () optional to quiet it down a bit??"
| adamwk wrote:
| What's unfamiliar about Val? It looks very similar to most
| languages released in the past 10 years with minor changes.
| [deleted]
| jgilias wrote:
| They do have a good reason to do what they do though. They
| explicitly say that they're going for a language where you can
| pretend there are no references and things are just mutable
| values. And you can't really do this without coming up with new
| names. Because of course there are references under the hood.
|
| If Rust goes the explicit modifier route, e.g. something can be
| & and also mut, and you need to know what these are, Val goes
| the implied behavior route where a 'set' parameter can be set,
| while a 'let' parameter can't.
|
| If they didn't come up with new semantics, they'd just be
| making a Rust clone. I for one am very looking forward to how
| Val develops. Currently it seems like it can offer similar
| guarantees to Rust while using a simpler mental model to deal
| with.
|
| I'm curious to see how they are going to tackle concurrency.
| Their roadmap outlines that as one of the trickier parts given
| the semantics that they're going for.
___________________________________________________________________
(page generated 2023-07-18 23:00 UTC)