Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The reference D compiler is now open source

forum.dlang.org

Post reply on HN
Print view View original

271–280 of 313 posts

Re: The reference D compiler is now open source

#271

Post by vonmoltke »

steveklabnik wrote: post #208
vonmoltke wrote: post #200

Earlier quoted context omitted.

> every language other than assembly languages has some amount of runtime How are you defining "runtime" such that this statement is correct?

What language are you thinking of that I'm missing? C has crt.0, for example.

crt0 does things you would need to do manually in hand-coded assembly anyway. It is no different than manually creating a library of assembly subroutines that you inject into your code, at which point assembly technically has a runtime as well.

I see a distinction between a runtime library and a language runtime. The former is just a set of convenient routines for interacting with a specific platform. The latter is something that runs alongside your program to facilitate its execution, like a JIT or an interpreter.

Re: The reference D compiler is now open source

#272

Post by giancarlostoro »

TTPrograms wrote: post #183
iamNumber4 wrote: post #105

Good news indeed. Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D. D's only issue is that it does not have general adoption, whic…

How well does Dub work? That could be another issue preventing widespread adoption.

I want to say it's somewhat good, but sometimes it just doesn't work out too well, and experience may vary between developers. But I totally agree, if some of it's quirks were sorted out... Sidenote: I'm really sorry I can't mention any off the top of my head, it's been a year or more since I last touched it. I did enjoy using dub, but ran into some odd issues from time to time. If it breaks, you can't use it properly basically.

Re: The reference D compiler is now open source

#273

Post by [deleted] »

jononor wrote: post #226
milesrout wrote: post #221

Earlier quoted context omitted.

Coffeescript is essentially dead, many production web sites were written in it.

For what definition of dead? Sure, not so many use it for new projects, but it is still being maintained. There is an upcoming major release which will output ES2015. I've got some tens of libraries/apps written in CS, no plans to migrate them. Works as well today as it did 3 years ago.

[deleted]

Re: The reference D compiler is now open source

#274

Post by jeremyjh »

sqeaky wrote: post #186
vardump wrote: post #113

Earlier quoted context omitted.

I think Go should be pretty deterministic, if you don't allocate or free at all at runtime. Just like C. You lose determinism with malloc() and free(). As any embedded/kernel developer knows, malloc() takes often unacceptably long time. Or even free().

Go does allocate and free at runtime, it just isn't explicit because its a garbage collected language and the garbage collector handles most of the freeing for you. Different GC'd languages handle allocations differently, some have a keyword, some do it whenever creating an instance of a type over a certain size. With C, C++ and Rust allocating memory often boils down to calling something equivalent to malloc and fre…

There are techniques used in GC languages to reduce or even eliminate runtime allocations. Basically - you re-reuse objects and pre-allocated collections rather than creating new ones. These techniques are common in games programming; and libraries like libgdx[0] (for Java) offer object pools to make this easier. I know some Java server applications use similar techniques.

[0]https://github.com/libgdx/libgdx/wiki/Memory-management#obje...

Re: The reference D compiler is now open source

#275

Post by leshow »

dbaupp wrote: post #249
WalterBright wrote: post #213

Earlier quoted context omitted.

Memory safety in D is the usual definition - making memory corruption impossible. There's no notion of "borrowing" in D nor any notion of "only one mutable access at a time".

By not having borrowing, do you mean the compiler doesn't stop one from mutating something that has a dependent scoped pointer pointing into it? How does D avoid dangling pointers for that?

It has a GC, I think.

Re: The reference D compiler is now open source

#276

Post by leshow »

GreenWinters wrote: post #185
smitherfield wrote: post #42

Earlier quoted context omitted.

> race-free concurrency Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.

Could you give an example of a kind of race conditions allowed in Rust? (Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)

Rust does not prevent all race conditions because doing so would be impossible. It would be akin to solving the halting problem.

Deadlocks, and other synchronization issues are just some 'general race conditions' Rust can't solve.

Rust's prevents 'data races' defined as:

-two or more threads concurrently accessing a location of memory

-one of them is a write

-one of them is unsynchronized

https://doc.rust-lang.org/nomicon/races.html

Re: The reference D compiler is now open source

#278

Post by loeg »

mhh__ wrote: post #150
loeg wrote: post #61

Earlier quoted context omitted.

Is the GC mandatory in D? I was under the impression some time ago that D could run GC-free, but the standard library still widely used GC. Did I just misunderstand?

You can tag a block @nogc, if you just need to avoid it for a specific part of your program. This can be done with the whole program, but quite a lot of the standard library requires the GC. I should point out that the GC has no problems that affect day to day usage, the stuff people complain about is when it's running for a while (it's conservative atm so it leaks).

If you can tag the entire program @nogc, great.

Re: The reference D compiler is now open source

#279

Post by jnordwick »

homarp wrote: post #243
jnordwick wrote: post #238

Earlier quoted context omitted.

XML? That's probable Spring. I hate that thing. But Java's tooling for monitoring is crazy good. The benchmarking harness that gives back the assembly code generated for hot code, unmatched on any other non-native language. The editors and how good hinting and auto-complete are, I don't know of another language that integrates so well. Java really raised the bar on tooling and other languages/platforms have really ha…

try spring boot. not a line of xml :) https://spring.io/guides/gs/spring-boot/

A quote I found one time, can't remember who: "When your framework has a framework, there's a problem."

Re: The reference D compiler is now open source

#280

Post by lomnakkus »

milesrout wrote: post #270
lomnakkus wrote: post #253

Earlier quoted context omitted.

AFAICT, yes it was. Obviously, it wasn't accepted as-is , but it was certainly motivated (i.e. "inspired") by the success of "static if" in D.

I do not agree at all. It's very obvious functionality, and would be in D either way.

I'm not sure I understand what you're trying to say. IIUC the causality in your last sentence is opposite to what've you been arguing? Maybe it's just a typo, but either way you're going to have to provide evidence.
Post reply on HN