Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Notorious b.s.d.
Jan 25, 2003

by Reene
rust looks way more promising than golang. option types own own own

you just need a rustfmt tool and you're gold

Adbot
ADBOT LOVES YOU

fart simpson
Jul 2, 2005

DEATH TO AMERICA
:xickos:


symbolic butt, i'd like to apologize for obscuring my point by making a dumb error in my math. when that code is compiled, the compiler will verify that it's never possible, ever, in your program to pass a value that's already in C to that function. and then the compiler will strip away the extra type information and your runtime is dealing with a normal float, so it's basically free

fart simpson fucked around with this message at 01:17 on Aug 27, 2014

FamDav
Mar 29, 2008

Subjunctive posted:

what does it mean for something to be in the stdlib vs the language proper?

standard libraries are expected but not necessary for compilation/interpretation/execution. also rj i really like the optional syntax in swift because i think it makes more sense in the context that swift is used v:)v.


quote:

are JS Object and Array and RegExp literals stdlib-syntax? Objective-C's NSString @"butts" form? the operand to Java's throw keyword must inherit from a stdlib type, and iteration syntax knows about an interface, and "literals" create a stdlib type instance. c# has using/IDisposable. C++'s for-: and user-defined literals.

i wouldn't count user-defined literals, but i get your point.

quote:

interaction between syntax and type system seem like a part of pretty solid language design, and implementations of those types will naturally live in the stdlib.

which is great, but i would find it much more interesting if instead of adding a bunch of new compiler-defined operators, there was a way to write in-source new operators.

fart simpson
Jul 2, 2005

DEATH TO AMERICA
:xickos:

HappyHippo posted:

coding in js more recently has got me thinking that static typing only catches the easiest to find and easiest to fix errors. i do run into type errors of course but they're very rarely headaches, because when the types don't match you've usually made a really basic mistake. the more subtle bugs are the kind a type system wouldn't catch anyway. that said, i do hate weak typing (by which i mean poo poo like coercing strings to numbers and vice versa, falsey and truthy values, etc), it only makes those type errors that do occur harder to find. it's unfortunate that so many dynamically typed languages are also weakly typed.

that doesn't mean static typing is useless though, it really helps you reason about the code; even if there's no comments it usually isn't difficult to figure out what's going on based on the types alone. they also allow for intellisense or it's equivalent. and the way languages like c# basically force you to design your code around a set of types is helpful in structuring complex projects. overall i think statically typed is better when the project is complex and you're working with a team

basically "catching errors" is the least significant advantage to static typing, imo

this is probably true if you're only working with built in types and never creating your own. what about my earlier (incorrect :shobon:) example of converting temperatures. in python, i've definitely run into subtle bugs where i was essentially passing a value that was already C into that conversion and ending up with something nonsensical. it's a basic mistake, but it can be hard to track down

FamDav
Mar 29, 2008

Vanadium posted:

Oh, yeah then, ours is called Result and has Ok and Err arms and they removed the regular Either type in January for whatever reason. :shobon:

the reason was actually "nobody uses this for anything but error and result, so why don't we actually just name it what it is"

fart simpson
Jul 2, 2005

DEATH TO AMERICA
:xickos:

Malcolm XML posted:

i like stuff like row polymorphism which gives u documentation and is pretty flexible

one thing haskell got wrong was not having good records.

maybe they'll fix it but the community is off masturbating to lens's 7 type parameters

this is one thing i like about elm that i miss when i write haskell

Notorious b.s.d.
Jan 25, 2003

by Reene

HappyHippo posted:

that said, i do hate weak typing (by which i mean poo poo like coercing strings to numbers and vice versa, falsey and truthy values, etc), it only makes those type errors that do occur harder to find. it's unfortunate that so many dynamically typed languages are also weakly typed.

strong, dynamic typing is very nice, but i'd still rather have static. i prefer catching more errors up front and fewer at runtime, even if the latter category is equally easy to debug.

(of course my only experience with a strongly typed fully dynamic language is common lisp. so there's that.)

Blotto Skorzany
Nov 7, 2008

He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

tef posted:

rand takes a integer from 1..n, but you can pass it anything that has to_i, then it calls abs on the value

in particular they decided it would be better to munge anything into a positive number than require them.

for example: why does rand(0) return a number from 0..1 but not rand(1) who knows

lol ruby

Vanadium
Jan 8, 2005

Rust has had a pretty printing mode all along but it never was really kept in sync with how people want the code to look, especially as the syntax evolved. If I run it on a mangled file now it mostly looks readable but ends up with some pretty excessive alignment-instead-of-indentation whitespace that I don't think is considered idiomatic now. Also it doesn't manage to group/space line comments as they were in the original file but maybe I was a bit excessive with mangling nonsignificant whitespace, I dunno how good gofmt is at that stuff.

ANYWAY people bring this up even more often than other Go comparisons and I'm sure something will eventually show up. pcwalton, one of the corest core team members, apparently has a fairly early prototype up on github.

Incidentally I'm not sure how solid the design of the artisanal rust package manager is, but given that it's like the third iteration of the concept it's probably pretty good by now!!

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

FamDav posted:

standard libraries are expected but not necessary for compilation/interpretation/execution.

there aren't very many languages that can operate without some ancillary library, but that definition opposes your argument in a circular fashion: Optional is an essential part of programs, because of the syntactic support, so by definition they are now language and not stdlib. :crossarms:

Vanadium
Jan 8, 2005

FamDav posted:

the reason was actually "nobody uses this for anything but error and result, so why don't we actually just name it what it is"

That's what I was gonna post originally but then the bulk of the PR is introducing

code:
enum Result { Signed(ast::int_ty), Unsigned(ast::uint_ty) }

enum Position {
    Exact(uint),
    Named(@str),
}

pub enum PluralSelector {
    Keyword(parse::PluralKeyword),
    Literal(uint),
}

enum OutputLocation<T> {
    Pretty(term::Terminal<T>),
    Raw(T),
}
(one of them twice, in separate modules) to replace various uses of Either, so it's probably more like "We don't want people to use a general Either type because that's not semantic enough, all the useful helpers that you could define for the general case be damned"

Notorious b.s.d.
Jan 25, 2003

by Reene

Vanadium posted:

ANYWAY people bring this up even more often than other Go comparisons and I'm sure something will eventually show up. pcwalton, one of the corest core team members, apparently has a fairly early prototype up on github.

it is literally the only thing i like about golang

Vanadium posted:

Incidentally I'm not sure how solid the design of the artisanal rust package manager is, but given that it's like the third iteration of the concept it's probably pretty good by now!!

it's probably loving terrible but it can't be worse than golang

lol @ including github sources

Vanadium
Jan 8, 2005

I'm also concerned that my posting must be really bad when all I do is doomsay rust and you're all "RUST IS LOOKING PRETTY GOOD RIGHT THERE"

Max Facetime
Apr 18, 2009

FamDav posted:

it is different, because now i only have to test my filtering function for correctness. i know that if my program compiles that any function demanding filtereddata gets filtereddata, and that the only possible place where unfiltered data can leak is in the function that does the filtering.

while I agree, I do see the point. going back to the certificate validation example, we might say that a certificate is safe for use if a bunch of mathematical relations hold and also that it won't expire in the next 5 minutes. so our algorithms establishes these invariants, we declare the certificate Valid...

... and the battery in the laptop malfunctions causing the OS to think it has been completely drained. the OS performs an emergency hibernation to try to minimize data loss...

... 10 minutes later we have finally found a compatible wall-charger but it's too late; the certificate has expired in the meantime. oh no! we tremble as the laptop starts to boot...


this isn't just an issue with type checking missing some errors, though. an invariant that can cease to hold on its own without any computation having taken place goes against pretty much everything that CS stands for. or mathematics

Vanadium
Jan 8, 2005

I mean the rust-package-manager model of declaring dependencies is pretty much putting a github url into a .toml file. I'm not sure whether it works with other git urls. At least it goes and remembers what revision it used and uses the same revision if you compile it again later, I guess.

Notorious b.s.d.
Jan 25, 2003

by Reene

Vanadium posted:

I mean the rust-package-manager model of declaring dependencies is pretty much putting a github url into a .toml file. I'm not sure whether it works with other git urls. At least it goes and remembers what revision it used and uses the same revision if you compile it again later, I guess.

i guess i was technically correct, this is not actually worse than golang, just equally bad

Notorious b.s.d.
Jan 25, 2003

by Reene

Max Facetime posted:

we declare the certificate Valid...

... and the battery in the laptop malfunctions causing the OS to think it has been completely drained. the OS performs an emergency hibernation to try to minimize data loss...

... 10 minutes later we have finally found a compatible wall-charger but it's too late; the certificate has expired in the meantime. oh no! we tremble as the laptop starts to boot...

so, yeah, we don't have languages with great primitives to express lengthy, unsignalled halts in computation to functions with point-in-time values

we do have languages with great primitives to mark whether a thing is meters or inches, and people itt are unironically arguing that that's not useful

Vanadium
Jan 8, 2005

Does it help that you can specify versions, git branches/tags/revisions, etc? And that it's not part of the language?

Notorious b.s.d.
Jan 25, 2003

by Reene

Vanadium posted:

Does it help that you can specify versions, git branches/tags/revisions, etc? And that it's not part of the language?

well it is at least modestly better to not actually be tainting the source files with direct references to github

fewer places to search for poison

FamDav
Mar 29, 2008

Subjunctive posted:

there aren't very many languages that can operate without some ancillary library, but that definition opposes your argument in a circular fashion: Optional is an essential part of programs, because of the syntactic support, so by definition they are now language and not stdlib. :crossarms:

youre right, but i would like it if languages allowed for defining more of their syntax in the source of their libraries instead of in the compiler.

HappyHippo
Nov 19, 2003
Do you have an Air Miles Card?

fart simpson posted:

this is probably true if you're only working with built in types and never creating your own. what about my earlier (incorrect :shobon:) example of converting temperatures. in python, i've definitely run into subtle bugs where i was essentially passing a value that was already C into that conversion and ending up with something nonsensical. it's a basic mistake, but it can be hard to track down

i do like the example of using types to ensure correct units. its a good example of what you can do with static typing (although others have pointed out you can do it dynammically) and it does in fact catch what would otherwise be subtle and difficult to detect bugs, mainly because you're creating a semantic difference between what would otherwise appear to be compatible types (two floats). this is different than the more common type error where they would never have been compatible in the first place (say comparing a string to an int, or using an object without member x where it was expected). so while it's totally useful i find that usually the type system is catching easy to notice errors

tef
May 30, 2004

-> some l-system crap ->

well if you provide a number n

if 0 <= abs(n) < 1 then it returns a float between 0 <= f < abs(n)

if floor(abs(n)) >=2 then it returns an int between 0 <= i < floor(abs(n))-1. so yes, you need to call rand(2) to get 0/1

if 1 <= abs(n) < 2 then it returns 0. always.

principle of least surprise right there

Shaggar
Apr 26, 2006

tef posted:

hey shaggar, this is what happens when people who aren't you use xml and soap

like, with webapi you have to actively fight the system to do terrible things like this. why do you people keep using bad tools.

Notorious b.s.d.
Jan 25, 2003

by Reene

HappyHippo posted:

i do like the example of using types to ensure correct units. its a good example of what you can do with static typing (although others have pointed out you can do it dynammically) and it does in fact catch what would otherwise be subtle and difficult to detect bugs, mainly because you're creating a semantic difference between what would otherwise appear to be compatible types (two floats). this is different than the more common type error where they would never have been compatible in the first place (say comparing a string to an int, or using an object without member x where it was expected). so while it's totally useful i find that usually the type system is catching easy to notice errors

on the contrary. passing a string to where you needed an int is insanely easy to catch as an error.

catching the distinction between two types with compatible internal implementations is the hairy thing that i want a smart compiler for in the first place

tef
May 30, 2004

-> some l-system crap ->

Shaggar posted:

like, with webapi you have to actively fight the system to do terrible things like this. why do you people keep using bad tools.

years of old bad tools encourage bad behaviour with new tools

tef
May 30, 2004

-> some l-system crap ->

FamDav posted:

youre right, but i would like it if languages allowed for defining more of their syntax in the source of their libraries instead of in the compiler.

i too would like it so that to read a source file i had to read another one to find out how the syntax worked.

MononcQc
May 29, 2007

Vanadium posted:

I'm also concerned that my posting must be really bad when all I do is doomsay rust and you're all "RUST IS LOOKING PRETTY GOOD RIGHT THERE"

I'm the one disappointed by Rust thanks to your posting (though I'm intrigued to see how people will deal with linear types as their primary concurrency tool in the real world)

Sweeper
Nov 29, 2007
The Joe Buck of Posting
Dinosaur Gum

MononcQc posted:

I'm the one disappointed by Rust thanks to your posting (though I'm intrigued to see how people will deal with linear types as their primary concurrency tool in the real world)

I'm really excited for a useable rust, kinda want to contribute but :effort:

fart simpson
Jul 2, 2005

DEATH TO AMERICA
:xickos:

HappyHippo posted:

i do like the example of using types to ensure correct units. its a good example of what you can do with static typing (although others have pointed out you can do it dynammically) and it does in fact catch what would otherwise be subtle and difficult to detect bugs, mainly because you're creating a semantic difference between what would otherwise appear to be compatible types (two floats). this is different than the more common type error where they would never have been compatible in the first place (say comparing a string to an int, or using an object without member x where it was expected). so while it's totally useful i find that usually the type system is catching easy to notice errors

semantic differences are what types are all about. its all 0s and 1s in the end

tef
May 30, 2004

-> some l-system crap ->
i haven't known what to make of rust because it has changed over time and still isn't 1.0

i've seen some wondorous intent from the outset, saw them adding uniqueness and experimenting with typestates, option types and other gizmos.

but i don't know how much of the software written in rust benefits from being written in it. sure enough servo serves as a good example but i don't think i ever want to write a browser. how much do you gain from writing a package manager in a systems language i do not know either.

i'm glad rust is out there and exploring a lot of these tradeoffs between features and seeing what can be reasonably implemented and still be sufficiently useful, but i haven't been in this sort of situation before

Max Facetime
Apr 18, 2009

Notorious b.s.d. posted:

so, yeah, we don't have languages with great primitives to express lengthy, unsignalled halts in computation to functions with point-in-time values

we don't, because we don't like to talk about our halts. we have a halting problem and we are ignoring it

MononcQc posted:

(though I'm intrigued to see how people will deal with linear types as their primary concurrency tool in the real world)

i'm equals parts
:coffeepal: and :jerky: and :magical: to see this
:coffee: :goku:

FamDav
Mar 29, 2008

tef posted:

i too would like it so that to read a source file i had to read another one to find out how the syntax worked.

dont tell haskell about most of its defined operators, i guess?

MononcQc
May 29, 2007

people don't read Haskell, they can just read the paper about the program written in Haskell

rjmccall
Sep 7, 2007

no worries friend
Fun Shoe
i devoted a minute or so of my wwdc talk this year to telling people not to go crazy with custom operators and the like

in my first draft, the slides for this section were basically "god dammit c++" and "god loving dammit haskell"

decided to stay classy, tho

b0lt
Apr 29, 2005

rjmccall posted:

i devoted a minute or so of my wwdc talk this year to telling people not to go crazy with custom operators and the like

in my first draft, the slides for this section were basically "god dammit c++" and "god loving dammit haskell"

decided to stay classy, tho

you mean i can't overload the comma operator in swift?? :argh:

rjmccall
Sep 7, 2007

no worries friend
Fun Shoe
if we had one, you would be able to overload it, but i would reserve the right to track you down and make you watch that wwdc talk until you felt bad and/or understood dave abrahams' memoization functor

rjmccall
Sep 7, 2007

no worries friend
Fun Shoe
basically the only swift operators you can't overload are:

  • binary = (assignment), which is justifiably special
  • prefix & (pass-by-reference), which i think is also justifiably special, but which i think it is possible to hook into on the receiver side
  • postfix ! (optional force), which we made builtin for reasons that no longer exist, and which will eventually become a library operator again
  • postfix ? (monadic optional evaluation), which is not just a normal unary operator; we could allow this to be hooked via a protocol, but that protocol would be quite complex and would rely on type-system features we don't have
  • ternary ? :, which we could easily make overloadable except it's such a weird special case in the grammar, which is basically the same reason it's not overloadable in c++

HappyHippo
Nov 19, 2003
Do you have an Air Miles Card?

Notorious b.s.d. posted:

on the contrary. passing a string to where you needed an int is insanely easy to catch as an error.

catching the distinction between two types with compatible internal implementations is the hairy thing that i want a smart compiler for in the first place

yeah that's what im saying. my point is the cases where they're compatible to the type system but semantically different i don't find come up that often. most often im getting errors like "you tried to call blah.x but that's undefined", those errors are easy to find and debug in either static or dynamic type systems. so the ability of static typing to catch that error for me i dont find so valuable, because it never caused me much headache in the first place. again though i find static typing has other benefits, my point is error catching isn't the top of that list for me


fart simpson posted:

semantic differences are what types are all about. its all 0s and 1s in the end

what's your point though? you can use types to express semantic differences in dynamic or static type systems. i was just commenting that its a neat example in the way it adds semantics to otherwise compatible types (floats) to distinguish them. most of the time that isn't something you're worried about because most objects already have interfaces that aren't compatible (ie calling ".length" on an integer)

Vanadium
Jan 8, 2005

tef posted:

i haven't known what to make of rust because it has changed over time and still isn't 1.0

i've seen some wondorous intent from the outset, saw them adding uniqueness and experimenting with typestates, option types and other gizmos.

but i don't know how much of the software written in rust benefits from being written in it. sure enough servo serves as a good example but i don't think i ever want to write a browser. how much do you gain from writing a package manager in a systems language i do not know either.

i'm glad rust is out there and exploring a lot of these tradeoffs between features and seeing what can be reasonably implemented and still be sufficiently useful, but i haven't been in this sort of situation before

The guy who wrote rust-http, abandoned it, and is now designing the next rust http lib called teepee, is gonna do a talk about rust for the web next month at strange loop or something: https://thestrangeloop.com/sessions/fast-secure-safe-the-web-that-can-still-be and he seems super enthusiastic about rust being just great for the web!!

Other people are posting about using rust to write libs to be consumed by C, maybe even as drop-in replacements for existing libs, but I'm not aware of concrete plans there. The cargo guy is using rust for a ruby extension that has to Go Fast and preferably not crash their rails. Some people who don't trust themselves with C/C++ seem to think it's a nice substitute too.

Adbot
ADBOT LOVES YOU

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

HappyHippo posted:

most of the time that isn't something you're worried about because most objects already have interfaces that aren't compatible (ie calling ".length" on an integer)

the most common issue there in JS is probably accidental stringification. if something inadvertently ends up as a string, you can apply addition to it, but also array operations like subscripting and .length. and it's all too easy to end up with a string when working with DOM.

(.length on a number in JS will evaluate to undefined, rather than throw, because primitives are automatically boxed when properties are accessed)

rustchat: we've been looking at Rust internally as a systems language, because it should be pretty fast, pretty safe, be reasonable for doing concurrent stuff, and have a good FFI. pretty sure there isn't anything in production yet, though.

Subjunctive fucked around with this message at 03:39 on Aug 27, 2014

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply